You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apps-dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2002/12/04 16:09:57 UTC
gump entry for containerkit
Hi gang,
Gump has an entry for excalibur-containerkit, which I've just moved to
the avalon-sandbox cvs. The sourcepath for this entry needs to be
updated, but even after lots of headscratching I can't figure out what
to do; the <home/> and <work/> tags probably both need to change but
it's unclear to me to what; and I can't find the <module/> definitions
at all!
could someone with more gump knowledge take a peek?
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> aha: the name attribute for <module> corresponds to the name of the cvs
> module! du-uh :D
There is a tentative GUI editor for the Gump descriptor in the
Alexandria-Gump repo, under /editor in the gump proposal dir.
> thanks!
>
> - Leo
>
> On Wed, 2002-12-04 at 16:41, Stefan Bodewig wrote:
>
>>On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
>>
>>
>>>Just can't figure out what file to change into what.
>>
>>I've added a new file avalon-sandbox.xml with a module for
>>avalon-sandbox (those file vaguely correspond to CVS modules and as
>>there hasn't been obe for avalon-sandbox, you need a new one).
>>
>>I moved the excalibur-containerkit <project> to the new file and added
>>the new file to the project.
>>
>>See it in action with the next Gump build.
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> aha: the name attribute for <module> corresponds to the name of the cvs
> module! du-uh :D
There is a tentative GUI editor for the Gump descriptor in the
Alexandria-Gump repo, under /editor in the gump proposal dir.
> thanks!
>
> - Leo
>
> On Wed, 2002-12-04 at 16:41, Stefan Bodewig wrote:
>
>>On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
>>
>>
>>>Just can't figure out what file to change into what.
>>
>>I've added a new file avalon-sandbox.xml with a module for
>>avalon-sandbox (those file vaguely correspond to CVS modules and as
>>there hasn't been obe for avalon-sandbox, you need a new one).
>>
>>I moved the excalibur-containerkit <project> to the new file and added
>>the new file to the project.
>>
>>See it in action with the next Gump build.
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> aha: the name attribute for <module> corresponds to the name of the cvs
> module! du-uh :D
There is a tentative GUI editor for the Gump descriptor in the
Alexandria-Gump repo, under /editor in the gump proposal dir.
> thanks!
>
> - Leo
>
> On Wed, 2002-12-04 at 16:41, Stefan Bodewig wrote:
>
>>On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
>>
>>
>>>Just can't figure out what file to change into what.
>>
>>I've added a new file avalon-sandbox.xml with a module for
>>avalon-sandbox (those file vaguely correspond to CVS modules and as
>>there hasn't been obe for avalon-sandbox, you need a new one).
>>
>>I moved the excalibur-containerkit <project> to the new file and added
>>the new file to the project.
>>
>>See it in action with the next Gump build.
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Leo Simons <le...@apache.org>.
aha: the name attribute for <module> corresponds to the name of the cvs
module! du-uh :D
thanks!
- Leo
On Wed, 2002-12-04 at 16:41, Stefan Bodewig wrote:
> On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
>
> > Just can't figure out what file to change into what.
>
> I've added a new file avalon-sandbox.xml with a module for
> avalon-sandbox (those file vaguely correspond to CVS modules and as
> there hasn't been obe for avalon-sandbox, you need a new one).
>
> I moved the excalibur-containerkit <project> to the new file and added
> the new file to the project.
>
> See it in action with the next Gump build.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Leo Simons <le...@apache.org>.
aha: the name attribute for <module> corresponds to the name of the cvs
module! du-uh :D
thanks!
- Leo
On Wed, 2002-12-04 at 16:41, Stefan Bodewig wrote:
> On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
>
> > Just can't figure out what file to change into what.
>
> I've added a new file avalon-sandbox.xml with a module for
> avalon-sandbox (those file vaguely correspond to CVS modules and as
> there hasn't been obe for avalon-sandbox, you need a new one).
>
> I moved the excalibur-containerkit <project> to the new file and added
> the new file to the project.
>
> See it in action with the next Gump build.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Leo Simons <le...@apache.org>.
aha: the name attribute for <module> corresponds to the name of the cvs
module! du-uh :D
thanks!
- Leo
On Wed, 2002-12-04 at 16:41, Stefan Bodewig wrote:
> On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
>
> > Just can't figure out what file to change into what.
>
> I've added a new file avalon-sandbox.xml with a module for
> avalon-sandbox (those file vaguely correspond to CVS modules and as
> there hasn't been obe for avalon-sandbox, you need a new one).
>
> I moved the excalibur-containerkit <project> to the new file and added
> the new file to the project.
>
> See it in action with the next Gump build.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 4 Dec 2002, Berin Loritsch <bl...@citi-us.com> wrote:
> Include GUMP descriptor in Avalon-Sandbox. It is reasonable
> to assume that the sandbox area will change more often than
> the Alexandria folks can keep up with.
Feel free to add
<http://cvs.apache.org/viewcvs.cgi/jakarta-alexandria/proposal/gump/project/avalon-sandbox.xml>
to avalon-sandbox and tell me where you've put it.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 4 Dec 2002, Berin Loritsch <bl...@citi-us.com> wrote:
> Include GUMP descriptor in Avalon-Sandbox. It is reasonable
> to assume that the sandbox area will change more often than
> the Alexandria folks can keep up with.
Feel free to add
<http://cvs.apache.org/viewcvs.cgi/jakarta-alexandria/proposal/gump/project/avalon-sandbox.xml>
to avalon-sandbox and tell me where you've put it.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Berin Loritsch wrote:
>>From: Leo Simons [mailto:leosimons@apache.org]
>>
>>I'll throw the same link at you I got from Steve:
>>
>>http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>>
>>essentially the descriptors were moved to avalon from
>>alexandria and we
>>did a lousy job maintaining them, so they were moved back. If you want
>>access to the descriptors all you have to do is ask :D
>
> There was no real education either. What does the thing look like?
> How to edit it? that sort of thing.
I'll let you in on a secret, if you promise not to tell. :-P
Go to any gump generated page and click on the bench icon thingie on the
top right corner.
Cool links to click on from there are the "Source", "Usage", and pretty
much any of the "Data Definitions" ones.
Just between us, of course.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
> I'll throw the same link at you I got from Steve:
>
> http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>
> essentially the descriptors were moved to avalon from alexandria and we
> did a lousy job maintaining them, so they were moved back. If you want
> access to the descriptors all you have to do is ask :D
+1
If descriptors exist in local cvses that are better maintained than the
ones in the alexandria's cvs, then they will simply be pointed to.
If existing committers want to access to the descriptors in alexandria's
cvs, all one needs to do is demonstrate an ability to execute a simple
build.xml which only depends on Ant, Xerces, and Xalan. I seriously
doubt that this is beyond the reach of most of the readers of this e-mail.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Stephen McConnell <mc...@apache.org>.
I think it makes much more sense to have the gump descriptor locally in
avalon-sandbox. All of the stuff I've been working on in excalibur was
actively maintained until it wass pulled of the excalibur site. Putting
it on avalon-sandbox makes it so much easier to maintain.
Cheers, Steve.
Leo Simons wrote:
>I'll throw the same link at you I got from Steve:
>
>http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>
>essentially the descriptors were moved to avalon from alexandria and we
>did a lousy job maintaining them, so they were moved back. If you want
>access to the descriptors all you have to do is ask :D
>
>the only thing in sandbox referenced by gump atm is containerkit. The
>rest can change as often as it wants without gump noticing.
>
>cheers,
>
>- Leo
>
>On Wed, 2002-12-04 at 16:54, Berin Loritsch wrote:
>
>
>>Include GUMP descriptor in Avalon-Sandbox. It is reasonable
>>to assume that the sandbox area will change more often than
>>the Alexandria folks can keep up with. The released stuff
>>should remain fairly static in its dependencies so if the
>>Alexandria folks want to keep up control of it let them.
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Berin Loritsch wrote:
>>From: Leo Simons [mailto:leosimons@apache.org]
>>
>>I'll throw the same link at you I got from Steve:
>>
>>http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>>
>>essentially the descriptors were moved to avalon from
>>alexandria and we
>>did a lousy job maintaining them, so they were moved back. If you want
>>access to the descriptors all you have to do is ask :D
>
> There was no real education either. What does the thing look like?
> How to edit it? that sort of thing.
I'll let you in on a secret, if you promise not to tell. :-P
Go to any gump generated page and click on the bench icon thingie on the
top right corner.
Cool links to click on from there are the "Source", "Usage", and pretty
much any of the "Data Definitions" ones.
Just between us, of course.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
> I'll throw the same link at you I got from Steve:
>
> http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>
> essentially the descriptors were moved to avalon from alexandria and we
> did a lousy job maintaining them, so they were moved back. If you want
> access to the descriptors all you have to do is ask :D
+1
If descriptors exist in local cvses that are better maintained than the
ones in the alexandria's cvs, then they will simply be pointed to.
If existing committers want to access to the descriptors in alexandria's
cvs, all one needs to do is demonstrate an ability to execute a simple
build.xml which only depends on Ant, Xerces, and Xalan. I seriously
doubt that this is beyond the reach of most of the readers of this e-mail.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Stephen McConnell <mc...@apache.org>.
I think it makes much more sense to have the gump descriptor locally in
avalon-sandbox. All of the stuff I've been working on in excalibur was
actively maintained until it wass pulled of the excalibur site. Putting
it on avalon-sandbox makes it so much easier to maintain.
Cheers, Steve.
Leo Simons wrote:
>I'll throw the same link at you I got from Steve:
>
>http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>
>essentially the descriptors were moved to avalon from alexandria and we
>did a lousy job maintaining them, so they were moved back. If you want
>access to the descriptors all you have to do is ask :D
>
>the only thing in sandbox referenced by gump atm is containerkit. The
>rest can change as often as it wants without gump noticing.
>
>cheers,
>
>- Leo
>
>On Wed, 2002-12-04 at 16:54, Berin Loritsch wrote:
>
>
>>Include GUMP descriptor in Avalon-Sandbox. It is reasonable
>>to assume that the sandbox area will change more often than
>>the Alexandria folks can keep up with. The released stuff
>>should remain fairly static in its dependencies so if the
>>Alexandria folks want to keep up control of it let them.
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
> I'll throw the same link at you I got from Steve:
>
> http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>
> essentially the descriptors were moved to avalon from alexandria and we
> did a lousy job maintaining them, so they were moved back. If you want
> access to the descriptors all you have to do is ask :D
+1
If descriptors exist in local cvses that are better maintained than the
ones in the alexandria's cvs, then they will simply be pointed to.
If existing committers want to access to the descriptors in alexandria's
cvs, all one needs to do is demonstrate an ability to execute a simple
build.xml which only depends on Ant, Xerces, and Xalan. I seriously
doubt that this is beyond the reach of most of the readers of this e-mail.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Berin Loritsch wrote:
>>From: Leo Simons [mailto:leosimons@apache.org]
>>
>>I'll throw the same link at you I got from Steve:
>>
>>http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>>
>>essentially the descriptors were moved to avalon from
>>alexandria and we
>>did a lousy job maintaining them, so they were moved back. If you want
>>access to the descriptors all you have to do is ask :D
>
> There was no real education either. What does the thing look like?
> How to edit it? that sort of thing.
I'll let you in on a secret, if you promise not to tell. :-P
Go to any gump generated page and click on the bench icon thingie on the
top right corner.
Cool links to click on from there are the "Source", "Usage", and pretty
much any of the "Data Definitions" ones.
Just between us, of course.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Stephen McConnell <mc...@apache.org>.
I think it makes much more sense to have the gump descriptor locally in
avalon-sandbox. All of the stuff I've been working on in excalibur was
actively maintained until it wass pulled of the excalibur site. Putting
it on avalon-sandbox makes it so much easier to maintain.
Cheers, Steve.
Leo Simons wrote:
>I'll throw the same link at you I got from Steve:
>
>http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>
>essentially the descriptors were moved to avalon from alexandria and we
>did a lousy job maintaining them, so they were moved back. If you want
>access to the descriptors all you have to do is ask :D
>
>the only thing in sandbox referenced by gump atm is containerkit. The
>rest can change as often as it wants without gump noticing.
>
>cheers,
>
>- Leo
>
>On Wed, 2002-12-04 at 16:54, Berin Loritsch wrote:
>
>
>>Include GUMP descriptor in Avalon-Sandbox. It is reasonable
>>to assume that the sandbox area will change more often than
>>the Alexandria folks can keep up with. The released stuff
>>should remain fairly static in its dependencies so if the
>>Alexandria folks want to keep up control of it let them.
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] RE: gump entry for containerkit
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> I'll throw the same link at you I got from Steve:
>
> http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>
> essentially the descriptors were moved to avalon from
> alexandria and we
> did a lousy job maintaining them, so they were moved back. If you want
> access to the descriptors all you have to do is ask :D
There was no real education either. What does the thing look like?
How to edit it? that sort of thing.
> the only thing in sandbox referenced by gump atm is containerkit. The
> rest can change as often as it wants without gump noticing.
All our code needs to be continuously integrated. If a sanbox project
depends on outside code, we need to know about changes.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] RE: gump entry for containerkit
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> I'll throw the same link at you I got from Steve:
>
> http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>
> essentially the descriptors were moved to avalon from
> alexandria and we
> did a lousy job maintaining them, so they were moved back. If you want
> access to the descriptors all you have to do is ask :D
There was no real education either. What does the thing look like?
How to edit it? that sort of thing.
> the only thing in sandbox referenced by gump atm is containerkit. The
> rest can change as often as it wants without gump noticing.
All our code needs to be continuously integrated. If a sanbox project
depends on outside code, we need to know about changes.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] RE: gump entry for containerkit
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> I'll throw the same link at you I got from Steve:
>
> http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>
> essentially the descriptors were moved to avalon from
> alexandria and we
> did a lousy job maintaining them, so they were moved back. If you want
> access to the descriptors all you have to do is ask :D
There was no real education either. What does the thing look like?
How to edit it? that sort of thing.
> the only thing in sandbox referenced by gump atm is containerkit. The
> rest can change as often as it wants without gump noticing.
All our code needs to be continuously integrated. If a sanbox project
depends on outside code, we need to know about changes.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Leo Simons <le...@apache.org>.
I'll throw the same link at you I got from Steve:
http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
essentially the descriptors were moved to avalon from alexandria and we
did a lousy job maintaining them, so they were moved back. If you want
access to the descriptors all you have to do is ask :D
the only thing in sandbox referenced by gump atm is containerkit. The
rest can change as often as it wants without gump noticing.
cheers,
- Leo
On Wed, 2002-12-04 at 16:54, Berin Loritsch wrote:
> Include GUMP descriptor in Avalon-Sandbox. It is reasonable
> to assume that the sandbox area will change more often than
> the Alexandria folks can keep up with. The released stuff
> should remain fairly static in its dependencies so if the
> Alexandria folks want to keep up control of it let them.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 4 Dec 2002, Berin Loritsch <bl...@citi-us.com> wrote:
> Include GUMP descriptor in Avalon-Sandbox. It is reasonable
> to assume that the sandbox area will change more often than
> the Alexandria folks can keep up with.
Feel free to add
<http://cvs.apache.org/viewcvs.cgi/jakarta-alexandria/proposal/gump/project/avalon-sandbox.xml>
to avalon-sandbox and tell me where you've put it.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Leo Simons <le...@apache.org>.
I'll throw the same link at you I got from Steve:
http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
essentially the descriptors were moved to avalon from alexandria and we
did a lousy job maintaining them, so they were moved back. If you want
access to the descriptors all you have to do is ask :D
the only thing in sandbox referenced by gump atm is containerkit. The
rest can change as often as it wants without gump noticing.
cheers,
- Leo
On Wed, 2002-12-04 at 16:54, Berin Loritsch wrote:
> Include GUMP descriptor in Avalon-Sandbox. It is reasonable
> to assume that the sandbox area will change more often than
> the Alexandria folks can keep up with. The released stuff
> should remain fairly static in its dependencies so if the
> Alexandria folks want to keep up control of it let them.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: gump entry for containerkit
Posted by Leo Simons <le...@apache.org>.
I'll throw the same link at you I got from Steve:
http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
essentially the descriptors were moved to avalon from alexandria and we
did a lousy job maintaining them, so they were moved back. If you want
access to the descriptors all you have to do is ask :D
the only thing in sandbox referenced by gump atm is containerkit. The
rest can change as often as it wants without gump noticing.
cheers,
- Leo
On Wed, 2002-12-04 at 16:54, Berin Loritsch wrote:
> Include GUMP descriptor in Avalon-Sandbox. It is reasonable
> to assume that the sandbox area will change more often than
> the Alexandria folks can keep up with. The released stuff
> should remain fairly static in its dependencies so if the
> Alexandria folks want to keep up control of it let them.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] RE: gump entry for containerkit
Posted by Berin Loritsch <bl...@citi-us.com>.
Include GUMP descriptor in Avalon-Sandbox. It is reasonable
to assume that the sandbox area will change more often than
the Alexandria folks can keep up with. The released stuff
should remain fairly static in its dependencies so if the
Alexandria folks want to keep up control of it let them.
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
>
> > Just can't figure out what file to change into what.
>
> I've added a new file avalon-sandbox.xml with a module for
> avalon-sandbox (those file vaguely correspond to CVS modules and as
> there hasn't been obe for avalon-sandbox, you need a new one).
>
> I moved the excalibur-containerkit <project> to the new file and added
> the new file to the project.
>
> See it in action with the next Gump build.
>
> Stefan
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] RE: gump entry for containerkit
Posted by Berin Loritsch <bl...@citi-us.com>.
Include GUMP descriptor in Avalon-Sandbox. It is reasonable
to assume that the sandbox area will change more often than
the Alexandria folks can keep up with. The released stuff
should remain fairly static in its dependencies so if the
Alexandria folks want to keep up control of it let them.
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
>
> > Just can't figure out what file to change into what.
>
> I've added a new file avalon-sandbox.xml with a module for
> avalon-sandbox (those file vaguely correspond to CVS modules and as
> there hasn't been obe for avalon-sandbox, you need a new one).
>
> I moved the excalibur-containerkit <project> to the new file and added
> the new file to the project.
>
> See it in action with the next Gump build.
>
> Stefan
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] RE: gump entry for containerkit
Posted by Berin Loritsch <bl...@citi-us.com>.
Include GUMP descriptor in Avalon-Sandbox. It is reasonable
to assume that the sandbox area will change more often than
the Alexandria folks can keep up with. The released stuff
should remain fairly static in its dependencies so if the
Alexandria folks want to keep up control of it let them.
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
>
> > Just can't figure out what file to change into what.
>
> I've added a new file avalon-sandbox.xml with a module for
> avalon-sandbox (those file vaguely correspond to CVS modules and as
> there hasn't been obe for avalon-sandbox, you need a new one).
>
> I moved the excalibur-containerkit <project> to the new file and added
> the new file to the project.
>
> See it in action with the next Gump build.
>
> Stefan
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stefan Bodewig <bo...@apache.org>.
On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
> Just can't figure out what file to change into what.
I've added a new file avalon-sandbox.xml with a module for
avalon-sandbox (those file vaguely correspond to CVS modules and as
there hasn't been obe for avalon-sandbox, you need a new one).
I moved the excalibur-containerkit <project> to the new file and added
the new file to the project.
See it in action with the next Gump build.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stefan Bodewig <bo...@apache.org>.
On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
> Just can't figure out what file to change into what.
I've added a new file avalon-sandbox.xml with a module for
avalon-sandbox (those file vaguely correspond to CVS modules and as
there hasn't been obe for avalon-sandbox, you need a new one).
I moved the excalibur-containerkit <project> to the new file and added
the new file to the project.
See it in action with the next Gump build.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stefan Bodewig <bo...@apache.org>.
On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
> Just can't figure out what file to change into what.
I've added a new file avalon-sandbox.xml with a module for
avalon-sandbox (those file vaguely correspond to CVS modules and as
there hasn't been obe for avalon-sandbox, you need a new one).
I moved the excalibur-containerkit <project> to the new file and added
the new file to the project.
See it in action with the next Gump build.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Leo Simons <le...@apache.org>.
heh :D
Perhaps I wasn't clear: I read the gump docs, even have a complete
working install along with a gb or so of sources locally, and all works
fine. Just can't figure out what file to change into what.
cheers,
- Leo
On Wed, 2002-12-04 at 16:21, Stephen McConnell wrote:
> Leo Simons wrote:
>
> >Hi gang,
> >
> >Gump has an entry for excalibur-containerkit, which I've just moved to
> >the avalon-sandbox cvs. The sourcepath for this entry needs to be
> >updated, but even after lots of headscratching I can't figure out what
> >to do; the <home/> and <work/> tags probably both need to change but
> >it's unclear to me to what; and I can't find the <module/> definitions
> >at all!
> >
>
> http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>
> Steve.
>
> >
> >could someone with more gump knowledge take a peek?
> >
> >cheers,
> >
> >- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Leo Simons <le...@apache.org>.
heh :D
Perhaps I wasn't clear: I read the gump docs, even have a complete
working install along with a gb or so of sources locally, and all works
fine. Just can't figure out what file to change into what.
cheers,
- Leo
On Wed, 2002-12-04 at 16:21, Stephen McConnell wrote:
> Leo Simons wrote:
>
> >Hi gang,
> >
> >Gump has an entry for excalibur-containerkit, which I've just moved to
> >the avalon-sandbox cvs. The sourcepath for this entry needs to be
> >updated, but even after lots of headscratching I can't figure out what
> >to do; the <home/> and <work/> tags probably both need to change but
> >it's unclear to me to what; and I can't find the <module/> definitions
> >at all!
> >
>
> http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>
> Steve.
>
> >
> >could someone with more gump knowledge take a peek?
> >
> >cheers,
> >
> >- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Leo Simons <le...@apache.org>.
heh :D
Perhaps I wasn't clear: I read the gump docs, even have a complete
working install along with a gb or so of sources locally, and all works
fine. Just can't figure out what file to change into what.
cheers,
- Leo
On Wed, 2002-12-04 at 16:21, Stephen McConnell wrote:
> Leo Simons wrote:
>
> >Hi gang,
> >
> >Gump has an entry for excalibur-containerkit, which I've just moved to
> >the avalon-sandbox cvs. The sourcepath for this entry needs to be
> >updated, but even after lots of headscratching I can't figure out what
> >to do; the <home/> and <work/> tags probably both need to change but
> >it's unclear to me to what; and I can't find the <module/> definitions
> >at all!
> >
>
> http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
>
> Steve.
>
> >
> >could someone with more gump knowledge take a peek?
> >
> >cheers,
> >
> >- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>Hi gang,
>
>Gump has an entry for excalibur-containerkit, which I've just moved to
>the avalon-sandbox cvs. The sourcepath for this entry needs to be
>updated, but even after lots of headscratching I can't figure out what
>to do; the <home/> and <work/> tags probably both need to change but
>it's unclear to me to what; and I can't find the <module/> definitions
>at all!
>
http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
Steve.
>
>could someone with more gump knowledge take a peek?
>
>cheers,
>
>- Leo
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 04 Dec 2002, Sam Ruby <ru...@apache.org> wrote:
> Stephan Bodewig constructed and committed a correct entry - before
> you even posted this e-mail.
No, we seem to have some mail-server hickups ATM. I've seen a
response by Nicola Ken to a mail by Leo - but not that original mail
so far. Without Leo's mail I wouldn't have known about the move.
> to this day, I still have been unable to locate the correct place to
> find and build the org.apache.avalon.framework.info classes. Any
> hints would be appreciated.
++++1
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 04 Dec 2002, Sam Ruby <ru...@apache.org> wrote:
> Stephan Bodewig constructed and committed a correct entry - before
> you even posted this e-mail.
No, we seem to have some mail-server hickups ATM. I've seen a
response by Nicola Ken to a mail by Leo - but not that original mail
so far. Without Leo's mail I wouldn't have known about the move.
> to this day, I still have been unable to locate the correct place to
> find and build the org.apache.avalon.framework.info classes. Any
> hints would be appreciated.
++++1
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 04 Dec 2002, Sam Ruby <ru...@apache.org> wrote:
> Stephan Bodewig constructed and committed a correct entry - before
> you even posted this e-mail.
No, we seem to have some mail-server hickups ATM. I've seen a
response by Nicola Ken to a mail by Leo - but not that original mail
so far. Without Leo's mail I wouldn't have known about the move.
> to this day, I still have been unable to locate the correct place to
> find and build the org.apache.avalon.framework.info classes. Any
> hints would be appreciated.
++++1
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Berin Loritsch wrote:
>
> My suggestion is to bring up the issue on the Pheonix dev list,
> and require them to bring Phoenix into a compilable and consistent
> build.
As Stephen has already pointed out, this *is* the phoenix dev list.
> I suggest we give the Phoenix developers one week to make it stop
> the GUMP build errors. If it cannot, we revert the code base to
> the last CVS date that it was working.
>
> I know there are Phoenix developers who can pick up where Peter
> left off. I have a feeling he was in the midst of a bunch of
> changes/updates to Phoenix/Info when his commit privs were
> suspended. It presents a problem in that Phoenix development
> has essentially stopped in the middle of a change.
Peter is still able to submit patches, and has done so in a number of
occasions.
Either Phoenix has a community or it does not belong in an ASF hosted
cvs repository.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Sam Ruby wrote:
> Stephen McConnell wrote:
>
>>
>> It very much concerns me where there is considerable pressure on one
>> hand to be non-devisive (i.e. no -1s) and on the otherhand, the
>> suggestion that someone thinks that the PMC in general thinks its not
>> our problem. Yes it is our problem - the only issue is when do we
>> bite the bullet and bring Phoenix into Avalon. That will require
>> effort and resource and will. I don't think those ingridients will
>> be available until we get the container API in place. In the
>> meantime we have two options:
>
>
> Do you believe that -1 is the only path to consensus?
Do you belive that I belive that a -1 is the only path to concensus?
I belive that there are things that are instrumental to consensus -
things like discussion, open debate, frank exchange of ideas and
opinions, collaboration, notions of shared ownership and responsibility.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Stephen McConnell wrote:
>
> It very much concerns me where there is considerable pressure on one
> hand to be non-devisive (i.e. no -1s) and on the otherhand, the
> suggestion that someone thinks that the PMC in general thinks its not
> our problem. Yes it is our problem - the only issue is when do we bite
> the bullet and bring Phoenix into Avalon. That will require effort and
> resource and will. I don't think those ingridients will be available
> until we get the container API in place. In the meantime we have two
> options:
Do you believe that -1 is the only path to consensus?
> (b) the easy option
>
> Let Phoenix development continue in an independent path.
>
> (a) the hard option
>
> Stop further divergence of Phoenix.
(a) can equivalently be described as "stop further divergence of Avalon".
My interests in resurrecting this thread are not in stopping anything,
but to start something that doesn't seem to be occuring:
communication
At a minimum, James is one "customer" of Phoenix. I will assert that
the current state of affairs is not in the best interests of either
James or Avalon.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>It very much concerns me where there is considerable pressure on one
>>hand to be non-devisive (i.e. no -1s) and on the otherhand, the
>>suggestion that someone thinks that the PMC in general thinks its not
>>our problem. Yes it is our problem - the only issue is when
>>do we bite
>>the bullet and bring Phoenix into Avalon. That will require
>>effort and
>>resource and will. I don't think those ingridients will be available
>>until we get the container API in place. In the meantime we have two
>>options:
>>
>> (b) the easy option
>>
>> Let Phoenix development continue in an independent path.
>>
>> (a) the hard option
>>
>> Stop further divergence of Phoenix.
>>
>>Cheers, Steve.
>>
>>
>
>My suggestion is to bring up the issue on the Pheonix dev list,
>and require them to bring Phoenix into a compilable and consistent
>build.
>
>
This is te Phoneix dev list - the merge of phoenix-dev with avalon-dev
was completed a couple of days ago.
>As to option "a" versus "b", I don't want to stand in the way of
>further development, but we need to make sure the standards are
>the same.
>
>
I don't want to stand in the way of furter development either - but I do
want to make sure that the development is rationale.
>As it stands *now* with the current understanding of the contracts
>(or lack thereof) of Avalon Framework 4.1 compliance, Phoenix _is_
>Avalon Framework compatible. That is the only level of compatibility
>that is guaranteed for Phoenix at this time.
>
>As we further refine what our contracts are, we need to communicate
>those issues to the Phoenix Dev list.
>
>I suggest we give the Phoenix developers one week to make it stop
>the GUMP build errors. If it cannot, we revert the code base to
>the last CVS date that it was working.
>
>
+1
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> It very much concerns me where there is considerable pressure on one
> hand to be non-devisive (i.e. no -1s) and on the otherhand, the
> suggestion that someone thinks that the PMC in general thinks its not
> our problem. Yes it is our problem - the only issue is when
> do we bite
> the bullet and bring Phoenix into Avalon. That will require
> effort and
> resource and will. I don't think those ingridients will be available
> until we get the container API in place. In the meantime we have two
> options:
>
> (b) the easy option
>
> Let Phoenix development continue in an independent path.
>
> (a) the hard option
>
> Stop further divergence of Phoenix.
>
> Cheers, Steve.
My suggestion is to bring up the issue on the Pheonix dev list,
and require them to bring Phoenix into a compilable and consistent
build.
As to option "a" versus "b", I don't want to stand in the way of
further development, but we need to make sure the standards are
the same.
As it stands *now* with the current understanding of the contracts
(or lack thereof) of Avalon Framework 4.1 compliance, Phoenix _is_
Avalon Framework compatible. That is the only level of compatibility
that is guaranteed for Phoenix at this time.
As we further refine what our contracts are, we need to communicate
those issues to the Phoenix Dev list.
I suggest we give the Phoenix developers one week to make it stop
the GUMP build errors. If it cannot, we revert the code base to
the last CVS date that it was working.
I know there are Phoenix developers who can pick up where Peter
left off. I have a feeling he was in the midst of a bunch of
changes/updates to Phoenix/Info when his commit privs were
suspended. It presents a problem in that Phoenix development
has essentially stopped in the middle of a change.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Sam Ruby wrote:
> Leo Sutic wrote:
>
>>
>>> What does concerns me, however, is when knowledge of such events and
>>> fail to spark a dialog. Particuarly, when this is all within the
>>> scope of a single project.
>>
>>
>> + People developing Phoenix have in some instances been completely
>> unaware of Avalon.
>
>
> Clearly somebody committed a change to phoenix creating a depencency
> on what is now excalibur-info in the sandbox. Furthermore, there has
> been plenty of notifications that the current version of info has
> diverged from what phoenix needs.
>
>> In short - there is a major chasm here. Result: When things like this
>> happen, people will just think "not my problem". I know I did.
>
>
> It very much concerns me when there is a PMC full of people, all of
> whom consider this not their problem.
It very much concerns me where there is considerable pressure on one
hand to be non-devisive (i.e. no -1s) and on the otherhand, the
suggestion that someone thinks that the PMC in general thinks its not
our problem. Yes it is our problem - the only issue is when do we bite
the bullet and bring Phoenix into Avalon. That will require effort and
resource and will. I don't think those ingridients will be available
until we get the container API in place. In the meantime we have two
options:
(b) the easy option
Let Phoenix development continue in an independent path.
(a) the hard option
Stop further divergence of Phoenix.
Cheers, Steve.
>
> - Sam Ruby
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Leo Sutic wrote:
>
>>What does concerns me, however, is when knowledge of such events and
>>fail to spark a dialog. Particuarly, when this is all within the
>>scope of a single project.
>
> + People developing Phoenix have in some instances been completely
> unaware of Avalon.
Clearly somebody committed a change to phoenix creating a depencency on
what is now excalibur-info in the sandbox. Furthermore, there has been
plenty of notifications that the current version of info has diverged
from what phoenix needs.
> In short - there is a major chasm here. Result: When things like this
> happen, people will just think "not my problem". I know I did.
It very much concerns me when there is a PMC full of people, all of whom
consider this not their problem.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: news [mailto:news@main.gmane.org]On Behalf Of Sam Ruby
>>
>>Berin Loritsch wrote:
>>
>>
>>>People who have not been working on Phoenix really don't know what
>>>is going on with that project. I have subscribed to it, but with
>>>all the volume of Avalon dev, Avalon users, et. al. it is hard to
>>>notice when something like this happens.
>>>
>>>
>>The reason why Avalon became a separate project was due to a similar
>>lack of oversight by Jakarta.
>>
>>[technical details snipped]
>>
>>I don't have an opinion on the technical details. But I do have an
>>opinion on the state of affairs when I see people aren't responsive.
>>
>>
>
>The fact that the change slipped in under the radar is something we
>can't change.
>
I disagree.
These changes were introduced on the 26-28 November and 02 December.
There has been no discussion on this subject. But that does not mean
that discussion should not happen. In fact - from a PMC Member
perspective there is absolutely no way that I could support the release
of Phoenix based on containerkit simply on the grounds that its not
"owned by" the community. Beoyond that there is the obviouse issue of
the releasing a container revision that is inconsistent with other
Avalon work.
>
>Who wants to take responsibility for either reverting Phoenix to the
>point where it no longer needs Info, or updating Phoenix to use Info
>properly?
>
Should be possible to roll back Phoneix to the status prior to
27-November 2002. I'm not sufficiently savy to do that in terms of CVS
manipulation - but I think its the right thing to do.
>
>Preferably, the latter course should be done. We need Phoenix to
>compile.
>
I would say preferable the first course.
There are some important things comming up in the context threads that
demonstrate a fault in the specifications of both the meta and info
packages. These issues are comming up as a result of the recent user
community participation on Avalon dev - and I think addressing those
issues is more important than pushing through a major rewrite of the
Phoenix core (particularly a rewite that has zero community
participation). Ideally, that core should be based on meta descriptions
that are consistent across all containers - and the reality is that a
common solution is strait-forward.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by "Noel J. Bergman" <no...@devtech.com>.
AFAIK, the errors are related to Avalon's change from Component (a core
interface) to Service, along with related changes, such as from
ComponentManager to ServiceManager.
We'll adapt our code, but we didn't want to run the risk of breaking during
a release.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Peter Donald wrote:
>
> The changes were not in Phoenix but in cornerstone and were done at the
> request of a James developer IIRC (Was it Greg?). Obviously there was a
> disconnect when updating James.
http://gump.covalent.net/log/jakarta-james.html
The following changes seem to be the one that cause compatibility issues:
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-cornerstone/src/java/org/apache/avalon/cornerstone/services/connection/AbstractHandlerFactory.java.diff?r1=1.5&r2=1.6
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-cornerstone/src/java/org/apache/avalon/cornerstone/services/store/Store.java.diff?r1=1.6&r2=1.7
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Greg Steuck <gr...@nest.cx>.
Hello,
I'm a bit late to this conversation, couldn't keep up with all this
traffic during the week.
>>>>> "Peter" == Peter Donald <pe...@realityforge.org> writes:
Peter> This is a different issue. In this case the
Peter> cornerstone.services.store.Store was changed from
Peter> ComponentSelector to ServiceSelector
My change to Store was strictly in javadoc. The change that switched
Store to ServiceSelector was:
revision 1.7
date: 2002/09/24 12:16:56; author: donaldp; state: Exp; lines: +6 -7
Moved Cornerstone to Serviceable rather than Composable.
Submitted by: "Steve Short" <ss...@postx.com>
Peter> ... and
Peter> cornerstone.services.sockets.Abstract...Factory became
Peter> Serviceable rather than Composable.
cornerstone.blocks.sockets.*.java don't seem to use
framework.{service,component} packages at all.
Peter> This at the request of Greg Steuk (sp?) for James but it
Peter> seems like he wasn't a James committer.
Noel is absolutely right, I've never even used James.
Thanks
Greg
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
James, Avalon and Gump
Posted by "Noel J. Bergman" <no...@devtech.com>.
> This at the request of Greg Steuk (sp?) for James but it
> seems like he wasn't a James committer.
You mean Greg Steuck <gr...@nest.cx>? AFAIK, he is an Avalon
developer for whom eyebrowse has no record of ever having participated in a
james mailing list. Not that this is a partisan issue. Anyone wanting to
contribute on James would be welcomed.
In any event, Sam Ruby's point is well-taken. We've probably been remiss in
not talking to the Avalon Community more often, other than somewhat after
the fact. Previously, we've pretty much found out about problems with
Avalon changes when someone tried new jars and got bit. Once we get current
again with Avalon, gump would provide an early warning system that something
is amiss and needs attention.
So cascading issues, like these from the Avalon decision to drop the
Component interface in favor of Service, would be caught by effected clients
earlier, and in time to initiate a dialog about code changes, which probably
should have happened earlier but at least won't wait until even later.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 10 Dec 2002 17:53, Paul Hammant wrote:
> >In any event we are pretty current on Phoenix. We are backlevel for the
> >moment on Cornerstone. Since we are trying to put out a Release Build, we
> >have been reluctant to make the change until that is cut.
>
> Peter did some investigation (after we were pasted and pasted each other
> in the list) and was fairly sure that the Composable->Serviceable issue
> should not ultimately affect JAMES because the Phoenix implementation of
> Serviceable returns Components (capaital C) even when the service
> offered did not. Some careful use of casting is what was needed.
This is a different issue. In this case the cornerstone.services.store.Store
was changed from ComponentSelector to ServiceSelector and
cornerstone.services.sockets.Abstract...Factory became Serviceable rather
than Composable.
This at the request of Greg Steuk (sp?) for James but it seems like he wasn't
a James committer.
--
Cheers,
Peter Donald
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > From another way of looking, there is only Avalon, and multiple
> > packages that it ships. Avalon should bee responsible as a
> > community for all of the changes it makes, and the changes it
> > imposes upon client code.
> That may be true, but PLEASE stop using the term Avalon like it were a
> jar. Newbies pick up on and use it further.
Actually, I was pretty specific about the fact that there are multiple
packages (jars). But the context in which I used the word Avalon was in
reference to what should be a single Community, rather than an association
of developers sharing a CVS repository. When you start dividing the
community around whose jar file is getting gored, then we have a problem.
> Peter did some investigation (after we were pasted and pasted each other
> in the list) and was fairly sure that the Composable->Serviceable issue
> should not ultimately affect JAMES because the Phoenix implementation of
> Serviceable returns Components (capaital C) even when the service
> offered did not.
Yes, from what Peter said, he made an effort in Phoenix to return the right
thing as a runtime issue, and I do appreciate that effort.
The problem, Paul, is that some signatures changed and *THAT* is preventing
compilation. Check the log from Sam Ruby's post, and you'll see. :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
[..]
>Now, Paul probably has his fingers poised to reply, "Dude, there is no
>Avalon. There is Avalon-Frameworks, Avalon-Phoenix, Avalon-Cornerstone, and
>...", and that is the problem. From another way of looking, there is only
>Avalon, and multiple packages that it ships. Avalon should bee responsible
>as a community for all of the changes it makes, and the changes it imposes
>upon client code.
>
That may be true, but PLEASE stop using the term Avalon like it were a
jar. Newbies pick up on and use it further.
We try to be responible.
>In any event we are pretty current on Phoenix. We are backlevel for the
>moment on Cornerstone. Since we are trying to put out a Release Build, we
>have been reluctant to make the change until that is cut.
>
Peter did some investigation (after we were pasted and pasted each other
in the list) and was fairly sure that the Composable->Serviceable issue
should not ultimately affect JAMES because the Phoenix implementation of
Serviceable returns Components (capaital C) even when the service
offered did not. Some careful use of casting is what was needed.
>We'll do the update. For one thing, I'd like that fix I posted for the
>thread pool limits.
>
>
If we have not applied it, could you repost.. ?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The changes were not in Phoenix but in cornerstone and were done at the
> request of a James developer IIRC (Was it Greg?). Obviously there was a
> disconnect when updating James.
Whom?? (http://jakarta.apache.org/james/weare.html)
For what it is worth, we were pretty amenable to whatever changes Avalon was
making, since Paul Hammant had volunteered to help change our code to keep
in synch with Avalon. Then there were some more changes to Avalon, and Paul
froze which versions of Avalon "stuff" we were using. I don't recall at the
moment all of the compatibility issues. I think that Component was, at
least at one point, one of them.
Now, Paul probably has his fingers poised to reply, "Dude, there is no
Avalon. There is Avalon-Frameworks, Avalon-Phoenix, Avalon-Cornerstone, and
...", and that is the problem. From another way of looking, there is only
Avalon, and multiple packages that it ships. Avalon should bee responsible
as a community for all of the changes it makes, and the changes it imposes
upon client code.
In any event we are pretty current on Phoenix. We are backlevel for the
moment on Cornerstone. Since we are trying to put out a Release Build, we
have been reluctant to make the change until that is cut.
We'll do the update. For one thing, I'd like that fix I posted for the
thread pool limits.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 10 Dec 2002 08:15, Sam Ruby wrote:
> One the build failures for James start appearing, I would really like to
> see a productive dialog as to whether there are other, better supported,
> interfaces that James can use today (without needing to wait for another
> release of Phoenix), or if the interfaces that James is currently using
> should be supported for another release or more.
The changes were not in Phoenix but in cornerstone and were done at the
request of a James developer IIRC (Was it Greg?). Obviously there was a
disconnect when updating James.
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by "Noel J. Bergman" <no...@devtech.com>.
> One the build failures for James start appearing, I would really like to
> see a productive dialog as to whether there are other, better supported,
> interfaces that James can use today (without needing to wait for another
> release of Phoenix)
Not a problem. Our expectation is that we'll change the James code, which
is why we have deferred making the changes until we have put out our stable
Release Build.
> or if the interfaces that James is currently using
> should be supported for another release or more.
Gee, ya think? LOL Sorry. Pet peeve.
We already expect to update our code. I don't recall that it will be a
major hassle to do it again.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Noel J. Bergman wrote:
>>Hopefully, we can see a similar level of cooperation between
>>Phoenix and James when the James compilation errors start
>>appearing again.
>
> After we ship v2.1, we'll make the changes to use the revised code from
> Avalon.
>
> Again.
One the build failures for James start appearing, I would really like to
see a productive dialog as to whether there are other, better supported,
interfaces that James can use today (without needing to wait for another
release of Phoenix), or if the interfaces that James is currently using
should be supported for another release or more.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Hopefully, we can see a similar level of cooperation between
> Phoenix and James when the James compilation errors start
> appearing again.
After we ship v2.1, we'll make the changes to use the revised code from
Avalon.
Again.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Leo Sutic wrote:
>
> I patched it so that it should compile, but I have no idea
> if the patch follows the architectural intentions in Phoenix,
> and no idea on whether Phoenix works at all.
With this change, gump can compile phoenix. Hopefully, we can see a
similar level of cooperation between Phoenix and James when the James
compilation errors start appearing again.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Berin Loritsch [mailto:bloritsch@citi-us.com]
>>
>>Who wants to take responsibility for either reverting Phoenix
>>to the point where it no longer needs Info, or updating
>>Phoenix to use Info properly?
>>
>>Preferably, the latter course should be done. We need
>>Phoenix to compile.
>>
>>
>
>I took a look at it. Both ways seem equally long - reverting
>looks like having to back out major parts, making it use
>Info properly looks like having to add major parts.
>
>I patched it so that it should compile, but I have no idea
>if the patch follows the architectural intentions in Phoenix,
>and no idea on whether Phoenix works at all.
>
>If it compiles, then I'd say we leave it there. If there is
>a developer community around it, it can take over (maybe they're
>all bogged down with other work).
>
>
Another solution is to back out changes since the last release.
That should be easy to do and was relatively recent.
Steve.
>/LS
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@citi-us.com]
>
> Who wants to take responsibility for either reverting Phoenix
> to the point where it no longer needs Info, or updating
> Phoenix to use Info properly?
>
> Preferably, the latter course should be done. We need
> Phoenix to compile.
I took a look at it. Both ways seem equally long - reverting
looks like having to back out major parts, making it use
Info properly looks like having to add major parts.
I patched it so that it should compile, but I have no idea
if the patch follows the architectural intentions in Phoenix,
and no idea on whether Phoenix works at all.
If it compiles, then I'd say we leave it there. If there is
a developer community around it, it can take over (maybe they're
all bogged down with other work).
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: news [mailto:news@main.gmane.org]On Behalf Of Sam Ruby
>
> Berin Loritsch wrote:
> >
> > People who have not been working on Phoenix really don't know what
> > is going on with that project. I have subscribed to it, but with
> > all the volume of Avalon dev, Avalon users, et. al. it is hard to
> > notice when something like this happens.
>
> The reason why Avalon became a separate project was due to a similar
> lack of oversight by Jakarta.
>
> [technical details snipped]
>
> I don't have an opinion on the technical details. But I do have an
> opinion on the state of affairs when I see people aren't responsive.
The fact that the change slipped in under the radar is something we
can't change.
Who wants to take responsibility for either reverting Phoenix to the
point where it no longer needs Info, or updating Phoenix to use Info
properly?
Preferably, the latter course should be done. We need Phoenix to
compile.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Berin Loritsch wrote:
>
> People who have not been working on Phoenix really don't know what
> is going on with that project. I have subscribed to it, but with
> all the volume of Avalon dev, Avalon users, et. al. it is hard to
> notice when something like this happens.
The reason why Avalon became a separate project was due to a similar
lack of oversight by Jakarta.
[technical details snipped]
I don't have an opinion on the technical details. But I do have an
opinion on the state of affairs when I see people aren't responsive.
> The question becomes do we work with Meta, Info, or a new
> tool? I think the consensus is to work with a new tool for
> new development.
Short term, shouldn't Info have provided deprecated interfaces, or
shouldn't Phoenix change to use a set of interfaces that will be supported?
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 10 Dec 2002 03:36, Sam Ruby wrote:
>
>>So, let me see if I get this straight. The development version of
>>Phoenix (a.k.a., "the stable container") depends on something in the
>>sandbox.
>
> 99% of the stuff that it depends upon has not been independently released.
Phoenix must depend on released packages. IMO all avalon "projects" it
depends upon that are only used by Phoenix should be in Phoenix, not as
separate codebases, and this would eliminate the need to release other
stuff, since they would be part of the Phoenix release itself.
IMO if Phoenix needs the containerkit, info, etc stuff, which are used
only by him, it should keep them in its own CVS module.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 10 Dec 2002 03:36, Sam Ruby wrote:
> So, let me see if I get this straight. The development version of
> Phoenix (a.k.a., "the stable container") depends on something in the
> sandbox.
99% of the stuff that it depends upon has not been independently released.
> Furthermore, that something has already changed in a way that
> is incompatible with Phoenix's usage.
>
> Does this pretty much sum up the current state of affairs?
I think I said this to you before but you could delete the file the
compilation error occurs in and it would not effect the rest of the build.
--
Cheers,
Peter Donald
*----------------------------------------------------*
| "the mother of idiots is always pregnant." |
*----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 10 Dec 2002 04:04, Berin Loritsch wrote:
> The problem is that ContainerKit was originally intended to be
> the aggregation of container utilities. The model was too rigid,
> and when Steve tried to make some changes, he got vetoed. He
> created the Meta package to correct what he thought were the
> mistakes. I believe I tried to get them to work together, but
> neither were really willing. Later, instead of working with the
> already set up ContainerKit, Peter created the Info to address
> what he thought was a better architecture.
Not quite accurate. ContainerKit was used by Phoenix from day one. The
contents of the Info package where previously in ContainerKit but got broken
out because they were starting to stabilize. So stuff moved from Phoenix into
ContainerKit then from ContainerKit into Info.
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: news [mailto:news@main.gmane.org]On Behalf Of Sam Ruby
>
> Berin Loritsch wrote:
> >
> >> of cooperation - to this day, I still have been unable to locate
> >> the correct place to find and build the
> >> org.apache.avalon.framework.info classes. Any hints would be
> >> appreciated.
> >
> > :/
> >
> > Unfortunately, that was someone's planned library for future
> > inclusion. It is not voted upon, and not released yet.
> It was being
> > developed in Excalibur (info?)
>
> So, let me see if I get this straight. The development version of
> Phoenix (a.k.a., "the stable container") depends on something in the
> sandbox. Furthermore, that something has already changed in
> a way that
> is incompatible with Phoenix's usage.
>
> Does this pretty much sum up the current state of affairs?
It seems so.
People who have not been working on Phoenix really don't know what
is going on with that project. I have subscribed to it, but with
all the volume of Avalon dev, Avalon users, et. al. it is hard to
notice when something like this happens.
There may have been an anouncement that the change was going to
occur, but I cannot vouch for that ATM.
The problem is that ContainerKit was originally intended to be
the aggregation of container utilities. The model was too rigid,
and when Steve tried to make some changes, he got vetoed. He
created the Meta package to correct what he thought were the
mistakes. I believe I tried to get them to work together, but
neither were really willing. Later, instead of working with the
already set up ContainerKit, Peter created the Info to address
what he thought was a better architecture.
As to the technical qualifications of each of these, I can't
say one way or the other. My focus had been on providing a
better ECM with proper separation of concerns (aka Fortress).
In the end I think we will all agree that ContainerKit should
go the way of the graveyard as I don't think it is currently
supported in any way.
The question becomes do we work with Meta, Info, or a new
tool? I think the consensus is to work with a new tool for
new development.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Can we get an update on PMC voting rules?
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Berin Loritsch wrote:
>>
>>
>>
>>>I think we had a version that we all liked so far, and
>>>it is a question now of the vote. Is this being done
>>>in the PMC list?
>>>
>>>
>>>
>>>
>>Technically, yes - but I would prefer to do this as a community vote
>>followed by a PMC rubber stamp. If peoiple think that's silly, then
>>sure, we can just fire of a PMC vote.
>>
>>
>
>
>My thoughts as well.
>
>Let's do it!
>
OK - I'll start the vote later this evening.
Steve.
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Can we get an update on PMC voting rules?
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
>
> >I think we had a version that we all liked so far, and
> >it is a question now of the vote. Is this being done
> >in the PMC list?
> >
> >
>
> Technically, yes - but I would prefer to do this as a community vote
> followed by a PMC rubber stamp. If peoiple think that's silly, then
> sure, we can just fire of a PMC vote.
My thoughts as well.
Let's do it!
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Can we get an update on PMC voting rules?
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>It seems that the momentum we had for the PMC voting
>proposal has stalled in the wake of all the Context
>discussions (which I might add I suggested that we
>push that off until we have PMC docs in place and we
>start work on Avalon 5).
>
Actually, I think what we are seeing is that we have reached a point
where the voting procedures stuff is ready to put to a vote. I can
start that of ASAP.
>
>I think we had a version that we all liked so far, and
>it is a question now of the vote. Is this being done
>in the PMC list?
>
>
Technically, yes - but I would prefer to do this as a community vote
followed by a PMC rubber stamp. If peoiple think that's silly, then
sure, we can just fire of a PMC vote.
>I also suggest that we follow the procedures set forth
>in the document for PMC charter changes. After that
>I suggest we tackle the issue of PMC adding and removing
>of members that I already started in another thread.
>
>
+1
Cheers, Steve.
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Can we get an update on PMC voting rules?
Posted by Berin Loritsch <bl...@citi-us.com>.
It seems that the momentum we had for the PMC voting
proposal has stalled in the wake of all the Context
discussions (which I might add I suggested that we
push that off until we have PMC docs in place and we
start work on Avalon 5).
I think we had a version that we all liked so far, and
it is a question now of the vote. Is this being done
in the PMC list?
I also suggest that we follow the procedures set forth
in the document for PMC charter changes. After that
I suggest we tackle the issue of PMC adding and removing
of members that I already started in another thread.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>>From: news [mailto:news@main.gmane.org] On Behalf Of Sam Ruby
>>
>>What does concerns me, however, is when knowledge of such events and
>>fail to spark a dialog. Particuarly, when this is all within the
>>scope of a single project.
>>
>>
>
>To say that Phoenix is in the scope of Avalon is not 100% right.
>Well, it is technically and let me stress that it should be, but
>consider this:
>
> + We've had a year+ of separate email lists.
>
> + People developing Phoenix have in some instances been completely
> unaware of Avalon.
>
>In short - there is a major chasm here. Result: When things like this
>happen, people will just think "not my problem". I know I did.
>
>The above is not an excuse, but a statement of fact.
>
>
+1
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Sam Ruby
>
> What does concerns me, however, is when knowledge of such events and
> fail to spark a dialog. Particuarly, when this is all within the
> scope of a single project.
To say that Phoenix is in the scope of Avalon is not 100% right.
Well, it is technically and let me stress that it should be, but
consider this:
+ We've had a year+ of separate email lists.
+ People developing Phoenix have in some instances been completely
unaware of Avalon.
In short - there is a major chasm here. Result: When things like this
happen, people will just think "not my problem". I know I did.
The above is not an excuse, but a statement of fact.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Berin Loritsch wrote:
>
>> Editorial comment: there are people who are actively trying to
>> build Avalon related components - if for no other reason than to
>> verify the correct operation of projects they care about (e.g. Ant)
>> or to identify things that other subprojects (e.g., james) may need
>> to be aware of at some point. At times, this requires a little bit
>> of cooperation - to this day, I still have been unable to locate
>> the correct place to find and build the
>> org.apache.avalon.framework.info classes. Any hints would be
>> appreciated.
>
> :/
>
> Unfortunately, that was someone's planned library for future
> inclusion. It is not voted upon, and not released yet. It was being
> developed in Excalibur (info?)
So, let me see if I get this straight. The development version of
Phoenix (a.k.a., "the stable container") depends on something in the
sandbox. Furthermore, that something has already changed in a way that
is incompatible with Phoenix's usage.
Does this pretty much sum up the current state of affairs?
If so, the fact that these things happen doesn't concern me. What does
concerns me, however, is when knowledge of such events and fail to spark
a dialog. Particuarly, when this is all within the scope of a single
project.
>> Who knows, this might even foster a bit more cooperation and
>> communication within the Avalon project.
>
> :)
Perhaps that smiley is a bit premature.
http://cvs.apache.org/builds/gump/2002-12-09/jakarta-avalon-phoenix.html
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: news [mailto:news@main.gmane.org]On Behalf Of Sam Ruby
> Editorial comment: there are people who are actively trying to build
> Avalon related components - if for no other reason than to verify the
> correct operation of projects they care about (e.g. Ant) or
> to identify
> things that other subprojects (e.g., james) may need to be
> aware of at
> some point. At times, this requires a little bit of cooperation - to
> this day, I still have been unable to locate the correct
> place to find
> and build the org.apache.avalon.framework.info classes. Any
> hints would
> be appreciated.
:/
Unfortunately, that was someone's planned library for future
inclusion. It is not voted upon, and not released yet. It was
being developed in Excalibur (info?)
> In return, you will have nightly builds that are internally self
> consistent - each component that depends on the common
> framework will be
> built with the same version of that framework.
>
> Who knows, this might even foster a bit more cooperation and
> communication within the Avalon project.
:)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by Leo Simons <le...@apache.org>.
> Leo Simons wrote:
> > Hi gang,
> >
> > Gump has an entry for excalibur-containerkit, which I've
> just moved to
> > the avalon-sandbox cvs. The sourcepath for this entry needs to be
> > updated, but even after lots of headscratching I can't
> figure out what
> > to do; the <home/> and <work/> tags probably both need to
> change but
> > it's unclear to me to what; and I can't find the <module/>
> definitions
> > at all!
> >
> > could someone with more gump knowledge take a peek?
>
> Stephan Bodewig constructed and committed a correct entry -
> before you
> even posted this e-mail.
That'd give him the amazing time window of roughly 10 mins for becoming
aware of the (new) problem, creating the solution, _and_ committing it.
Astounding! :D
There's some mail hiccups atm, I suspect half is the problem of our uni
(re those pictures of lots of smoke in the ICT building), the other half
is @ apache, but it's having some weird effects....
> Editorial comment: there are people who are actively trying to build
> Avalon related components - if for no other reason than to verify the
> correct operation of projects they care about (e.g. Ant) or to
identify
> things that other subprojects (e.g., james) may need to be aware of at
> some point. At times, this requires a little bit of cooperation - to
> this day, I still have been unable to locate the correct place to find
> and build the org.apache.avalon.framework.info classes. Any hints
would
> be appreciated.
These used to be in jakarta-avalon-excalibur/info, and have just moved
to
avalon-sandbox/info/. Getting avalon "gumped" completely is #2 on
my todo list (#1 is charter/community stuff); this is just one of many
points
to address IIUC. Note it is hardly appropriate for non-alpha non-avalon
materials to reference that code as it's somewhat contentious but that's
not
the point atm :D
> In return, you will have nightly builds that are internally self
> consistent - each component that depends on the common framework will
be
> built with the same version of that framework.
>
> Who knows, this might even foster a bit more cooperation and
> communication within the Avalon project.
My thoughts exactly! Me and some others have been rather ignorant of
Gump
and this'll change soon I hope. My POA:
- figure out gump from nitter to gritter (I've got it running locally
but ran
out of disk space ;)
- get all avalon bits building using gump
- 'normalize' gump usage in avalon
- submit patches to gump docs detailing the things I found out but
didn't
"get" at first
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by Leo Simons <le...@apache.org>.
> Leo Simons wrote:
> > Hi gang,
> >
> > Gump has an entry for excalibur-containerkit, which I've
> just moved to
> > the avalon-sandbox cvs. The sourcepath for this entry needs to be
> > updated, but even after lots of headscratching I can't
> figure out what
> > to do; the <home/> and <work/> tags probably both need to
> change but
> > it's unclear to me to what; and I can't find the <module/>
> definitions
> > at all!
> >
> > could someone with more gump knowledge take a peek?
>
> Stephan Bodewig constructed and committed a correct entry -
> before you
> even posted this e-mail.
That'd give him the amazing time window of roughly 10 mins for becoming
aware of the (new) problem, creating the solution, _and_ committing it.
Astounding! :D
There's some mail hiccups atm, I suspect half is the problem of our uni
(re those pictures of lots of smoke in the ICT building), the other half
is @ apache, but it's having some weird effects....
> Editorial comment: there are people who are actively trying to build
> Avalon related components - if for no other reason than to verify the
> correct operation of projects they care about (e.g. Ant) or to
identify
> things that other subprojects (e.g., james) may need to be aware of at
> some point. At times, this requires a little bit of cooperation - to
> this day, I still have been unable to locate the correct place to find
> and build the org.apache.avalon.framework.info classes. Any hints
would
> be appreciated.
These used to be in jakarta-avalon-excalibur/info, and have just moved
to
avalon-sandbox/info/. Getting avalon "gumped" completely is #2 on
my todo list (#1 is charter/community stuff); this is just one of many
points
to address IIUC. Note it is hardly appropriate for non-alpha non-avalon
materials to reference that code as it's somewhat contentious but that's
not
the point atm :D
> In return, you will have nightly builds that are internally self
> consistent - each component that depends on the common framework will
be
> built with the same version of that framework.
>
> Who knows, this might even foster a bit more cooperation and
> communication within the Avalon project.
My thoughts exactly! Me and some others have been rather ignorant of
Gump
and this'll change soon I hope. My POA:
- figure out gump from nitter to gritter (I've got it running locally
but ran
out of disk space ;)
- get all avalon bits building using gump
- 'normalize' gump usage in avalon
- submit patches to gump docs detailing the things I found out but
didn't
"get" at first
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by Leo Simons <le...@apache.org>.
> Leo Simons wrote:
> > Hi gang,
> >
> > Gump has an entry for excalibur-containerkit, which I've
> just moved to
> > the avalon-sandbox cvs. The sourcepath for this entry needs to be
> > updated, but even after lots of headscratching I can't
> figure out what
> > to do; the <home/> and <work/> tags probably both need to
> change but
> > it's unclear to me to what; and I can't find the <module/>
> definitions
> > at all!
> >
> > could someone with more gump knowledge take a peek?
>
> Stephan Bodewig constructed and committed a correct entry -
> before you
> even posted this e-mail.
That'd give him the amazing time window of roughly 10 mins for becoming
aware of the (new) problem, creating the solution, _and_ committing it.
Astounding! :D
There's some mail hiccups atm, I suspect half is the problem of our uni
(re those pictures of lots of smoke in the ICT building), the other half
is @ apache, but it's having some weird effects....
> Editorial comment: there are people who are actively trying to build
> Avalon related components - if for no other reason than to verify the
> correct operation of projects they care about (e.g. Ant) or to
identify
> things that other subprojects (e.g., james) may need to be aware of at
> some point. At times, this requires a little bit of cooperation - to
> this day, I still have been unable to locate the correct place to find
> and build the org.apache.avalon.framework.info classes. Any hints
would
> be appreciated.
These used to be in jakarta-avalon-excalibur/info, and have just moved
to
avalon-sandbox/info/. Getting avalon "gumped" completely is #2 on
my todo list (#1 is charter/community stuff); this is just one of many
points
to address IIUC. Note it is hardly appropriate for non-alpha non-avalon
materials to reference that code as it's somewhat contentious but that's
not
the point atm :D
> In return, you will have nightly builds that are internally self
> consistent - each component that depends on the common framework will
be
> built with the same version of that framework.
>
> Who knows, this might even foster a bit more cooperation and
> communication within the Avalon project.
My thoughts exactly! Me and some others have been rather ignorant of
Gump
and this'll change soon I hope. My POA:
- figure out gump from nitter to gritter (I've got it running locally
but ran
out of disk space ;)
- get all avalon bits building using gump
- 'normalize' gump usage in avalon
- submit patches to gump docs detailing the things I found out but
didn't
"get" at first
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: news [mailto:news@main.gmane.org]On Behalf Of Sam Ruby
> Editorial comment: there are people who are actively trying to build
> Avalon related components - if for no other reason than to verify the
> correct operation of projects they care about (e.g. Ant) or
> to identify
> things that other subprojects (e.g., james) may need to be
> aware of at
> some point. At times, this requires a little bit of cooperation - to
> this day, I still have been unable to locate the correct
> place to find
> and build the org.apache.avalon.framework.info classes. Any
> hints would
> be appreciated.
:/
Unfortunately, that was someone's planned library for future
inclusion. It is not voted upon, and not released yet. It was
being developed in Excalibur (info?)
> In return, you will have nightly builds that are internally self
> consistent - each component that depends on the common
> framework will be
> built with the same version of that framework.
>
> Who knows, this might even foster a bit more cooperation and
> communication within the Avalon project.
:)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: gump entry for containerkit
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: news [mailto:news@main.gmane.org]On Behalf Of Sam Ruby
> Editorial comment: there are people who are actively trying to build
> Avalon related components - if for no other reason than to verify the
> correct operation of projects they care about (e.g. Ant) or
> to identify
> things that other subprojects (e.g., james) may need to be
> aware of at
> some point. At times, this requires a little bit of cooperation - to
> this day, I still have been unable to locate the correct
> place to find
> and build the org.apache.avalon.framework.info classes. Any
> hints would
> be appreciated.
:/
Unfortunately, that was someone's planned library for future
inclusion. It is not voted upon, and not released yet. It was
being developed in Excalibur (info?)
> In return, you will have nightly builds that are internally self
> consistent - each component that depends on the common
> framework will be
> built with the same version of that framework.
>
> Who knows, this might even foster a bit more cooperation and
> communication within the Avalon project.
:)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
> Hi gang,
>
> Gump has an entry for excalibur-containerkit, which I've just moved to
> the avalon-sandbox cvs. The sourcepath for this entry needs to be
> updated, but even after lots of headscratching I can't figure out what
> to do; the <home/> and <work/> tags probably both need to change but
> it's unclear to me to what; and I can't find the <module/> definitions
> at all!
>
> could someone with more gump knowledge take a peek?
Stephan Bodewig constructed and committed a correct entry - before you
even posted this e-mail.
http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/project/avalon-sandbox.xml
Editorial comment: there are people who are actively trying to build
Avalon related components - if for no other reason than to verify the
correct operation of projects they care about (e.g. Ant) or to identify
things that other subprojects (e.g., james) may need to be aware of at
some point. At times, this requires a little bit of cooperation - to
this day, I still have been unable to locate the correct place to find
and build the org.apache.avalon.framework.info classes. Any hints would
be appreciated.
In return, you will have nightly builds that are internally self
consistent - each component that depends on the common framework will be
built with the same version of that framework.
Who knows, this might even foster a bit more cooperation and
communication within the Avalon project.
Just my 2 cents.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stefan Bodewig <bo...@apache.org>.
On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
> Gump has an entry for excalibur-containerkit, which I've just moved
> to the avalon-sandbox cvs.
I'll give it an updated descriptor a try and keep you posted.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
> Hi gang,
>
> Gump has an entry for excalibur-containerkit, which I've just moved to
> the avalon-sandbox cvs. The sourcepath for this entry needs to be
> updated, but even after lots of headscratching I can't figure out what
> to do; the <home/> and <work/> tags probably both need to change but
> it's unclear to me to what; and I can't find the <module/> definitions
> at all!
>
> could someone with more gump knowledge take a peek?
Stephan Bodewig constructed and committed a correct entry - before you
even posted this e-mail.
http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/project/avalon-sandbox.xml
Editorial comment: there are people who are actively trying to build
Avalon related components - if for no other reason than to verify the
correct operation of projects they care about (e.g. Ant) or to identify
things that other subprojects (e.g., james) may need to be aware of at
some point. At times, this requires a little bit of cooperation - to
this day, I still have been unable to locate the correct place to find
and build the org.apache.avalon.framework.info classes. Any hints would
be appreciated.
In return, you will have nightly builds that are internally self
consistent - each component that depends on the common framework will be
built with the same version of that framework.
Who knows, this might even foster a bit more cooperation and
communication within the Avalon project.
Just my 2 cents.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>Hi gang,
>
>Gump has an entry for excalibur-containerkit, which I've just moved to
>the avalon-sandbox cvs. The sourcepath for this entry needs to be
>updated, but even after lots of headscratching I can't figure out what
>to do; the <home/> and <work/> tags probably both need to change but
>it's unclear to me to what; and I can't find the <module/> definitions
>at all!
>
http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
Steve.
>
>could someone with more gump knowledge take a peek?
>
>cheers,
>
>- Leo
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stefan Bodewig <bo...@apache.org>.
On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
> Gump has an entry for excalibur-containerkit, which I've just moved
> to the avalon-sandbox cvs.
I'll give it an updated descriptor a try and keep you posted.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
> Hi gang,
>
> Gump has an entry for excalibur-containerkit, which I've just moved to
> the avalon-sandbox cvs. The sourcepath for this entry needs to be
> updated, but even after lots of headscratching I can't figure out what
> to do; the <home/> and <work/> tags probably both need to change but
> it's unclear to me to what; and I can't find the <module/> definitions
> at all!
>
> could someone with more gump knowledge take a peek?
Stephan Bodewig constructed and committed a correct entry - before you
even posted this e-mail.
http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/project/avalon-sandbox.xml
Editorial comment: there are people who are actively trying to build
Avalon related components - if for no other reason than to verify the
correct operation of projects they care about (e.g. Ant) or to identify
things that other subprojects (e.g., james) may need to be aware of at
some point. At times, this requires a little bit of cooperation - to
this day, I still have been unable to locate the correct place to find
and build the org.apache.avalon.framework.info classes. Any hints would
be appreciated.
In return, you will have nightly builds that are internally self
consistent - each component that depends on the common framework will be
built with the same version of that framework.
Who knows, this might even foster a bit more cooperation and
communication within the Avalon project.
Just my 2 cents.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>Hi gang,
>
>Gump has an entry for excalibur-containerkit, which I've just moved to
>the avalon-sandbox cvs. The sourcepath for this entry needs to be
>updated, but even after lots of headscratching I can't figure out what
>to do; the <home/> and <work/> tags probably both need to change but
>it's unclear to me to what; and I can't find the <module/> definitions
>at all!
>
http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2
Steve.
>
>could someone with more gump knowledge take a peek?
>
>cheers,
>
>- Leo
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: gump entry for containerkit
Posted by Stefan Bodewig <bo...@apache.org>.
On 04 Dec 2002, Leo Simons <le...@apache.org> wrote:
> Gump has an entry for excalibur-containerkit, which I've just moved
> to the avalon-sandbox cvs.
I'll give it an updated descriptor a try and keep you posted.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>