Community
Participate
Working Groups
Eclipse-BundleShape ::= type type ::= ('jar' | 'dir') Once it is supported by the rest of Eclipse, that is. I'm just opening this bug to track. Bugs to watch: Bug 157562 to track documenting the header bug 217005 to track changes to PDE-Build. bug 217006 to track changes to p2. bug 217007 to track changes to PDE-UI. bug 217009 to track changes needed for jnlp.
assigning to myself just to have an owner
David, not sure if it is still necessary to keep this one open. Did you have specific bundles in mind?
(In reply to comment #2) > David, not sure if it is still necessary to keep this one open. Did you have > specific bundles in mind? No nothing specific in mind ... more like all those that currently have "unpack-true" in the feature.xml (or map file?). It was mentioned once (on mailing list?) as maybe something we should do "in mass". (The directive didn't exist when we started Orbit ... added in 3.6?). It seems like a "good way" to do it ... but, not sure if it is in wide spread use or if there is a true "need". If no one (else) chimes in, then I agree, we should probably close this "in mass" bug, and update the "how to add a bundle to Orbit" directions, so committers can use it moving forward, but otherwise just "fix" those where there is a specific request.
assigning back to inbox (to signify there is no true assignee that's working on this) and marked as "helpwanted" to signify that if someone desires this change in mass, then they should take ownership and direct us as to what needs to happen.
We noticed that Orbit bundles that should be unzipped (e.g. org.apache.axis) don't get exploded when provisioning a product using Tycho's eclipse-feature packaging type: http://wiki.eclipse.org/Tycho/Packaging_Types#eclipse-feature . Tycho apparently expects the Eclipse-BundleShape header to provision the bundles as expected. It seems that it would be fairly important that the Orbit bundles that need to be unzipped would specify the header or is there another way to correctly provision Orbit bundles with Tycho?
Here is some more background why Tycho ignore the unpack flag in the feature.xml: https://issues.sonatype.org/browse/TYCHO-555
I certainly don't mind committers adding Eclipse-BundleShape to those Orbit bundles that want to be unzipped. But, the rest of what you say is a little disconcerting. I think the way the rest of Eclipse (not sure if its PDE, p2, or both) takes the Eclipse-BundleShape as a "hint" of what to do, but the feature specification is given priority. As far as I know. To do otherwise would have the potential to be breaking behaviour. I personally do not know of anyone who uses a feature specification to "go against" what is in an Eclipse-BundleShape directive ... but ... seems it should get some good community exposure, discussion, warnings, etc. if there is some big change coming. The "directive" to unzip or not eventually becomes part of the p2 metadata directive (right?) but I think in an ideal OSGi world, its expected that the consumer/adopter of a bundle could in theory have control if its left jarred or takes the 'dir' shape. This larger issue does not sounds like _this bug_ (which is just about adding the directive to Orbit bundles) but appreciate you pointing out the issue and giving some background.
Sorry for posting information in small bits. The more I read about this, the more I realize that we haven't gotten to the bottom of our build problem. As you point out the problem that bundles are getting unpacked is not related to the header not being specified in Orbit bundles. The meta-data on the Orbit site looks correct, e.g. for org.apache.axis it specifies in the content.jar: <touchpointData size='1'> <instructions size='2'> <instruction key='zipped'> true </instruction> ... If I understand the Tycho issue correctly this would only be a problem if Orbit decided to use Tycho for building. In this case the meta-data generated for the repository would be missing the 'zipped' touchpoint instruction regardless of unpack attribute specified in the feature (as Tycho would only honor the manifest header). Thanks very much for listening though.
> > If I understand the Tycho issue correctly this would only be a problem if > Orbit decided to use Tycho for building. In this case the meta-data > generated for the repository would be missing the 'zipped' touchpoint > instruction regardless of unpack attribute specified in the feature (as > Tycho would only honor the manifest header). Thanks very much for listening > though. I think this is correct. I checked our feature.xml and there are currently only 6 that are expected to be "unzipped": org.junit org.apache.ant org.apache.axis javax.xml.rpc javax.xml.soap org.apache.commons.discovery I check the Eclipse Platform, and org.junit, and org.apache.ant are indeed unzipped ... so Tycho "copies" not only the artifact, but also the metadata ... whew.
We can also imagine that if one day, Orbit only builds bundles and no feature, the "unpack" metadata would get lost. That's why it would make sense to use Eclipse-BundleShape instead of a flag in feature.xml, and to rely on it to create p2 metadata. Tycho generates metadata for each bundle, and then consumes them (without modifying them because modifying p2 metadata is evil according to p2 folks). That's why Tycho relies on Eclipse-BundleShape rather that the unpack flag, because it doesn't know the flag in the feature while generating p2 metadata.
This issue also affects Orbit consumption in tycho-surefire-plugin. Cf bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=416982 (comments 3 and 5)
I think we're now in a state where orbit recipe based bundles can easily add "Eclipse-BundleShape: dir" to their osgi.bnd if necessary. This won't fix already existing older bundles, unless they get moved over to the EBR side but it certainly improves things. Marking as CLOSED (FIXED)
