Re: [orbit-dev] Packaging 3rd party libs as single-jar-bundle?

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

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.

Jeff

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>

To	Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
cc
Subject	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. 

Cheers, 

Christian

---

Christian W. Damus
Component Lead, MDT
UML2 OCL and EMFT-QTV
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>

To	"Orbit Developer discussion" <orbit-dev@xxxxxxxxxxx>
cc
Subject	[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, 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
 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=163421)

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?

Thanks,
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev