Hi Jeff,

I think dropping the m:co is fine as long as there is a way to get to the source code. I did not see openejb src released with the jar's here;


but if I recall correctly its a snap to get m2 to push src jars as well. Maybe we could get one pushed from the tag and then disable the m:co?

Just a thought.

TTFN,



On Jul 7, 2006, at 11:47 AM, Jeff Genender wrote:

I agree, but if we are not using snapshots, i.e. a true release of
openejb, then this should be a moot point...the m:co could be changed to
point at the openejb tag rather than the branch.  If we aren't going to
run after this, then I may go along with the best thing to do is to
remove the m:co as it will give very bad results (as I and others have
found).  Thoughts?

Jeff

Matt Hogstrom wrote:
It would be nice to have closure on this.  Perhaps, we'll have it when
OpenEJB makes it to Apache. However, we've had issues with other Apache
projects not releasing on time...Axis is the example that comes to mind.

I think it would be nice to have everything bundled up but in many
respects its outside our control.

Jeff Genender wrote:

David Blevins wrote:
On Jul 7, 2006, at 6:32 AM, Kevan Miller wrote:

On Jul 6, 2006, at 11:30 PM, Jeff Genender wrote:

I tried to build the v1.1 of Geronimo tag and I noticed that when I
went
to do a m:co of openejb, it is giving me the openejb branch instead of
the 2.1 tag.  Sure enough, upon perusal of the tagged root maven.xml,
its pulling the openejb branch and not the tag.

I am assuming this is an oversight and it should pull the tag orf
openejb, not the branch.  Do we need this fixed so we can do a
build of
our svn tagged 1.1?
Yes, I noticed this yesterday, also. The build works if you don't run
m:co (the openejb 2.1 dependencies). So, I don't think we need to rush
to fix this. Instead we can wait to fix in the normal 1.1.1 release
cycle, which I think should be soon (in July).

Clearly something that needs to be in a release process checklist.
At release time is one of the rare moments where we don't have a
snapshot dependency on OpenEJB.  Why wouldn't we just disable the m:co?


I still believe there is value getting the state of OpenEJB at tagged
level and accessing it with m:co.  Here is an example...

I am trying to research some classloading issues regarding OpenEJB and
Geronimo 1.1.  It behooves me to have source level access to both
OpenEJB and Geronimo for the state of the Geronimo 1.1 release so I can
accurately debug the problem.  It would be nice to have the m:co
checkout the tagged version of OpenEJB since we are not really supposed
to have any snapshots in there.

-David






Reply via email to