Bugzilla – Full Text Bug Listing
| Summary: | Bundle remains packed with upack=true set in feature.xml | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Markus Kuppe <bugs.eclipse.org> | ||||||||||||||||
| Component: | Buckminster | Assignee: | buckminster.core-inbox <buckminster.core-inbox> | ||||||||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||||||||
| Severity: | major | ||||||||||||||||||
| Priority: | P3 | CC: | cernst, thomas | ||||||||||||||||
| Version: | unspecified | ||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||
| Hardware: | All | ||||||||||||||||||
| OS: | All | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Markus Kuppe
Created attachment 120471 [details]
example
What's worth to mention is, that a) Bundles set to be unpacked in e.g. "org.eclipse.help" end up unpacked b) Explicitly checking unpack in the "Component query" wizard page doesn't help The problems seems to be that my unpack defining feature is local/source. BM apparently (correctly) materializes the feature into a temporary location (without the feature itself though). Then it continues resolving the dependencies but looses the unpack in nested/child resolutions. BM should either: a. pass the unpack bit from the outer (feature) resolution to the inner (bundle) resolution to set it in org.eclipse.buckminster.core.cspec.AbstractResolutionBuilder.createResolution(IComponentReader, CSpecBuilder, OPMLBuilder). b. org.eclipse.buckminster.pde.cspecgen.bundle.CSpecFromBinary scans the temp location and sets the unpack bit on the bundle (requires an extra field which essentially duplicates the unpack bit from the feature to the bundle). The CSpecFromBinary could either check the temp if the bundle is extracted or use the feature.xml of the parent feature (requires the feature to be copied to the temp location). Created attachment 122791 [details]
patch p1
This patch changes EclipseImportBase to keep the "unpack" bit. EclipseImportReader* and CSpecBuilder offer unpack getters/setters to allow CSpecFromBinary to access this information.
Created attachment 122792 [details]
mylyn/context/zip
Anyway you can modify this patch so that it does not alter the CSpecBuilder? I'm not much in favor of having a pack/unpack attribute in the cspec (nor in it's builder). (In reply to comment #6) > Anyway you can modify this patch so that it does not alter the CSpecBuilder? > I'm not much in favor of having a pack/unpack attribute in the cspec (nor in > it's builder). I don't really see how to get unpack from org.eclipse.buckminster.pde.internal.EclipseImportReader to org.eclipse.buckminster.core.cspec.AbstractResolutionBuilder.createResolution(IComponentReader, CSpecBuilder, OPMLBuilder) without changing CSpecBuilder, unless: a) org.eclipse.buckminster.core.reader.ICatalogReader offers isUnpack() b) org.eclipse.buckminster.pde.cspecgen.PDEBuilder overwrites createResolution(IComponentReader, CSpecBuilder, OPMLBuilder). The derived impl could cast to EclipseImportReader. But it would need to clone the impl from org.eclipse.buckminster.core.cspec.AbstractResolutionBuilder.createResolution(IComponentReader, CSpecBuilder, OPMLBuilder) Created attachment 122794 [details]
patch p2
This one doesn't change CSpec* but overwrites BundleBuilder#createResolution(...)
Created attachment 122795 [details]
mylyn/context/zip
I would suggest option #B in combination with two things.
1. You add an extra parameter 'isUnpack' to the current
AbstractResolutionBuilder.createResolution() method and assign that value to
the ResolutionBuilder.
2. You add an additional AbstractResolutionBuilder.createResolution() that
preserves the current signature by just doing:
protected Resolution createResolution(IComponentReader reader, CSpecBuilder
cspecBuilder, OPMLBuilder opmlBuilder) throws CoreException
{
return createResolution(reader, cspecBuilder, opmlBuilder, false);
}
3. You override the added method in the PDEBuilder så that it, instead of
passing false, passes the value extracted from the reader.
This way you will not have to clone the implementation and you will not cause
any changes in the API (other then adding, but that's non intrusive).
Created attachment 122799 [details]
patch p3
Done as you wish ;-)
Created attachment 122800 [details]
mylyn/context/zip
Patch applied, thanks. With 3.5 a new "Eclipse-BundleShape" bundle header has been defined [1]. It's tracked in bug #157562. It defines whether a bundle remains a jar or has to be extracted during installation. IMO this patch needs to be revised to also check for "Eclipse-BundleShape" and not just "unpack". But maybe the transition to p2 addresses this problem already. [1] http://eclipsesource.com/blogs/2009/01/20/tip-eclipse-bundleshape/ Fix also avaiable in Ganymede 3.4.2 release |