Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Understanding how to get version 3.1.3 of Apache XML RPC in Orbit

Thanks Roland,

That already helps, it seems I misread the CQ approach.

As Triquetrum committer I could become Orbit committer for this.
Of course if there is an existing Orbit committer who volunteers to do the Orbit work, that would be ok for me ;-)

I'll do some more reading and try to do the ATO CQ. Shouldn't I be an Orbit committer first to be able to do that?

thanks
erwin

Op 30/06/2016 om 21:57 schreef Roland Grunberg:
Hi Erwin,

For Triquetrum we would need to use Apache XML RPC 3.1.3 as (works-with)
dependencies. And we would prefer to have them as bundles in Orbit.

We've found a couple of other Eclipse projects that use the 3.1.3 as well,
but as plain binary jars embedded in their bundles.
Yes, it seems like Apache XML RPC 3.1.3 is already approved in CQ 5204. This
means individual projects are likely bundling it into their projects with
Bundle-ClassPath (not recommended), or bundling it into their generated p2
repositories and depending on it. Of course the ideal course of action is
to contribute it to Orbit so that all projects can reference the repo Orbit
would publish.


Orbit currently only contains 3.0.0 , based on
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2196 (from Jeff McAffer)

I've been reading the Orbit Wiki about how to get something added and am
honestly a bit "impressed" with the work to be done ;-)
You would need to be an Orbit committer before being able to contribute
anything. Generally the requirements are being a committer on another
project at Eclipse and of course committing to maintain the package(s)
you wish to contribute.

Yup, the CVS approach can be pretty complicated. Even after having
contributed ~25 bundles I'd still need to look at the docs page to confirm
I'm not forgetting anything.


Some first practical questions :


Q1. XML-RPC 3.0.0 is still in Orbit CVS. Should we try to get the 3.1.3 in
there as well? Or do we go for the Git and EBR approach now?
My personal preference would be to go for Git + EBR (if I understand the info
correctly).
No experience yet with EBR but this seems to be the future-proof way to go
for bundling 3rd-party deps?
I would say the Git+EBR approach, although in all honesty, there's some things
we need to work out first. At Orbit, we'd like to migrate to using only
Git+EBR but there's still the matter of having the generated repositories as
being "official". I've been in contact with Gunnar and David in the hopes of
getting everything in place.


Q2. the 3.0.0 seems to bundle the 3 apache jars in one bundle (commons,
client & server). I would prefer to provide 3 separate bundles for that.
How does that impact the approach? E.g. this does not correspond to the
current CVS structure for head & branching.
Providing 3 separate bundles (as I assume the upstream project does) is
preferred. I think if you were contributing to CVS, you would have to
create new modules for core, client and server matching
Bundle-SymbolicName for those packages. The older module would remain
unused.. unless someone wanted to bundle everything together for 3.1.3
as well.


 From the Wiki pages (long & short) about adding new bundles in Orbit :


I will already request 3 CQs on Triquetrum.

Q3. We're in Parallel IP so I could also already start committing the
original Apache class files in 3 bundle projects in CVS or Git?
Are you referring to https://dev.eclipse.org/ipzilla/show_bug.cgi?id=11656 ?
I believe this only gives you approval to distribute Apache XML RPC 3.1.3
as part of your project, but it does not give you permission to contribute
it to Orbit. You need to file an ATO (Add To Orbit) CQ against CQ 5204 to
distribute in Orbit.

 From there you would file a PB (Piggyback) CQ from your project to the
ATO CQ you created just to keep track of your usage of the library through
Orbit. The latter CQ wouldn't take very long to approve.


Cheers,




Back to the top