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

[David M Williams <david_williams@xxxxxxxxxx>]

> 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.

Maybe this is easy to clear up. Orbit doesn't release.  Eclipse projects
do, and they use bundles from Orbit, obviously, so if they want to use a
bundle that is not part of an "R build" they are responsible for keeping
their own copy (and/or working with Orbit before hand, to provide an off
cycle R build). As far as I know, most projects, even when releasing "off
cycle" seldom have a need to use a bundle that is not already part part of
an Orbit R (since often provided 3 times per year). I will be interested if
others voice this confusion or problem, now that you have brought it to
light and started this discussion. If anyone knows of other projects that
were "forced" to use an Orbit I build (or S build) for some reason, please
let us know (and, let us know why).

> ... hence this hacked up pulling out of our
> download directory stuff that once lived in some integration orbit
> repository before it disappeared.

Ok ... made me look ... at the URL you provide, you list 22 bundles. If I
am seeing things right, 12 of them are part of an Orbit R build, one of
them is not an Orbit bundle at all (but from JDT?), of the remaining 9, 4
of them appear "early" versions of Juno versions and only 5 appear to be
some I-build version that did not survive to the R build. I'm not sure
why .... what bug was fixed ... or why you needed that particular I build
version instead of the previous R build version .... but, there are reasons
why we have the the iterative cycles (to find problems) and simultaneous
releases  (to be coordinated). One of the ones you apparently released
early, javax.servlet_3.0.0.v201103241727.jar sounds like it may have been
"wrong" if it exports packages at version 3.0 as we have all discussed in
bug  360245 [1] ... and not that you would have been the only one in the
industry to do so ... just highlighting some advantages to the methods
behind our madness. :)

Bottom line, it sounds to me like it is the "one and only one URL" issue
that your builder or process require, that is your biggest problem ...
which takes me back to my confusion over why bug 289092 is given no
attention by those that need it, or, as Wayne mentioned, how/why the Dash
project and maven.eclipse.org doesn't get some lov'en. Though, to repeat
myself, hard for me to imagine there  could ever be exactly only one URL
possible ... since, as some projects do, Orbit would need at least 3 URLs
for integration, milestones, and "releases".

Thanks for the discussion and education. I sincerely hope my comments help
educate also, to further constructive discussions.



[1] Bug 360245 - javax.servlet package versions for the Servlet 3
specification
https://bugs.eclipse.org/bugs/show_bug.cgi?id=360245




From:	Jesse McConnell <jesse.mcconnell@xxxxxxxxx>
To:	Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>,
Date:	11/30/2011 04:11 PM
Subject:	Re: [orbit-dev] orbit bundles to maven central
Sent by:	orbit-dev-bounces@xxxxxxxxxxx



> 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
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev