You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jeff Genender <jg...@apache.org> on 2006/07/07 05:30:17 UTC
Tag 1.1 issue?
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?
Jeff
Re: Tag 1.1 issue?
Posted by Jeff Genender <jg...@apache.org>.
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 <jg...@apache.org> 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?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <jg...@apache.org> 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?
Posted by David Jencks <da...@yahoo.com>.
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 <jg...@apache.org> 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?
Posted by Bruce Snyder <br...@gmail.com>.
On 7/8/06, David Blevins <da...@visi.com> wrote:
> On Jul 8, 2006, at 2:54 AM, Bruce Snyder wrote:
>
> > On 7/7/06, Jeff Genender <jg...@apache.org> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://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?
Posted by David Blevins <da...@visi.com>.
On Jul 8, 2006, at 2:54 AM, Bruce Snyder wrote:
> On 7/7/06, Jeff Genender <jg...@apache.org> 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?
Posted by Bruce Snyder <br...@gmail.com>.
On 7/7/06, Jeff Genender <jg...@apache.org> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://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?
Posted by David Blevins <da...@visi.com>.
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?
Posted by Bill Dudney <bd...@apache.org>.
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 Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html
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
>>>>
>>>>
>>>
>>>
>>>
Re: Tag 1.1 issue?
Posted by Jeff Genender <jg...@apache.org>.
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?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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?
Posted by Jeff Genender <jg...@apache.org>.
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?
Posted by David Blevins <da...@visi.com>.
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?
Posted by Kevan Miller <ke...@gmail.com>.
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