Creating an openejb version for the Geronimo M1 release.

[Rick McGuire <ri...@gmail.com>]

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.

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.

Thoughts on whether this doable?

Rick

Re: Creating an openejb version for the Geronimo M1 release.

[David Blevins <da...@visi.com>]

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