To give plug-in developers out there a heads up… I want to say that there will be a new preference available to you when working with target platforms in 3.4M7:
What does this preference do?
Well, first, let me tell you about how PDE goes to build your target platform. By build, I mean what PDE does when you point it to a location and you get a target platform out of it. There has always been a little magic inside that operation. The magic involves PDE analyzing your target platform location and looking to see if it can find a configuration of plug-ins installed. How did PDE do this? In the the era of before p2, there was a platform.xml file that was kept by Update that listed the set of recognized plug-ins. In the era after p2, there is a file called bundles.info which serves a similar purpose. These files were there so the runtime can make smart decisions on what to actually run when started. For example, you could have 10 versions of plug-in A on disk, but only one version listed in one of those configuration files so when Eclipse is ran, the runtime only knows about what is listed in the configuration file (see a sample bundles.info below).
So if PDE found one of these “configuration files” it would construct your target platform to reflect what would actually be running in your target. If it didn’t find one of these configuration files, it will then just manually scan the file system and build a target platform with what plug-ins PDE found on disk. In the 10 versions of plug-in A case, it would populate the target platform with all 10 versions if it couldn’t find a target “configuration file.”
When p2 was introduced in the SDK (3.4M6), the bundles.info file was always around and caused confusion for people when they grabbed the SDK, unzipped something like WTP and all their dependencies, and pointed their target platform to the location to only see the SDK set of bundles. PDE was almost being too smart here… it’s analysis of the target platform was correct, ie., only the SDK set of bundles have been discovered by p2 and since the target hasn’t been launched, the unzipped set of bundles (WTP) haven’t been discovered yet.
To not break people’s existing workflows, PDE added this preference to the target platform preference page with some smart initialization. If you’re target == host, we will attempt to build the target platform using the target’s configuration. If your target != host, PDE will revert to manually scanning for plug-ins on the file system to build your target platform. It seems 99.9% of the Eclipse plug-in development community has been spoiled by that workflow so PDE needs to adapt. However, if you wish to change this behavior, the preference will allow you to do that based on your needs.
I hope this clarifies things for some people who have been experiencing growing pains with the 3.4M6 version of Eclipse. It pains me to expose this preference, but it seems it may be a good thing in the long run. The important thing to take away here is that an unzipped plug-in != installed plug-in.
Related bugs:
[bug 226037] – initialization policy for target platform should be different based on location
[bug 225148] – P2 PDE target doesn’t work, easily
