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

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

> Orbit would need at least 3 URLs
> for integration, milestones, and "releases".

I'll bite and explain this a bit further for discussions sake.  This
right here is the distinction that bothers me.  The way eclipse
defines 'release' with so many levels or degrees of release.

Our general view of the world (speaking for jetty, and at least in
part for the maven community) is that you are either released or not.
Very black and white.  Very clear.

Now we may release an RC release, or a milestone release...but it is
treated no different then an official release.  They are all there,
firm points in time that are durable for all the world to see and use
as they see fit.  Take the jetty-io module:

http://repo2.maven.org/maven2/org/eclipse/jetty/jetty-io/

You can find all of our releases, milestones and release candidates in
one place for that module.  Anyone who wants to use it can find it in
one place.  If they find a milestone works better for them then an
official release, its their prerogative to go right ahead and use
that.  Maybe they need to take some time to rejigger their code before
updating to some new version...whatever the case may be, they have
that single url with the released version of software there.  And they
don't have to copy it someplace special for their own releases.  Also
the metadata in that version (contained in the pom.xml) contains all
the information needed to build that module should they want to pull
the source and tweak it themselves (providing the SCM still lives
somewhere).  This is sane to me.

The issue we ran across originally is that to meet the requirements of
eclipse (as we understood them) was that to put something like the
servlet-api into our jetty-distribution we had to consume it out of
orbit.  So we put it in orbit and because we had to release with it
used the orbit repository it happened to be in....and we jiggered our
build to pull the file out of that orbit repo.  Fast forward a couple
of months and we had an issue reported against a release and we went
back in time to build off of a tag and the orbit repository we were
configured for was _gone_.  Then we had to flail around looking for
another orbit repo that had the artifact in it...and it was
inexplicably a different filename then we had before (we largely
understand why it was different now).  So after getting bit by that
issue a couple of times we opted for the current solution so we always
know where the artifact is.

As for why the bug you mention hasn't had more work done to it, I
suspect its because there are still only a handful of projects that
are in our boat...supporting a much larger community outside of the
'eclipse way' then inside of the 'eclipse way'.  That and its not a
simple task to merge the 'its kinda sorta a release but not really its
only temporary and might disappear sometime unless its the special
one' release model with the 'you are or your not' release model.

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

I hope that further explains the differences, at least as I see them.  :)

cheers,
jesse

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