I'm in the same situation with Apache
Batik, which comprises 16 jars as a base distribution.
The GMF project currently bundles Batik
as a single org.apache.batik_1.6.jar bundle, with these 16 jars nested
inside and all listed on the Bundle-Classpath. This also has the
advantage of preserving Apache's jars in their original form. It
doesn't allow for pack200-ing, but the wrapper bundle can be signed by
Considering the fact that these 16 jars
are commonly used together, I'm currently of a mind to prefer this approach
(although one or two of the JARs are not actually Batik code, such as the
W3C SVG DOM implementation, so I would be inclined to break them out into
I'll be interested to hear other Orbiters'
reflections on this. I think this may be a good middle ground between
a proliferation of bundles and actually combining all of the Batik packages
"directly" into a single JAR.
[orbit-dev] Packaging 3rd party libs
I have Jakarta ORO 2.0.8 and Commons Net 1.4.1 that I'm
going to contribute to Orbit.
Currently, these are bundled very similar to the Platform's
ANT bundle, i.e. the original, verbatim JAR file from
Apache is in a subdirectory plus some additional files
around it (about.html, Manifest.mf etc).
The advantage of this setup is that the original JAR is
binary unmodified, but there are some disadvantages:
* The bundle must be expanded at the client - but
it's good Eclipse Citizenship to have single-jar bundles
* The bundle cannot be both pack200'ed and signed at the
same time, but this would be recommended for Europa
Because of that, I'm considering changing the build process
in order to produce single-file JARs. Does anyone here have
any experience with this?
- Any potential legal issues with extracting the original
vendor's binary jar and repacking it into the new jar?
- Any existing ANT scripts to do the extract - repack step?
- Anyone else interested in getting this done?
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
orbit-dev mailing list