Community
Participate
Working Groups
CQ:WIND00261271 Build ID: Eclipse 3.7 Indigo My product on top of Eclipse 3.7 (Indigo) includes org.eclipse.pde.runtime in order to get the PDE plug-in spy, but we do not want to include the optional JDT. Due to the way pde.runtime marks up its optional runtime dependencies in MANIFEST.MF (along with incorrect behavior of the p2 publisher as per bug 247099), as soon as _any_ bundle is installed from the Indigo Repository into my product, the JDT is installed silently as a side-effect. This is not acceptable for our product since the unexpected JDT functionality leads to end user confusion.
Created attachment 199489 [details] patch v1, adding p2.inf to make dependencies non-greedy Attached patch fixes the issue, by adding a p2.inf file which explicitly converts the optional runtime dependencies from MANIFEST.MF into optional non-greedy dependencies in the p2 metadata. This approach is in line with the approach discussed on bug 247099, and fixes the incorrect metadata. The non-greedy dependencies advertise the fact that pde.runtime can "work with" the extra plugins, but don't force the installer to also install those optional plugins silently as soon as they are available. Please consider integrating this fix into Indigo SR1, such that our product can ship with an unmodified version of pde.runtime and also other users of Eclipse don't end up with getting unexpected bundles installed. Steps to reproduce, and verify the fix: --------------------------------------- 1.) Install Eclipse Platform Runtime Binary, eg http://download.eclipse.org/eclipse/downloads/drops/R-3.7-201106131736/download.php?dropFile=eclipse-platform-3.7-win32.zip 2.) Place org.eclipse.pde.runtime_*.jar into dropins/ 3.) Launch Eclipse 4.) Help > Install New Software... pick http://download.eclipse.org/releases/indigo 5.) Install "Mobile and Device Development > Target Management Terminal" --> Without the fix, JDT is installed as a side-effect --> With the fix, JDT is not installed
Thanks for considering this for 3.8, but I actually really need this fix in 3.7.1 for our product. As stated, the effect of installing JDT as a side-effect is really problematic for us (and we have actually been patching the pde.runtime bundle ourselves so far to ship our previous releases). I'm very confident that this change is not going to cause issues, because - p2.inf only affects install-time behavior (not runtime behavior) - the only effect is not dragging in optional bundles at install time - Anybody who installs the PDE Feature will get JDT due to the feature dependencies and/or explicit _required_ dependencies from PDE. So I cannot see any workflow where dragging in the _optional_ dependencies would be needed ... it's a plain defect that these are dragged in.
We will consider this for backporting. The p2.inf definitely needs some comments explaining it's purpose and the related bug numbers. Depending if and how bug 247099 is fixed, this file could become unecessary, but future developers would not know. It is currently being considered for Juno (and possible backporting), but it is at 104 comments.
The point here is, adding p2.inf to pde.runtime removes ambiguity. It makes it clear what the provider (PDE) intends for the bundle. Given that "optional greedy" dependencies into JDT make no sense here, it is right for pde.runtime to specify this in its p2.inf -- regardless of the decision on bug 247099. In some sense, bug 247099 is about changing the default behavior for the case where a provider doesn't explicitly specify what it wants. I'm in favor of pde.runtime explicitly specifying. Thus I'd recommend keeping the p2.inf even in Juno, although it will likely be unnecessary - but that depends on the build technology / publisher being used to build the bundle, and such a dependency on the build technology is not good. I can add comments into the p2.inf and reattach if that helps getting it into 3.7.1 (where we need it to pick up into our product).
Ping, can I help moving this forward?
I'm in support of this. We are working at getting M1 fixes and testing done, not at 3.7.1 fixes right now. If you attach a commented p2.inf that would save me some time. I still am concerned that this will have some ramification that hasn't been seen yet, I don't think it will be a problem to backport to 3.7.1.
Created attachment 200784 [details] Patch v2, adding comments into p2.inf Attached is a new patch, adding comments into p2.inf
Thanks for adding the comments. Applied new patch to HEAD. Cloned as bug 354549 to apply to 3.7.1.
This hasn't caused any problems in M2. Marking as VERIFIED.