Bugzilla – Full Text Bug Listing
| Summary: | unpack="true" doesn't work for customBuildCallbacks | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Jacek Pospychala <jacek.pospychala> |
| Component: | Build | Assignee: | pde-build-inbox <pde-build-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | aniefer, gm.romanato |
| Version: | 3.5 | ||
| Target Milestone: | 3.6 M2 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 293218 | ||
Following is metadata found in repository content.xml generated for above plugin. For some strange reason it's missig instruction "zipped".
<unit id='org.mozilla.xulrunner.win32.win32.x86' version='1.9.1.0_200908251324'>
<update id='org.mozilla.xulrunner.win32.win32.x86' range='[0.0.0,1.9.1.0_200908251324)' severity='0'/>
<properties size='4'>
<property name='df_LT.Bundle-Vendor' value='Mozilla.org'/>
<property name='df_LT.Bundle-Name' value='Mozilla Xulrunner for Windows'/>
<property name='org.eclipse.equinox.p2.name' value='%Bundle-Name'/>
<property name='org.eclipse.equinox.p2.provider' value='%Bundle-Vendor'/>
</properties>
<provides size='5'>
<provided namespace='org.eclipse.equinox.p2.iu' name='org.mozilla.xulrunner.win32.win32.x86' version='1.9.1.0_200908251324'/>
<provided namespace='osgi.bundle' name='org.mozilla.xulrunner.win32.win32.x86' version='1.9.1.0_200908251324'/>
<provided namespace='org.eclipse.equinox.p2.eclipse.type' name='bundle' version='1.0.0'/>
<provided namespace='osgi.fragment' name='org.mozilla.xulrunner' version='1.9.1.0_200908251324'/>
<provided namespace='org.eclipse.equinox.p2.localization' name='df_LT' version='1.0.0'/>
</provides>
<requires size='1'>
<required namespace='osgi.bundle' name='org.mozilla.xulrunner' range='0.0.0.0'/>
</requires>
<filter>
(& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86))
</filter>
<artifacts size='1'>
<artifact classifier='osgi.bundle' id='org.mozilla.xulrunner.win32.win32.x86' version='1.9.1.0_200908251324'/>
</artifacts>
<touchpoint id='org.eclipse.equinox.p2.osgi' version='1.0.0'/>
<touchpointData size='1'>
<instructions size='1'>
<instruction key='manifest'>
Bundle-ManifestVersion: 2
Fragment-Host: org.mozilla.xulrunner;bundle-version="0.0.0.0"
Bundle-NativeCode: /xulrunner/xpcom.dll; selection-filter="(& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86))"
Manifest-Version: 1.0
Bundle-Version: 1.9.1.0_200908251324
Eclipse-PlatformFilter: (& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86))
Bundle-SymbolicName: org.mozilla.xulrunner.win32.win32.x86;singleton:=true
Bundle-Name: %Bundle-Name
Bundle-Vendor: %Bundle-Vendor
Bundle-localization: plugin
</instruction>
</instructions>
</touchpointData>
</unit>
I was debugging this one a little bit and now see that for some reason publisher has BundleShape advice set to "jar" IPublisherInfo argument in org.eclipse.equinox.p2.publisher.eclipse.BundlesAction.createBundleIU(BundleDescription, IArtifactKey, IPublisherInfo) Explicitely adding "Eclipse-BundleShape: dir" solves this problem. However I'm still curious what does drive p2 to set the BundleShape advice to jar in first place. How are you building/generating metadata for this? Without the bundle shape header, by itself the bundle doesn't indicate the shape, and the publisher will default to whatever shape it was on disk. The publisher does consult "advice" when making this decision, this generally comes from the feature, but it is possible to publish bundles without recording the feature advice. I'm using PDE Build configured with p2.gathering=true At first org.mozilla.xulrunner.win32.win32.x86 was plug-in, configured in feature.xml to unpack="true" and it was working correctly - during install it was being unzipped. Then I decided to turn it into fragment, updated plugin manifest to contain Fragment-Host and added fragment="true" in feature.xml and suddenly it has stopped unzipping on install. I haven't been able to reproduce this yet. In your headless build, can you look at the build.xml generated for org.mozilla.xulrunner.win32.win32.x86. There is a publish.bin.parts target, does the <eclipse.gatherBundle> call have an unpack="true" attribute on it? I have found a problem, but it has nothing to do with fragments. Did you add customBuildCallbacks? yes, we use customBuildCallbacks.xml a lot. Our releng project is in CVS under org.eclipse.atf/components/releng/org.eclipse.atf.mozilla.xulrunner.releng However in HEAD it's fixed now, it was broken couple hours ago. fixed customBuildCallbacks problem Hello, I am having the same problem in our PDE-based build system since we migrated to 3.5: all our bundles with customCallbacks don't get unpacked during installation. This issue affects for example our branding plug-ins (custom callback used to edit about.mapping) and our help plug-ins (custom callback used to generate javadoc for API). We will add Eclipse-BundleShape to work-around this problem. Target milestone is set to 3.6 M2, any chance to get this fix into 3.5.2 ? Thank you. |
With Eclipse 3.5 SDK I have a feature.xml which among other contains this: <plugin id="org.mozilla.xulrunner.win32.win32.x86" os="win32" ws="win32" arch="x86" download-size="0" install-size="0" version="0.0.0" fragment="true" unpack="true"/> So it's fragment and should be unpacked during install. Unfortunately it's not unpacked but remains jarred in plugins directory.