[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orbit-dev] orbit bundles to maven central
|
Ok, I have a solution in place for this for jetty now...going to
describe it here for posterity and see if anyone else needs something
similar in which case I'll coordinate a more general solution with
them.
I have created a new maven plugin under
org.eclipse.jetty.toolchain:jetty-orbit-maven-plugin that defines a
custom lifecycle and packaging called 'orbit'
then I setup individual projects for the jar files I need out of orbit
in maven central, for example the javax.servlet 3.0 bundle that was
recently updated to export version 2.6 for the packages...
in a javax.servlet directory I have the following pom.xml
<project>
<parent>
<groupId>org.eclipse.jetty.orbit</groupId>
<artifactId>jetty-orbit</artifactId>
<version>1</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>org.eclipse.jetty.orbit</groupId>
<artifactId>javax.servlet</artifactId>
<version>3.0.0.v201112011016</version>
<name>Jetty Orbit :: Servlet API</name>
<packaging>orbit</packaging>
</project>
and under the src/main/artifacts directory I have the following files
src/main/artifacts/javax.servlet.source_3.0.0.v201112011016.jar
src/main/artifacts/javax.servlet_3.0.0.v201112011016.jar
which are straight out of orbit.
in the lifecycle of it I also unpack the source and generate the
javadoc from the source so that is available as well in maven central.
in here I will be able to run mvn deploy which will deploy it into our
staging repository at oss.sonatype.org where we can review the
artifacts that will ultimately synced to maven central
The will appear under the maven coordinates of:
org.eclipse.jetty.orbit:javax.servlet:3.0.0.v201112011016
The maven-gpg-plugin takes care of generating .asc for all of the
files so everything deploys to central with signing and
checksums...(not internal signing, the jar file orbit remains exactly
what it was in orbit)
I did toy with seeing about putting this setup under dash so others
could use it but I don't know how many others of you suffer from the
current setup enough to resort to this solution.
I figured I would reply to my original mail now that I have a solution
and it clearer what it actually looks like. Ideally we could come up
with a more general solution but I don't know that there are enough
people suffering to make it worth rocking the boat right now. I have
some clean up to do in the plugin and I think I'll get a new git repo
setup for this under jetty so I don't have it all stuffed under our
toolchain setup.
anyway, comments or questions are welcome
cheers,
jesse
--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx
On Thu, Dec 1, 2011 at 10:44, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:
> 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
>>
>
