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

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

sure, and I was probably being disingenuous to not align that somewhat
with the nightly releases mentioned, thanks :)

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Thu, Dec 1, 2011 at 10:38, Igor Fedorenko <ifedorenko@xxxxxxxxxxxx> wrote:
> Maven also has SNAPSHOT builds, which are quite similar to Eclipse's
> nightly builds, i.e. they are transient by definition. So the difference
> between Maven and Eclipse build types boils down to retention policies
> -- Maven has two, i.e. "forever" and "not-at-all", and Eclipse has
> couple more inbetween. Dependency from a (more) permanent build to a
> (more) transient build will cause troubles both in Maven and in Eclipse.
>
> --
> Regards,
> Igor
>
> On 11-12-01 11:14 AM, Jesse McConnell wrote:
>>>
>>> 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
>>>
>> _______________________________________________
>> 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
>