Hi,
I’m the new guy. Thanks for your votes. I don’t want to bore anyone, so just some very short remarks: I am currently a Java developer working for SAP and very active in the Skalli project. Next to coding I also do lots of infrastructure work like beautifying
and keeping Maven builds together, finding p2 repos and providing quality plugins. We are having quite a busy time here so it’s only now that I can start thinking about Orbit contributions. And here we go:
There we have a list of several third party libraries which Skalli is using and which are mainly not or only with older versions in the orbit currently. Since the CQs took quite a while to get through or we didn’t have needs for newer versions, some of
the requested components do not reflect the most current version.
- How do we deal with such components? Is there a guideline? IMO there is quite a high probability that a newer version is released during the CQ time.
I have prepared a short overview of the components I am talking about. These are all minimum versions required by us, older versions e.g. for lucene do not work as needed (CQ=what was requested and cleared already for us, Out=most current version, Orbit=version
in latest R… orbit):
3 CQs: Apache Lucene Core, Highlighter, Queries 3.0.2
Out: 3.3
Orbit: 2.9.1
CQ: xstream 1.3.1
Out: 1.3.1
Orbit: none
3 CQs: Restlet API, Servlet Extension, XStream Extension 2.0.5
Out: 2.0.8
Orbit: none
CQ: XMLUnit 1.2
Out: 1.3
Orbit: none
CQ: xmlpull 1.1.3.4b
Out: 1.1.3.4c
Orbit: none
- We could piggy back on these existing CQs now pretty fast and I could create the missing CQs, new branches and projects as needed. I would try to follow the “Adding bundles to orbit” guide. Are there any objections or additional thoughts?
- Since this, if agreed, would be my first contribution is there someone who could double check what I do in the repo just to make sure I don’t go into the wrong direction?
Greetings, Robert
- Off topic: Are there any plans yet to move to git with the Orbit project?
