Re: [orbit-dev] orbit bundles to maven central

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

> First ... and this isn't my call ... pulling something from maven central,
> to use in an Eclipse release, I do not think is currently covered by the
> Eclipse IP policy. But, I'll let the Eclipse IP experts discuss/decide
> that. Perhaps it is and I have just never heard of it before.

well, this starts getting back to defining 'release' which history as
taught me means something completely different to eclipse, but yes we
have jumped through amazing hoops to try and adhere to the spirit of
'release' within eclipse, hence this hacked up pulling out of our
download directory stuff that once lived in some integration orbit
repository before it disappeared.

I really shouldn't consume these bundles out of maven central for our
eclipse distribution, but I the jetty-maven-plugin isn't an eclipse
release, its released out of codehaus which has no such restrictions.
Also our hightide release is also out of codehaus as well which could
also consume these from central if we configured it like that.

> My main concern is this sounds like a divergent effort to "do your own
> thing" ... certainly you and your company's right to do your own thing ...
> but ... it raises questions ... if not problems ... for other Eclipse
> projects. How compatible are these versions, with versions in Orbit?

The versions and bundles I want to put into central _are_ the goop in
orbit that will one day work their way into a durable p2 repository.
The only reason we had to cobble this together in the first place was
to honor what we were told were hard and fast rules within eclipse.
So there is no company forcing us to do it one way or the other...its
that our user community requires jsp support in the jetty-maven-plugin
(again, not being released as an eclipse anything) and with the recent
change to how we are CQ'ing the glassfish repo we don't start out
having that patched artifact in central anymore.

> And, I wonder ... and I could be misunderstanding ... how much of this
> problem you are having may just be because you never realized you could ask
> for an off-cycle Orbit release? Here is a long wordy response to recent
> posts that I have been brooding over in my "drafts", but will send it
> now ... wordy as it is ... since it addresses this and another issue, in
> case it helps.

This could be it in part, I still fail to understand the reasoning
behind orbit's release strategy...it just seems to alien to me.

However at this point I have a hard requirement that some goop that
exists solely in orbit now has to exist in maven central.  Previously
we would patch glassfish jsp source so it would be more generally
useable and then we would get that CQ'd, it used to live under
org.mortbay.jetty.jsp in maven central.  Since we have lately switched
to getting the actual glassfish artifact that they now release into
central (previously they went into java.net repo but that is in
central which was another reason we would wrap in our own groupId into
central) CQ'd and patching them within the eclipse orbit process, we
no longer have them in maven central for our jetty-maven-plugin to
use.

I should note, our patches to these things have been opened with that
community and are not jetty specific, we have worked with virgo/gemini
I believe on trying to align all of us onto one implementation of jsp
with this effort.  We simply need this stuff exposed to maven central
so normal non-eclipse people and the non-eclipse portion of our
project can use it.

Anyway, your response is enough for me to drop the idea of using the
org.eclipse.orbit groupId in maven central, it probably is best to
leave that open for the eventual day when orbit decides to release a
single durable p2 repository containing everything for all eclipse
releases and then that can be synced into that groupId.  I look
forward to those conversations on here when we get closer to cvs being
shutdown and the inevitable migration to git :)

cheers,
jesse