Community
Participate
Working Groups
Supporting just features/plugins and links directory is not flexible enought. with Eclipse 3.x uses platform.xml to control what plugin to be loaded. baseLocation should also support configuration with platform.xml.
Created attachment 64829 [details] Patc for org.eclipse.pde.build 3 files that I change to have it support.. Please review and see if it can be commited into the base. I have ran test against my product build to confirm the old ways still worked, as well as using platform.xml
This is a fine idea. However before tackling this we should see how the new provisioning work from equinox evolve.
I don't know if it should be covered by this bug or a new one, but the IDE should also support a target (Preferences > Plug-in Development > Target Platform) that uses plaform.xml. I don't know whether this patch addresses that situation, but I assume not since the files changed have "build" in their name. Why is this affected by the ongoing Equinox provisioning work?
David, I do believe that when pointing the target platform to an eclipse install containing a platform.xml PDE does the proper thing. Some work went into this in 3.2 to enable scenarios where pools of plug-ins are being shared across multiple configurations. See Nalini's bug in PDE UI. This would be affected by the provisioning work because the platform.xml is an update artifact that will unlikely be carried on into the new story with its current shape.
Hum... I had missed the fact that there was a patch attached to this bug.... I will take a look. Conan, could you please attach an actual patch against HEAD? That would greatly facilitate the review and gaging the scope of the change.
will do.
Created attachment 64896 [details] org.eclipse.pde.build patch based on HEAD
Created attachment 65120 [details] Correct format of the patch from HEAD
The patch looks good and the fact that most of the code is coming from PDE Core makes me confident that it could be released for 3.3. There is just one thing that bugs me: given that all the callers of PluginPathFinder.getPluginPaths() eventually convert the returned URLs into Files, why can't getPluginPaths directly return a File[]. By doing this change, it would avoid to have two findPluginXML in BuildTimeSiteContentProvider (note that findPluginXML(String[]) can be changed to findPluginXML(File[]). Conan could you please do those change and attach a new patch for tomorrow friday noon?
Tentatively marking for 3.3.
No, Can be done but it is not an easy. I have to make a different handling of the URL[] in BuildTimeSiteContentProvider because getPlugsPath in URL[] is different then String[].. You request basically required me to start to the beginning to do all the testing again.. Beside, keeping the PluginPathFinder close to the pde.core one make it easier to move up with the pde.core version I would think..
I tried.. but I don't think it is as simple as making a converter from URL[] to String[].. And I think what I have changed in the patch is way better solution.. You to decide..
Created attachment 65214 [details] Patch including the changes proposed above Conan, I have made the changes. Here is a patch, please verify that it works in your environment. Thx.
Created attachment 65230 [details] Extra Patch on top of Pascal's change
Created attachment 65236 [details] New patch addressing some concerns with looking too deep
Patch released in HEAD.
