Twitter github

Posts Tagged with “p2”

Debugging Eclipse p2 Dropins

If you ever have any issues with the p2 dropins directory (which you shouldn’t be using in the first place), there are some handy tracing options you can use…


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
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.parser
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.feature.feature.jar
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins]
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.debug
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] com.python.pydev.fastparser
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins]

Happy debugging!

p2 and the Unsigned Dialog Prompt

Every wanted to make this unsigned prompt dialog go away when you’re installing things into Eclipse?

Well, the best way to get rid of this dialog is to actually sign your JARs like most mature 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.

P2-enabled Update Sites

If you’re looking at doing build-to-build updates using p2, here is the right list of update sites to use (thanks Kim Moir!). It’s really nice not to have to download a new build every time you just want to update to a new build.

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

Call for Input: p2 UI

For those who don’t follow a lot of the Eclipse mailing lists, the p2 team has graciously called for input on the 3.5 p2 user interface.

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

OSBootCamp7 Eclipse Videos

For those who aren’t in the know, there was an OSBootCamp in Ottawa recently that was dedicated to Eclipse. Here are three videos of interest:

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

New Target Platform Preference

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 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 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 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