geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Creating an openejb version for the Geronimo M1 release.
Date Thu, 06 May 2010 19:46:12 GMT

On May 6, 2010, at 11:56 AM, Rick McGuire wrote:

> We need to make a decision on how to handle getting a non-snapshot version of openejb
for the Geronimo M1 release.  In the past, we've handled this by having a local repository
in the build that copied a revision pinned version in the local maven repository to do the
build.  This type of processing is at best frowned upon by the maven release plugin, and might
even be specifically forbidden.
> 
> The openejb community is probably weeks away from having code in a state that they would
be comfortable shipping as a visible milestone, which is a bit of a problem for getting a
Geronimo M1 release out soon.  If we're going to ship something, then it really will have
to be a private build of some kind.

Right.  I'll add that the recent 3.0.2 release voting took a bit over two weeks to complete
even with the "for Geronimo 2.1.5 only" disclaimer -- and that branch has been inactive since
'08.  We'd be looking at at least that long for a trunk release of any kind.

> We already sort of have precedent with how we're handling Tomcat.  At this point, it
appears the simplest approach would be to make a copy of the openejb code in the geronimo
ext tree, change the group ids to geronimo ids and release the artifacts separately.  Since
this will have different group ids, the chance of getting used as standalone openejb components
is significantly less, and this gives us a non-snapshot version we can replace with a real
release for the final version.

I can take care of this.  I'd probably trim out some of modules that Geronimo doesn't need
while I'm at it, which will make it a bit easier for us to review at vote time.

Likely won't be able to hammer on this till tomorrow.


-David


Mime
View raw message