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
