[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orbit-dev] Addind/Updating Libaries in Orbit
|
Hi, Gunnar,
As I understand the process, a CQ requests permission to adopt a third-
party JAR. The CQs do not indicate how that JAR is to be published at
Eclipse.org as OSGi bundles or what have you. However, the IP
tracking for any Eclipse bundle (in Orbit or otherwise) must reference
the CQs of all third-party JARs that contributed to it. So yes, to
reuse a single bundle, clients may have to raise multiple PB CQs.
However, the piggy-back process is very light because of the due
diligence already done for the original requesting project, so it
usually turns around quickly and easily.
In the past, components like Lucene and even Batik were CQ'd as a
single bundle. EMO is tightening that process, so that this year the
Batik 1.7 adoption comprises 16 CQs (or thereabouts).
I agree with you that, in principle, it is advantageous to align your
Lucene bundles with the original JAR structure as much as possible,
for finer-grained reusability. That is, assuming that the original
JARs were so organized in order to promote reusability. I took this
approach with Batik primarily because I don't know Batik at all, and
was bundling it on behalf of the Modeling project which I "represent"
here in Orbit-land.
The main difficulty that I had was in keeping OSGi's classpaths sane
in the face of multiple different qualifiers of the same bundle
versions being installed (1.6.0). The package exports and imports
don't have qualifiers, so the wiring was going haywire. Added to
this, most of the clients of Batik in Eclipse don't reference it using
Import-Package but rather Require-Bundle. The package imports
internally between Batik bundles didn't play nicely with the Require-
Bundle dependencies from the world outside. In the end, I went with
Require-Bundle dependencies to resolve this problem. Plus, I managed
to convince myself (with my fellow Orbiters) that it makes sense,
anyway, because the original Apache Batik deployment is a tightly
coupled bunch of JARs, so this preserves those semantics as accurately
as OSGi can.
One note: the Batik distro includes a few org.w3c API packages, which
I separated out into their own bundles. I did reference those from my
Batik bundles with Import-Package because I know that they are also
provided by some other bundles (and the JRE, too, possibly) and
because they are external to Apache development.
HTH,
Christian
On 10-Nov-08, at 9:08 AM, Gunnar Wagenknecht wrote:
Christian W. Damus schrieb:
You should submit first the CQs for contribution to Orbit, then (once
those are approved) the piggy-back (PB) CQs for re-use of these
bundles in your project.
Turns our that I can't submit Orbit CQs. Thus, I started submitting
CQs
for my project first.
In the end, I wish I had produced only one Batik bundle (with the W3C
content separate), but it works, so I'm not planning to refactor it.
Same is true for Lucene. They have split packages and maybe also
cyclic
dependencies. At this time, I have the bundles but they don't
resolve at
runtime.
However, I hesitate to create a single bundle for all the JARs because
this would make consumability tricky. I'm not an expert on that
subject
but if I submit individual CQs for each jar and now combine the jar
into
one bundle then all bundle consumers will need fill multiple CQs for
re-use. This complicates things too. It requires to track the CQs per
version and instruct consumers to submit the right CQs.
Thoughts?
-Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
--
Christian W. Damus
Senior Software Developer, Zeligsoft Inc.
Component Lead, Eclipse MDT OCL and EMF-QTV
E-mail: cdamus@xxxxxxxxxxxxx
