Community
Participate
Working Groups
Created attachment 189935 [details] p2 site built with aggregator reproducing the problem. i mirror certain IBM plugins, and they have yet not converted their builds to P2 (err..this is IBM..hello!..ahh well) format. the site in question is: http://www3.software.ibm.com/ibmdl/pub/software/rationalsdp/clearcase/60/update/windows/ it only has an site.xml in the root. When i mirror this with the B3 aggregator it creates p2 metadata naturally of the process. Trying to install from that aggregated site into an Eclipse 3.6.1 suceeds but all plugins is supposed to be unpacked on target, which it doesn't so you end up with an error in the error log after installment: like: java.lang.UnsatisfiedLinkError: Expecting an absolute path of the library: file:\C:\WS\Eclipse\plugins\com.rational.clearcase_7.5.0.v201010151645.jar! \RSCMRegistryJni.dll which indicates it needs the plugin unpacked. if i install the clearcase scm plugin from their updatesite (old format with site.xml) it suceeds without problems. I attached an built p2 site which recreates the problem. This goes way over my p2 knowledge but ill will help in anyway to locate where the problem can be. also see: http://www.eclipse.org/forums/index.php?t=rview&goto=656497#msg_656497 best regards David
some versions i forgot: b3 Aggregator Engine (Incubation) 0.1.0.r01408 org.eclipse.b3.aggregator.engine.feature.feature.group b3 Aggregator Editor (Incubation) 0.1.0.r01408 org.eclipse.b3.aggregator.editor.feature.feature.group windows xp sp3 Eclipse 3.6.1
I located where the problem is in the content.xml at least, i installed the plugins from the "old" site with an site.xml into an fresh eclipse, exported that feature from the PDE with an export feature, i then compared the metadata produced by the PDE exporter an the one created by the b3 aggregator. the main difference i found was this line: </instruction> <instruction key='zipped'> true </instruction> removing this line from b3 generated content.xml casues the plugin to be installable, i.e it unzips the plugins as needed. also found another bug on the way but that seems to be PDE specific so i won't mention that here.
The 'zipped' instruction means that the artifact is in zipped format and should be unzipped. Removing 'zipped' instruction will have the opposite effect from what you describe here. The bundle will no longer get unzipped. With that in mind, I examined what happened and found the cause. Since no p2 meta-data exists on the site, this data is synthesized by the p2 resolver. This happens in two steps. Step one will create an approximation that is good enough to present to the installer. In this step, all bundles will be represented by an interim installable unit that isn't yet complete. This interim unit is generated based on feature content only. In the old days, the zipped status of a bundle was actually maintained by the feature. This means that the interim unit now contains the 'zipped' instruction. The problem occured during step two, when the interim bundle is converted into a fully fledged bundle based on the manifest found in the actual bundle jar. Old bundles doesn't have any "Eclipse-BundleShape: dir" header so the information from the feature was simply forgotten when the interim unit was replaced. This is now fixed so that the 'zipped' instruction that stems from the feature meta-data is retained when the bundle is converted. The fix is in revision 1505 and will be available in the next build.
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. No change to assignee for resolved and verified bugs.]
