Re: Tag 1.1 issue?
David Jencks wrote: On Jul 8, 2006, at 2:08 PM, David Blevins wrote: On Jul 8, 2006, at 2:54 AM, Bruce Snyder wrote: On 7/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote: 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. I'll do you one even better, Jeff ... I've just discovered that geronimo/tags/1.1.0 depends on openejb 2.1 branch which depends on geronimo-1.1.1-SNAPSHOT. Right, geronimo-1.1-SNAPSHOT (not 1.1.1-SNAPSHOT). This means that any user with a clean environment who is interested in building Geronimo 1.1 from source and somehow figures out that Geronimo 1.1resides in geronimo/tags/1.1.0 and follows the bulid instructions on the wiki will wind up with the following error: I'm fine documenting this as long as it's made completely clear it isn't at all necessary. One can build Geronimo just fine when skipping the optional 'm:co' step. Those are missing deps on Geronimo 1.1.1 while building Geronimo 1.1. In other words, geronimo/tags/1.1.0 is permanently broken. IMO, this issue is worse than we originally thought. Not that I don't agree it's a screwed up situation, but geronimo/tags/1.1.0 is perfectly fine -- building openejb is optional. It's openejb/tags/v2_1/ that's permanently broken. In fact all the openejb 2x tags are broken in exactly the same way. All openejb 2.x releases are cut before Geronimo releases so a given Geronimo release doesn't have to have a snapshot dependency on openejb. To fix this issue, I changed m:checkout to grab the openejb 2.1 tag. Then I changed the geronimo_version in my local copy of the openejb 2.1 tag from 1.1-SNAPSHOT to 1.1. After this, Geronimo 1.1 built successfully for me. At a minimum this solution should be documented in the appropriate locations. Maximally, we should consider fixing 1.1. What would you recommend? I think that we need to release like this: geronimo jars (and possibly non-openejb configs) (possibly also non-openejb assemblies such as minimal) openejb jars (and possibly openejb configs) other configs ( perhaps these should all be independently released plugins) assemblies. I don't think we can realistically do this on the 1.1/2.1 branches but it might be a realistic goal for 1.2/2.2 Do you think that things could be simplified if we broke up Geronimo into separate "product lines" instead of having a trunk that's a big bucket-o-stuff? Regards, Alan
Re: Tag 1.1 issue?
On 7/8/06, David Blevins <[EMAIL PROTECTED]> wrote:
On Jul 8, 2006, at 2:54 AM, Bruce Snyder wrote:
> On 7/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
>
>> 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.
>
> I'll do you one even better, Jeff ...
>
> I've just discovered that geronimo/tags/1.1.0 depends on openejb 2.1
> branch which depends on geronimo-1.1.1-SNAPSHOT.
Right, geronimo-1.1-SNAPSHOT (not 1.1.1-SNAPSHOT).
> This means that any
> user with a clean environment who is interested in building Geronimo
> 1.1 from source and somehow figures out that Geronimo 1.1resides in
> geronimo/tags/1.1.0 and follows the bulid instructions on the wiki
> will wind up with the following error:
I'm fine documenting this as long as it's made completely clear it
isn't at all necessary. One can build Geronimo just fine when
skipping the optional 'm:co' step.
My apologies, I stand corrected.
> Those are missing deps on Geronimo 1.1.1 while building Geronimo 1.1.
> In other words, geronimo/tags/1.1.0 is permanently broken. IMO, this
> issue is worse than we originally thought.
Not that I don't agree it's a screwed up situation, but geronimo/tags/
1.1.0 is perfectly fine -- building openejb is optional. It's
openejb/tags/v2_1/ that's permanently broken. In fact all the
openejb 2x tags are broken in exactly the same way. All openejb 2.x
releases are cut before Geronimo releases so a given Geronimo release
doesn't have to have a snapshot dependency on openejb.
> To fix this issue, I changed m:checkout to grab the openejb 2.1 tag.
> Then I changed the geronimo_version in my local copy of the openejb
> 2.1 tag from 1.1-SNAPSHOT to 1.1. After this, Geronimo 1.1 built
> successfully for me.
>
> At a minimum this solution should be documented in the appropriate
> locations. Maximally, we should consider fixing 1.1.
What would you recommend?
Documented the issue with m:co on tags/1.1.0 is all that is needed.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: Tag 1.1 issue?
On Jul 8, 2006, at 2:08 PM, David Blevins wrote: On Jul 8, 2006, at 2:54 AM, Bruce Snyder wrote: On 7/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote: 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. I'll do you one even better, Jeff ... I've just discovered that geronimo/tags/1.1.0 depends on openejb 2.1 branch which depends on geronimo-1.1.1-SNAPSHOT. Right, geronimo-1.1-SNAPSHOT (not 1.1.1-SNAPSHOT). This means that any user with a clean environment who is interested in building Geronimo 1.1 from source and somehow figures out that Geronimo 1.1resides in geronimo/tags/1.1.0 and follows the bulid instructions on the wiki will wind up with the following error: I'm fine documenting this as long as it's made completely clear it isn't at all necessary. One can build Geronimo just fine when skipping the optional 'm:co' step. Those are missing deps on Geronimo 1.1.1 while building Geronimo 1.1. In other words, geronimo/tags/1.1.0 is permanently broken. IMO, this issue is worse than we originally thought. Not that I don't agree it's a screwed up situation, but geronimo/ tags/1.1.0 is perfectly fine -- building openejb is optional. It's openejb/tags/v2_1/ that's permanently broken. In fact all the openejb 2x tags are broken in exactly the same way. All openejb 2.x releases are cut before Geronimo releases so a given Geronimo release doesn't have to have a snapshot dependency on openejb. To fix this issue, I changed m:checkout to grab the openejb 2.1 tag. Then I changed the geronimo_version in my local copy of the openejb 2.1 tag from 1.1-SNAPSHOT to 1.1. After this, Geronimo 1.1 built successfully for me. At a minimum this solution should be documented in the appropriate locations. Maximally, we should consider fixing 1.1. What would you recommend? I think that we need to release like this: geronimo jars (and possibly non-openejb configs) (possibly also non- openejb assemblies such as minimal) openejb jars (and possibly openejb configs) other configs ( perhaps these should all be independently released plugins) assemblies. I don't think we can realistically do this on the 1.1/2.1 branches but it might be a realistic goal for 1.2/2.2 thanks david jencks -David
Re: Tag 1.1 issue?
On Jul 8, 2006, at 2:54 AM, Bruce Snyder wrote: On 7/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote: 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. I'll do you one even better, Jeff ... I've just discovered that geronimo/tags/1.1.0 depends on openejb 2.1 branch which depends on geronimo-1.1.1-SNAPSHOT. Right, geronimo-1.1-SNAPSHOT (not 1.1.1-SNAPSHOT). This means that any user with a clean environment who is interested in building Geronimo 1.1 from source and somehow figures out that Geronimo 1.1resides in geronimo/tags/1.1.0 and follows the bulid instructions on the wiki will wind up with the following error: I'm fine documenting this as long as it's made completely clear it isn't at all necessary. One can build Geronimo just fine when skipping the optional 'm:co' step. Those are missing deps on Geronimo 1.1.1 while building Geronimo 1.1. In other words, geronimo/tags/1.1.0 is permanently broken. IMO, this issue is worse than we originally thought. Not that I don't agree it's a screwed up situation, but geronimo/tags/ 1.1.0 is perfectly fine -- building openejb is optional. It's openejb/tags/v2_1/ that's permanently broken. In fact all the openejb 2x tags are broken in exactly the same way. All openejb 2.x releases are cut before Geronimo releases so a given Geronimo release doesn't have to have a snapshot dependency on openejb. To fix this issue, I changed m:checkout to grab the openejb 2.1 tag. Then I changed the geronimo_version in my local copy of the openejb 2.1 tag from 1.1-SNAPSHOT to 1.1. After this, Geronimo 1.1 built successfully for me. At a minimum this solution should be documented in the appropriate locations. Maximally, we should consider fixing 1.1. What would you recommend? -David
Re: Tag 1.1 issue?
Yep...I did the exact same thing as you to fix this ;-) I just left out all that SNAPSHOT stuff in the email. But I agree...that needs some good documenting. Bruce Snyder wrote: > On 7/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > >> 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. > > I'll do you one even better, Jeff ... > > I've just discovered that geronimo/tags/1.1.0 depends on openejb 2.1 > branch which depends on geronimo-1.1.1-SNAPSHOT. This means that any > user with a clean environment who is interested in building Geronimo > 1.1 from source and somehow figures out that Geronimo 1.1resides in > geronimo/tags/1.1.0 and follows the bulid instructions on the wiki > will wind up with the following error: > > BUILD FAILED > File.. /Users/bsnyder/src/geronimo/tags/1.1.0/maven.xml > Element... maven:reactor > Line.. 48 > Column 105 > The build cannot continue because of the following unsatisfied > dependencies: > > geronimo-dependency-plugin-1.1.1-3.jar > geronimo-connector-1.1.1-SNAPSHOT.jar > geronimo-core-1.1.1-SNAPSHOT.jar > geronimo-client-1.1.1-SNAPSHOT.jar > geronimo-common-1.1.1-SNAPSHOT.jar > geronimo-deployment-1.1.1-SNAPSHOT.jar > geronimo-j2ee-1.1.1-SNAPSHOT.jar > geronimo-management-1.1.1-SNAPSHOT.jar > geronimo-kernel-1.1.1-SNAPSHOT.jar > geronimo-security-1.1.1-SNAPSHOT.jar > geronimo-timer-1.1.1-SNAPSHOT.jar > geronimo-transaction-1.1.1-SNAPSHOT.jar > geronimo-axis-1.1.1-SNAPSHOT.jar > geronimo-axis-builder-1.1.1-SNAPSHOT.jar > geronimo-naming-1.1.1-SNAPSHOT.jar > geronimo-system-1.1.1-SNAPSHOT.jar > geronimo-util-1.1.1-SNAPSHOT.jar > geronimo-webservices-1.1.1-SNAPSHOT.jar > > Those are missing deps on Geronimo 1.1.1 while building Geronimo 1.1. > In other words, geronimo/tags/1.1.0 is permanently broken. IMO, this > issue is worse than we originally thought. > > To fix this issue, I changed m:checkout to grab the openejb 2.1 tag. > Then I changed the geronimo_version in my local copy of the openejb > 2.1 tag from 1.1-SNAPSHOT to 1.1. After this, Geronimo 1.1 built > successfully for me. > > At a minimum this solution should be documented in the appropriate > locations. Maximally, we should consider fixing 1.1. > > Bruce
Re: Tag 1.1 issue?
On 7/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
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.
I'll do you one even better, Jeff ...
I've just discovered that geronimo/tags/1.1.0 depends on openejb 2.1
branch which depends on geronimo-1.1.1-SNAPSHOT. This means that any
user with a clean environment who is interested in building Geronimo
1.1 from source and somehow figures out that Geronimo 1.1resides in
geronimo/tags/1.1.0 and follows the bulid instructions on the wiki
will wind up with the following error:
BUILD FAILED
File.. /Users/bsnyder/src/geronimo/tags/1.1.0/maven.xml
Element... maven:reactor
Line.. 48
Column 105
The build cannot continue because of the following unsatisfied dependencies:
geronimo-dependency-plugin-1.1.1-3.jar
geronimo-connector-1.1.1-SNAPSHOT.jar
geronimo-core-1.1.1-SNAPSHOT.jar
geronimo-client-1.1.1-SNAPSHOT.jar
geronimo-common-1.1.1-SNAPSHOT.jar
geronimo-deployment-1.1.1-SNAPSHOT.jar
geronimo-j2ee-1.1.1-SNAPSHOT.jar
geronimo-management-1.1.1-SNAPSHOT.jar
geronimo-kernel-1.1.1-SNAPSHOT.jar
geronimo-security-1.1.1-SNAPSHOT.jar
geronimo-timer-1.1.1-SNAPSHOT.jar
geronimo-transaction-1.1.1-SNAPSHOT.jar
geronimo-axis-1.1.1-SNAPSHOT.jar
geronimo-axis-builder-1.1.1-SNAPSHOT.jar
geronimo-naming-1.1.1-SNAPSHOT.jar
geronimo-system-1.1.1-SNAPSHOT.jar
geronimo-util-1.1.1-SNAPSHOT.jar
geronimo-webservices-1.1.1-SNAPSHOT.jar
Those are missing deps on Geronimo 1.1.1 while building Geronimo 1.1.
In other words, geronimo/tags/1.1.0 is permanently broken. IMO, this
issue is worse than we originally thought.
To fix this issue, I changed m:checkout to grab the openejb 2.1 tag.
Then I changed the geronimo_version in my local copy of the openejb
2.1 tag from 1.1-SNAPSHOT to 1.1. After this, Geronimo 1.1 built
successfully for me.
At a minimum this solution should be documented in the appropriate
locations. Maximally, we should consider fixing 1.1.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: Tag 1.1 issue?
On Jul 7, 2006, at 8:41 AM, 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. Makes sense. -David
Re: Tag 1.1 issue?
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;http://www.ibiblio.org/maven2/openejb/openejb-core/2.0/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, Bill DudneyMyFaces - http://myfaces.apache.orgCayenne - http://incubator.apache.org/projects/cayenne.htmlOn Jul 7, 2006, at 11:47 AM, Jeff Genender wrote:I agree, but if we are not using snapshots, i.e. a true release ofopenejb, then this should be a moot point...the m:co could be changed topoint at the openejb tag rather than the branch. If we aren't going torun after this, then I may go along with the best thing to do is toremove the m:co as it will give very bad results (as I and others havefound). Thoughts?JeffMatt Hogstrom wrote: It would be nice to have closure on this. Perhaps, we'll have it whenOpenEJB makes it to Apache. However, we've had issues with other Apacheprojects 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 manyrespects 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 Iwentto do a m:co of openejb, it is giving me the openejb branch instead ofthe 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 orfopenejb, not the branch. Do we need this fixed so we can do abuild ofour svn tagged 1.1? Yes, I noticed this yesterday, also. The build works if you don't runm:co (the openejb 2.1 dependencies). So, I don't think we need to rushto fix this. Instead we can wait to fix in the normal 1.1.1 releasecycle, 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 asnapshot dependency on OpenEJB. Why wouldn't we just disable the m:co? I still believe there is value getting the state of OpenEJB at taggedlevel and accessing it with m:co. Here is an example...I am trying to research some classloading issues regarding OpenEJB andGeronimo 1.1. It behooves me to have source level access to bothOpenEJB and Geronimo for the state of the Geronimo 1.1 release so I canaccurately debug the problem. It would be nice to have the m:cocheckout the tagged version of OpenEJB since we are not really supposedto have any snapshots in there. -David
Re: Tag 1.1 issue?
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 >>> >>> >> >> >>
Re: Tag 1.1 issue?
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
Re: Tag 1.1 issue?
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 > >
Re: Tag 1.1 issue?
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? -David
Re: Tag 1.1 issue?
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. I also noticed that the tagged 1.1.0 is using people.apache.org/ repository. A tagged release should not be dependent on anything in that repository. Removing the repo, will bring up another issue, some of our dependencies only reside in people.apache.org. Namely, 1) commons-modeler-20060524.jar and 2) maven-itest-plugin-1.0.jar These dependencies need to be moved to a more permanent location or removed. --kevan
