[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orbit-dev] Addind/Updating Libaries in Orbit
|
Hi, Gunnar,
Welcome to the club!
See some replies in-line, below. For reference, see also http://wiki.eclipse.org/Adding_Bundles_to_Orbit
and http://wiki.eclipse.org/Source_Bundles .
Cheers,
Christian
On 7-Nov-08, at 3:48 PM, Gunnar Wagenknecht wrote:
Hi Orbit Committers,
For our CloudFree project I need/want to update/add content to the
Orbit
project. The purpose of this mail is to socialite feedback from you on
the approach/steps to take.
These are the dependencies which I can't satisfy from Orbit:
Apache Solr 1.3 (including SolrJ Client)
Codehaus Jackson
Google Web Toolkit 1.5.3
Apache Commons CSV
Required by Solr:
Apache Lucene 2.4
StAX Utils (https://stax-utils.dev.java.net/; I asked on the Solr dev
list if that dependency could be made optional)
Should I first submit individual CQs for my project and then for Orbit
or should I first submit CQs for Orbit and then for my project
indicating re-use from Orbit?
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.
Is it ok to submit one CQ which results into multiple Orbit bundles?
For
Every JAR file in the original distro of your 3rd-party package
requires a separate CQ, as JARs are the unit of deployment in Java.
example, Solr is provided as one single zip. It includes the full
source. However, for Orbit it would make more sense to split it across
different bundles (eg. solr.common, solr.core, solr.servlet,
solr.client.solrj, solr.client.solrj.embedded) which allows a more
fine
grained consumability and clearer dependencies in manifests.
You can do this at your peril. I had a nightmare with Apache Batik,
which actually is distributed in 16+ JARs. I tried to map them 1-
for-1 to OSGi bundles, but had to consolidate three of them that
formed a dependency cycle, and split another one into three because it
combined a bunch of distinct W3C APIs.
It was not a pleasant exercise.
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.
Lucene is already in Orbit but in an older version. I also found out
that the bundle in Orbit is missing the org.tartarus... packages. It
seems like there need to be separate CQs for the various Lucene
contribute source. There is actually CQ2603 but that's for the old
version too.
Yes, we absolutely *love* to host multiple versions of the same libs.
You will need new CQs for any new versions or new content from old
versions.
-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
