Community
Participate
Working Groups
This bug is created as a follow on to bug 225148. I think that the initial set of bundles in the target platform should be determined differently based on the location of the target platform. (1) If the target platform is the default location (i.e. the running host), we should use the bundles.info to populate the initial set of bundles. (2) If the target platform is not the default location, we should scan the directory to populate the initial set of bundles. Since the behavior is dependent on the target platform location, I think this setting has to appear on the target platform page (rather than the general page). We'll need to keep track of whether the user has changed the default setting to somethin explicit to know whether to change the "initialize policy" as they change the target platform location... this migh take some experiemtation to get the user interaction right.
yap, we can work on something here.
The goal: "PDE should launch the target platform with the same contents that p2 considers to be installed, without having the user to change the current workflow." Note: this is only when the target platform has "default contents" - i.e. if the user has selected/defined an explicit set on bundles, then PDE launches just those bundles. Ideally we would not need a preference for this, and p2 would provide an API for this (i.e. bundle discovery API). Since p2 is not planning an API for 3.4, and PDE may not want to require p2, we may need to copy code in the short term.
CC'ing Pascal for comment on "p2 API", or where we might look to copy code that discovers bundles during launch.
(In reply to comment #2) > "PDE should launch the target platform with the same contents that p2 considers > to be installed, without having the user to change the current workflow." We actually do that now... however, the problem is that the target runtime isn't up to date... PDE can't predict user intentions currently. PDE's main focus should not be able to break people's existing workflows, p2 comes secondary to this. Note that PDE has to not only support working against p2, but targets that contain 3.0, 3.1, 3.2, 3.3, etc... it's common for people to download a 3.4 version of Eclipse and target it to be on say 3.3 or 3.2 which their product is based on. The current situation is no different to how we would treat a platform.xml... for example, imagine someone's unzips the SDK... as their target... launches that SDK for some reason... then unzips EMF into the SDK... in that case, PDE would only see the SDK and not EMF since the platform.xml hasn't been updated here. The current solution is sufficient for 3.4 in my opinion (with some user experience enhancements in terms of wording)
(In reply to comment #4) > The current situation is no different to how we would treat a platform.xml... > for example, imagine someone's unzips the SDK... as their target... launches > that SDK for some reason... then unzips EMF into the SDK... in that case, PDE > would only see the SDK and not EMF since the platform.xml hasn't been updated > here. Darin's suggestion would still work for this case. You unzipped the SDK and EMF and pointed to it in the target. Darin's suggestion is that we would populate from all bundles in that target folder if the target folder was not the default location (user explicitly chose a folder). The problem with the current solution is that PDE and p2 are now doing different things. p2 says which bundles to run, doesn't matter where they are. If the target is based on the currently running platform, we should use what p2 considers to be the platform. I see this as a step in the wrong direction, in 3.4 we should be moving towards p2, not away from it.
Darin, p2 does not have the API you are looking for. The problem is that the API you are after and what p2 knows about are at two different levels of abstraction. Bundles (and even features) are things that p2 happens to be manipulating but it has no particular knowledge about those, no more that it has particular knowledge about exes or other things. This isolation comes from touchpoints. As for copying code that does the discovery, here again p2 is structured such that things get discovered because they appear in a repository, repositories whose layout is pluggable. Therefore there is no sure way to know what will be happening until the system has run and everything we do without "running" the system is just a guess and will likely have to be revisited post 3.4. That said, here are 3 alternatives that I can think of going from the least fidelity to the most fidelity - simply browse the file system and discovery bundles in well-known places (http://wiki.eclipse.org/Equinox_p2_Getting_Started). - create repository objects on the dropins using the repository type available in the development instance and list all the artifacts that are bundles. - Run the target profile with -initialize if the profile can run and if the user is ok with running the instance. If the profile can't run, then we could create a temporary profile and do provision into it from content discovered into the dropins.
Let me repeat, with bug 225148 fixed, I'm confident we have taken care of people's workflows for 3.4 :)! If we go with Curtis' approach in comment #5, we still need that preference, we can just be a bit smarter about the preference default. We can discuss more on PDE's call this Wed and make fun of how jet-lagged I am. Also, I am not comfortable actually launching a target to actually set the target platform... that seems unnecessary. I'm actually quite happy with our current approach... it doesn't break anyone and exposes an interesting concept to plug-in developers that was hidden before. Let's try to keep things simple and realistic in 3.4 In the 3.5 / 4.0 timeframe, we can discuss how to make this target platform story even better. There are quite a few ways to set target platforms in PDE (target provisioners, target definition files, target platform pref page) and it's time to see if we can consolidate this story more. For example, I could envision a future where improved target definitions were the way to work with target platforms versus the current preference page.
I am fine for an approximation of the real solution in 3.4 (given p2 full power is not yet in use), but once the pref defaults are made smarter, why would you ever want to flip the preference ? If running on host, then the preference would be irrelevant, since p2 would have provisioned the target already. If running a different target, then full discovery is all a user would need I think. So why is there a need for a preference to achieve this ?
(In reply to comment #8) > I am fine for an approximation of the real solution in 3.4 (given p2 full power > is not yet in use), but once the pref defaults are made smarter, why would you > ever want to flip the preference ? > If running on host, then the preference would be irrelevant, since p2 would > have provisioned the target already. If running a different target, then full > discovery is all a user would need I think. > So why is there a need for a preference to achieve this ? I was wondering this too... if we had the refined discovery mechanim, would we need to expose it to the user? I can only think of one situation where it would be important (and I'm not sure how common it is). If a user wants to point to an external installation/profile that has been provisioned, then explicitly chosing the "installed" bundles (instead of all bundles) could be important. However, if this is not a common use case, then perhaps we don't need to expose the preference - we just use the location as a guide/heuristic on how to initialize the bundles.
IMHO this usecase was one of the main driving forces for doing target platforms in the first place. The scenario here is some team is working on a product (whatever). The team members all get the latest build of the product and point to it as the target. They then check out only the projects for the plugins they are developing. In this case they want exatly the product configuration as their target since that is what they are building (or building on). This same story is true of poeple building on platforms. The SDK is our platform but it is not special. Lots of other people have their Eclipse base on which they build. The other usecuase is target provisioning. Here you are effectively provisining your target and it is reasonable to have a workflow that has things really installed into the target (with the proper bundle.info, profile, ... written). So from PDE's point of view it cannot tell the difference between a provisioned app/product and a target that someone has created using the p2 target provisioning support.
If the target got provisioned already, wouldn't the discovery yield back the same amount of installed bundles anyway ? If so, why have the user tell whether the target was provisioned already or not (maybe he doesn't even know, since he grabbed the official I-build made for him), instead of figuring it ourselves ? My understanding is that the PDE target should reflect the runtime workbench the user would run in the end, once he tries to launch it.
Jeff & Philippe: from your comments, it sounds like you think teams such as WTP should change their workflow to deal with p2 - i.e. they should explicitly "provision" the target being developed?
Proposal Refinement: * Support a preference to "ignore p2 metadata" (but don't call it that in the UI). * When the running host is the target platform (typical SDK developer scenario), the default setting of the preference will be "use p2 metadata" - i.e. unchecked. * When the target platform is remote (not the running host), the default setting of the preference will be "ignore p2 metadata" We can improve this implementation over time with assistance from p2, or by mimicing p2's bundle discovery at startup. For example, we start out by always using p2 metadata and use timestamp analysis to note that the remote target platform's bundle.info is stale and only fall back to "ignore p2 metadata" in this case. The explicit preference will allow users to ignore p2 metadata in any scenario.
(In reply to comment #13) > Proposal Refinement: > > * Support a preference to "ignore p2 metadata" (but don't call it that in the > UI). This is already available in the i-build as part of the fix to bug 225148... and it's just not p2 metadata... this is any Eclipse installation that has its target configuration available (i.e., <3.4 it's the platform.xml). > * When the running host is the target platform (typical SDK developer > scenario), the default setting of the preference will be "use p2 metadata" - > i.e. unchecked. > * When the target platform is remote (not the running host), the default > setting of the preference will be "ignore p2 metadata" So this is what I will make available in the next i-build (4/15) after I do some more testing. I'm confident that with this final polish item along with a possible preference wording change, we're golden. Note, we can't expect teams to change their development workflow for 3.4 ... the community will make us pay for it. However, this fix (along with the fix from bug 225148) allows the best of all worlds. Thanks for the feedback and I'll get something in the next i-build and do some community relations on this new preference. btw, Sorry I'd respond sooner, but it's like a game to find stable internet here in India.
(In reply to comment #14) > This is already available in the i-build as part of the fix to bug 225148... > and it's just not p2 metadata... this is any Eclipse installation that has its > target configuration available (i.e., <3.4 it's the platform.xml). Yes - even better to have this consistentcy - i.e. use the 'installed' metadata (whether from p2 or update manager). However, I wasn't sure we ever used platform.xml in the past to initialize the target platform (if so, great).
wrt comment 12, NO, I am explicitly saying that teams (WTP and otherwise) MUST NOT have to change their workflows. I am arguing against the idea that target content discovery be based solely on the where the target is. The preference is essential. I'm liking what Chris has done.
Created attachment 95920 [details] org.eclipse.pde.patch Here is a patch that: 1) updates the preference text to be "build target platform based on target's installed plugins" 2) sets smart defaults based on the location of the target platform With these changes, people who just use the SDK will get defaulted to use what p2/update provides them as the list of installed bundles. For those who use a different target from the running instance, they will get defaulted to the classic behavior of PDE scanning for plug-ins. Thanks for the feedback, I'm happy with this addition.
Created attachment 95921 [details] mylyn/context/zip
> 20080414
