[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orbit-dev] orbit bundles to maven central
|
> ...I figured I would first see if anyone would
> be adverse to my asking to get a git repo setup for orbit maven
> central artifacts and setting up a maven build that would allow for
> people to push out specifically versioned orbit bundles to maven
> central ...
This does not sound like the right approach, to me. Though, I am sure, I do
not understand it completely.
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.
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? How
compatible is your "patched jsp implementation" with the original
javax.servlet.jsp implementation? Are these all "for juno" versions you
simply want early? Or are they from old Indigo I-builds or S-builds which
later changed by the time the R-build came out? I'm sure there are answers
to all these questions ... but, I think those types of discussions should
happen, rather than just "doing your own thing".
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.
= = = = =
> That does sound more like a process issue rather then a technical one. I
> think Orbit should produce promoted releases more often if downstream
> consumers need them.
> David might have more insights into the process, though.
We can have a "release" (promote a build to recommended status) whenever an
Orbit committer asks for one, and the committers of Orbit agree. The main
issue would be whether to have a "maintenance" release (based from previous
release, with minimal changes) or something "all new", like we normally do
only yearly. The former being my usual preference as it reduces risk to the
general population of adopters ... but ... there could be exceptions. (and
have been, in the past. granted, just once, if I recall right).
> imo orbit ought to produce fully versioned artifacts once
> and put them in one place that is durable for all time...and when that
> artifact changes, produce a new versioned artifact alongside the other
> one.
There is a reason that is not done ... it is because no one has volunteered
to do it. (To paraphrase some famous person whose quote I can't find right
now so I wont' guess.)
Bug 289092 [1] has been opened a long time, marked "help wanted" for a long
time ... and with all the many people that say how much they would like
this, and as easy as it would be to do, no one has come forward to do it.
Why is that? I personally do not need it. The projects I work on don't need
it. The builders I use easily take variables for repository URLs ... so if
anyone wants something else ... well, I don't need to dwell on how open
development works.
The one caveat I would make is that I am a firm believer in a progressive,
iterative cycles of producing product-ready code, so I take the
"integration", "milestone", "released" cycle seriously and consider it
necessary, even for Orbit bundles. So the only thing I would be hesitant
about is some notion that "each and every bundle we produce directly goes
into some one, persistent, common URL repo and stays there. There's always
mistakes that have to be corrected, and think we'd be asking for trouble
and doing the community a disservice if we allowed bundles "out into the
wild" before they'd been through at least a few test cycles.
But, that said, if someone has a need for more frequent (maintenance)
releases, please ask and discuss.
Hope these tidbits help. I am quite interested in making improvements to
our processes and I am sympathetic to others situations so don't be put off
if my tone comes across as a bit negative. I always react that way when I
hear someone say "I don't like the the way you do things, and I want you to
do more work for me" ... which I know is not exactly what is being said ...
but it sort of comes across that way, given the long history of some of
these issues and some of the innuendo of some of the long notes on the
topic over the years and inaction on bugs that would improve the situation.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=289092
= = = = = = =
So, please keep the discussion going. I'm sure you have problems I do not
understand ... but, I am willing to try and understand, and give guidance
and free advice if I can (any programming effort will cost you extra :)
From: Jesse McConnell <jesse.mcconnell@xxxxxxxxx>
To: Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>,
Date: 11/30/2011 10:41 AM
Subject: Re: [orbit-dev] orbit bundles to maven central
Sent by: orbit-dev-bounces@xxxxxxxxxxx
Below are the objects we have poached from various orbit builds over
the past couple years and placed into:
http://download.eclipse.org/jetty/orbit/
With these dependencies in this directory our previous releases (since
we adopted this) can be checked out and built successfully.
Now, I would _like_ to take these and put them into maven central so
moving forward we can move away from having to use hackish maven
conventions to get artifacts into place for our traditional
distributions, but I absolutely need to put the latest jsp ones into
maven central someplace for our jetty-maven-plugin to have the support
of the patched jsp implementation (for example, issues with glassfish
impl atm is a) have to have a jdk b) it has to be jdk 6 or above c)
you can't use ecj).
So...since gunner mentioned I could perhaps use the org.eclipse.orbit
groupId in maven central...I figured I would first see if anyone would
be adverse to my asking to get a git repo setup for orbit maven
central artifacts and setting up a maven build that would allow for
people to push out specifically versioned orbit bundles to maven
central under the coordinates of: (using some of the below as
examples)
org.eclipse.orbit:com.sun.el:1.0.0.v201004190952
org.eclipse.orbit:javax.servlet.jsp:2.2.0.v201103241009
I would probably have the ejc one as
org.eclipse.orbit:org.eclipse.equinox.ecj:3.6 or something akin to
that depending on where its actually from.
If this is more then anyone is willing to accept at this point, I'll
just wire something similar up under org.eclipse.jetty.orbit and call
it good, but I figured if there was interest I could see about
spending some time setting up something more generally useful for
others. No guarantee's but I would at least look into it for a spell
if there was interest. I just don't see an automated solution
surfacing of putting orbit artifacts into central anytime soon as the
release models just seem so widely divergent.
com.sun.el_1.0.0.v201004190952.jarcom.sun.el_2.2.0.v201105051105.jarecj-3.6.jarjavax.activation_1.1.0.v201005080500.jar
javax.activation_1.1.0.v201105071233.jarjavax.annotation_1.0.0.v20100513-0750.jarjavax.annotation_1.1.0.v201105051105.jarjavax.el_2.1.0.v201004190952.jarjavax.el_2.2.0.v201105051105.jarjavax.mail.glassfish_1.4.1.v201005082020.jarjavax.servlet_2.5.0.v200910301333.jarjavax.servlet_3.0.0.v201103241727.jarjavax.servlet.jsp_2.1.0.v201004190952.jarjavax.servlet.jsp_2.2.0.v201103241009.jarjavax.servlet.jsp.jstl_1.2.0.v201004190952.jarjavax.transaction_1.1.1.v201004190952.jarorg.apache.jasper.glassfish_2.1.0.v201007080150.jarorg.apache.jasper.glassfish_2.1.0.v201110031002.jarorg.apache.jasper.glassfish_2.2.2.v201108011116.jarorg.apache.taglibs.standard.glassfish_1.2.0.v201004190952.jarorg.objectweb.asm_3.1.0.v200803061910.jarorg.objectweb.asm_3.3.1.v201101071600.jar
cheers,
jesse
--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx
On Wed, Nov 30, 2011 at 07:44, Jesse McConnell
<jesse.mcconnell@xxxxxxxxx> wrote:
> honestly, imo orbit ought to produce fully versioned artifacts once
> and put them in one place that is durable for all time...and when that
> artifact changes, produce a new versioned artifact alongside the other
> one...like a maven repository :)
>
> that would be infinitely more usable (from a raw maven perspective)
> then producing the equivalent of multiple discrete repositories of
> artifacts that you have to surf into to track down a specifically
> versioned artifact. anyway, old argument...
>
> jesse
>
> --
> jesse mcconnell
> jesse.mcconnell@xxxxxxxxx
>
>
>
> On Wed, Nov 30, 2011 at 07:21, Gunnar Wagenknecht
> <gunnar@xxxxxxxxxxxxxxx> wrote:
>> Am 30.11.2011 14:14, schrieb Jesse McConnell:
>>> mostly because we have our 'releases' against things that were in
>>> early builds of orbit (from the orbit release perspective) and we have
>>> had a number of instances where we checked out an old release tag and
>>> it wouldn't build because the orbit repo it needed was gone. so to
>>> make our old releases actually build we couldn't rely on orbit repos
>>> any longer
>>
>> That does sound more like a process issue rather then a technical one. I
>> think Orbit should produce promoted releases more often if downstream
>> consumers need them.
>>
>> David might have more insights into the process, though.
>>
>> -Gunnar
>>
>> --
>> Gunnar Wagenknecht
>> gunnar@xxxxxxxxxxxxxxx
>> http://wagenknecht.org/
>> _______________________________________________
>> 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
