org.eclipse.equinox.p2.core/debug=true
org.eclipse.equinox.p2.core/reconciler=true

Just create a .options file at the root of the Eclipse installation directory and pass -debug when you start Eclipse. You should see some debug output from p2 in the log…

[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] Repository created file:/usr/share/eclipse/dropins/pydev/
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] com.python.pydev.codecompletion 1.6.1.2010080312
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.parser 1.6.1.2010080312
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.feature.feature.jar 1.6.1.2010080312
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.help 1.6.1.2010080312
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.debug 1.6.1.2010080312
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] com.python.pydev.fastparser 1.6.1.2010080312
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.feature.feature.group 1.6.1.2010080312


Happy debugging!

Well, the best way to get rid of this dialog is to actually sign your JARs like most mature Eclipse.org projects do. At first I didn’t think it was possible to remove this dialog without signing your JARs, however, after working with a colleague I discovered the eclipse.p2.unsignedPolicy system property (you learn something new everyday, right?). For example, if you didn’t want this dialog to appear, you can set -Declipse.p2.unsignedPolicy=allow when your Eclipse-based application starts up. The valid values for eclipse.p2.unsignedPolicy are:

• prompt – user is prompted for confirmation when installing unsigned content (default value)
• fail – installing unsigned software is never allowed and the install will fail
• allow – installing unsigned software is always allowed and the user is never prompted (3.4 – 3.5 behavior)

If you’re interested in the original bug report, check it out here.

Hopefully people don’t have to struggle as much as I did to find this precious link

Consider this your chance to voice your concerns and offer feedback.

• p2 – Pascal Rapicault
• Eclipse DTP – Jo Peel
• Introduction to Eclipse – Wayne Beaton

Good to see that there’s some evangelism going on during Eclipse’s typical off months

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