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

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

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