Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338405

Summary: [aggregator] p2 site built with aggregator does not unpack plugin
Product: [Technology] CBI Reporter: David Samuelsson <david.samuelsson.se>
Component: CBI p2 Repository AggregatorAssignee: Project Inbox <b3.aggregator-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: david_williams, thomas
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
p2 site built with aggregator reproducing the problem. none

Description David Samuelsson CLA 2011-02-28 07:18:20 EST 
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
Comment 1 David Samuelsson CLA 2011-02-28 07:20:02 EST 
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
Comment 2 David Samuelsson CLA 2011-03-01 04:56:04 EST 
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.
Comment 3 Thomas Hallgren CLA 2011-07-08 12:09:51 EDT 
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.
Comment 4 David Williams CLA 2016-09-16 15:57:55 EDT 
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI.
No change to assignee for resolved and verified bugs.]