Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Packaging 3rd party libs as single-jar-bundle?

Some comments on both Martin and Christian's messages

- as far as we have seen, there are no legal implications of modifying a JAR that comes from someone else.  That of course depends on the license but so far no one in the vast legal community looking at Eclipse has had a problem.

- Note that injecting OSGi metadata into the JAR is equivalent to signing the JAR.  Signing adds a few files and modifies the manifest.  Bundling may add a few files and modifies the manifest

- Our Pack200 and signing support DOES allow you to both sign and pack nested JARs.  Note that again here, if you want to do both you have to pack, unpack, sign and then repack for technical reasons.  This could also be seen as a modification of the JARs.

- In general the trend has been towards one bundle per JAR.  The overarching guideline that covers bundle scope is this
        "If two bundles will always ship together or reasonably needed together, combine them.  Otherwise ship keep them separate"
I think we should apply this logic to Orbit.  Certainly separating out "fourth party" JARs (e.g., Batik's W3C SVG DOM) into a reusable bundle makes alot of sense.  I don't know enough about Batik code/package structure and usecases to comment on the rest.


Christian Damus/Ottawa/IBM@IBMCA
Sent by: orbit-dev-bounces@xxxxxxxxxxx

12/06/2006 08:50 AM

Please respond to
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>

Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
Re: [orbit-dev] Packaging 3rd party libs as single-jar-bundle?

Hi, Martin,

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 Eclipse.

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 separate bundles).

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.



Christian W. Damus
Component Lead,
IBM Rational Software

"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
Sent by: orbit-dev-bounces@xxxxxxxxxxx

12/06/06 07:07 AM

Please respond to
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>

"Orbit Developer discussion" <orbit-dev@xxxxxxxxxxx>
[orbit-dev] Packaging 3rd party libs as single-jar-bundle?

Hi Orbit,

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, 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?

Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
orbit-dev mailing list

orbit-dev mailing list

Back to the top