You are viewing a plain text version of this content. The canonical link for it is here.
Posted to library-dev@jakarta.apache.org by Peter Donald <do...@apache.org> on 2001/03/01 00:40:06 UTC
Re: Riffing again on another tangent
At 04:01 1/3/01 -0800, cmanolache@yahoo.com wrote:
>> > So in a sense, Directory is another library project with open
>> > rules (like agora). (Not sure if Agora was going to be a
>> > Library peer in Jakarta-land, or a 'product peer' in Library-land.
>>
>> My biggest concern is that I don't understand the relationship between
>> Library, Directory, Agora, and Avalon.
>
>The proposed project ( library/directory/agora/whatever ) is indeed
>similar with avalon in one of the goals - creating server side components.
>( and also to jakarta-tools )
ie Avalon has identical content but ...
>But IMHO the current proposal is closer to alexandria then avalon.
>
>But what's special about the library/agora is that it proposes to
>act as a common repository, managed in common by multiple projects. While
>creating productized components is also a goal ( same as in Avalon ), the
>sharing of components and inter-project dynamics are more important.
From this point of view, avalon is one of the projects that will share
>components - equal with all other projects where general-purpose code is
>developed.
different infrastructure. Since I think the infrastructure we create
will/should be integrated into all projects - what will happen when we
integrate it into Avalon? We will have two identical projects.
>Beeing "project-neutral" is important to create what we need.
This would be the only sticking point I see. It is unfortunate that other
projects are seen as "competitors" rather than "companions" but I guess
until this is "fixed" it could be an issue. However instead of starting
again I would prefer that we try to start fixing things now.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Riffing again on another tangent
Posted by Peter Donald <do...@apache.org>.
At 10:27 1/3/01 -0800, cmanolache@yahoo.com wrote:
>Well, sorry about the previous mail, it didn't sounded as I wanted.
;)
>All I'm trying to say is that the Library is significantly bigger than
>Avalon - in both scope and intended community.
I think you are mixing content and form.
The form being the infrastructure (gump/cjan etc). The form is
fundamentally larger than any other aspect in this project and IMHO it
should be a separate entity in itself integrated into ant/alexandria/gump.
I would propose this but I am not willing to do the work ;)
I believe Jon even created either a directory or CVS or something for CJAN
but as yet only one other person (Conor from ant-dev) has expressed
interesting in actually doing the work ;) The details of which are buried
somewhere in ant-dev archives - though I could search through them if you
want ;)
The content between proposed library content and Avalon overlaps however
which I would want to avoid.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Riffing again on another tangent
Posted by Peter Donald <do...@apache.org>.
At 10:27 1/3/01 -0800, cmanolache@yahoo.com wrote:
>Well, sorry about the previous mail, it didn't sounded as I wanted.
;)
>All I'm trying to say is that the Library is significantly bigger than
>Avalon - in both scope and intended community.
I think you are mixing content and form.
The form being the infrastructure (gump/cjan etc). The form is
fundamentally larger than any other aspect in this project and IMHO it
should be a separate entity in itself integrated into ant/alexandria/gump.
I would propose this but I am not willing to do the work ;)
I believe Jon even created either a directory or CVS or something for CJAN
but as yet only one other person (Conor from ant-dev) has expressed
interesting in actually doing the work ;) The details of which are buried
somewhere in ant-dev archives - though I could search through them if you
want ;)
The content between proposed library content and Avalon overlaps however
which I would want to avoid.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Riffing again on another tangent
Posted by David Weinrich <dw...@home.com>.
On Thu, 1 Mar 2001, Peter Donald wrote:
>
> When you say Avalon - what are you referring to exactly? If you are
> referring to the frameowork components or cornerstone components then I
> agree - if not then you are going to have to explain it further ;)
> Cheers,
>
I think this is the core issue that we are having problem resolving here.
Avalon is not clearly defined enough for us to make this judgement from
outside, and the sources of information ( the website vs. the emails
posted by yourself describing Avalon ) are sufficiently different to cause
even more confusion. I think we are very close to reaching a consensus on
what the Commons project and the Library/Agora/Catlog services within that
project consist of, and the goals of the project. And to be brief ( while
also beating the poor dead horse yet again ), Avalon has an existing
product for which it is known for, an existing set of developers who
developed that product with specific design goals and methods, and an
existing userbase that is using that product ( James is based upon Avalon
if I understand correctly ). Instead of trying to cram the
ideas/goals/objectives identified on this list into an existing project,
why don't we move forward and create a set of services and infrastructure
without destroying what Avalon has already done or is trying to do.
David
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
>
Re: Riffing again on another tangent
Posted by David Weinrich <dw...@home.com>.
On Thu, 1 Mar 2001, Peter Donald wrote:
>
> When you say Avalon - what are you referring to exactly? If you are
> referring to the frameowork components or cornerstone components then I
> agree - if not then you are going to have to explain it further ;)
> Cheers,
>
I think this is the core issue that we are having problem resolving here.
Avalon is not clearly defined enough for us to make this judgement from
outside, and the sources of information ( the website vs. the emails
posted by yourself describing Avalon ) are sufficiently different to cause
even more confusion. I think we are very close to reaching a consensus on
what the Commons project and the Library/Agora/Catlog services within that
project consist of, and the goals of the project. And to be brief ( while
also beating the poor dead horse yet again ), Avalon has an existing
product for which it is known for, an existing set of developers who
developed that product with specific design goals and methods, and an
existing userbase that is using that product ( James is based upon Avalon
if I understand correctly ). Instead of trying to cram the
ideas/goals/objectives identified on this list into an existing project,
why don't we move forward and create a set of services and infrastructure
without destroying what Avalon has already done or is trying to do.
David
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
>
Re: Riffing again on another tangent
Posted by Peter Donald <do...@apache.org>.
At 10:25 1/3/01 -0800, cmanolache@yahoo.com wrote:
>> But Avalon was intended to be a shared repository of server-side components
>> - it has no other purpose ;) All the other projects create server-side
>> components as a side effect of developing another product. Avalons product
>> is the components.
>
>Which is a very generic term - like saying the goal of a project is to
>create java code, or a server-side templating system.
Or perhaps that the goal of this project is to create library of reusable
components for server side products - oh wait - thats the goal of this
project ! ;)
>And if you are saying that Avalon was supposed to do what we want for the
>libary - provide "catalog" and "common development" for projects - then it
>obviously failed ( since jakarta projects are still duplicating code
>instead of participating in avalon ) - so there is no point in discussing
>this :-)
Well yes a lot of people have said Avalon has failed so far ;) But that
doesn't say it still can not suceed ;)
>> I don't see how having two separate projects who do the same thing could be
>> good for jakarta. Could you imagine if someone proposed another servlet
>> engine at jakarta - Do you think that another servlet engine that served
>> roughly the same purpose would be good for Jakarta? (I don't think so)
>> Would it be good for Tomcat ? (not really) Would it be good for foo servlet
>> engine ? (perhaps they get associated with Apache).
>
>Yes, that already happened and we survived. I would say ( IMHO !!) that
>the net effect was quite good (!).
>
>And Apache has 2 xml parsers,
which serve different purposes
>multiple template engines,
which serve different purposes
>multiple flavors of regexps.
don't know what the difference is between them ;)
>Choice is good - each may be better suited for a different
>environment ( like tomcat 3.x is the only solution for JDK1.1 and
>catalina / 4.x for people wanting servlet 2.3 support - to give only a
>"neutral" example )
3.3 vs catalina is the same project just different versions. Once catalina
graduates I assume 3.x will no longer be distributed at the same time and
catalina will adopt Tomcat name.
It is actually this type of approach that I am advocating. Consider Avalon
as the 3.3 that currently exists and library as the 4.x version ;) I
welcome internal fork forks but parrallel development in jakarta on very
similar products is not something I want to see.
>> I agree - all code sits on its' own merits and these components should not
>> (at least in base form) be integrated into the rest of Avalon. The
>> cornerstone CVS may integrate components from the catalog/agora CVS into
>> the Avalon services/kernel API but I don't see this as something the
>> catalog/agora should do by itself.
>
>I see it the other way around - avalon components should be treated equal
>with components developed by other projects, and "promoted" based on
>their actual use in projects and user adoption.
Isn't that what I just said ? ;)
>Merging this project with avalon would sugest that avalon components are
>"special" compared with components from other project. And that would be
>wrong.
I am not sure where you get this impression - I hope I haven't given you
that impression. Even within Avalon we have had competing implementaions of
things. At one stage we had 3 different pooling frameworks, 3 different
schedulers and different server-socket abstractions. Merit determins which
ones last and which are burned away.
>> By opening another CVS and giving everybody karma/voting rights/whatever
>> then I believe the community would manage itself ;) If you think it is a
>> bad idea to integrate with the framework part of Avalon then don't ;) I
>> would even allow components integrated with other frameworks be added (with
>> the proviso that they would be refactored to use JavaBeans standard
overtime).
>
>Again - I think it's the other way around.
>
>Avalon components could be integrated in the library, if they are not
>dependent on a framework - and avalon decides to.
When you say Avalon - what are you referring to exactly? If you are
referring to the frameowork components or cornerstone components then I
agree - if not then you are going to have to explain it further ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Riffing again on another tangent
Posted by Peter Donald <do...@apache.org>.
At 10:25 1/3/01 -0800, cmanolache@yahoo.com wrote:
>> But Avalon was intended to be a shared repository of server-side components
>> - it has no other purpose ;) All the other projects create server-side
>> components as a side effect of developing another product. Avalons product
>> is the components.
>
>Which is a very generic term - like saying the goal of a project is to
>create java code, or a server-side templating system.
Or perhaps that the goal of this project is to create library of reusable
components for server side products - oh wait - thats the goal of this
project ! ;)
>And if you are saying that Avalon was supposed to do what we want for the
>libary - provide "catalog" and "common development" for projects - then it
>obviously failed ( since jakarta projects are still duplicating code
>instead of participating in avalon ) - so there is no point in discussing
>this :-)
Well yes a lot of people have said Avalon has failed so far ;) But that
doesn't say it still can not suceed ;)
>> I don't see how having two separate projects who do the same thing could be
>> good for jakarta. Could you imagine if someone proposed another servlet
>> engine at jakarta - Do you think that another servlet engine that served
>> roughly the same purpose would be good for Jakarta? (I don't think so)
>> Would it be good for Tomcat ? (not really) Would it be good for foo servlet
>> engine ? (perhaps they get associated with Apache).
>
>Yes, that already happened and we survived. I would say ( IMHO !!) that
>the net effect was quite good (!).
>
>And Apache has 2 xml parsers,
which serve different purposes
>multiple template engines,
which serve different purposes
>multiple flavors of regexps.
don't know what the difference is between them ;)
>Choice is good - each may be better suited for a different
>environment ( like tomcat 3.x is the only solution for JDK1.1 and
>catalina / 4.x for people wanting servlet 2.3 support - to give only a
>"neutral" example )
3.3 vs catalina is the same project just different versions. Once catalina
graduates I assume 3.x will no longer be distributed at the same time and
catalina will adopt Tomcat name.
It is actually this type of approach that I am advocating. Consider Avalon
as the 3.3 that currently exists and library as the 4.x version ;) I
welcome internal fork forks but parrallel development in jakarta on very
similar products is not something I want to see.
>> I agree - all code sits on its' own merits and these components should not
>> (at least in base form) be integrated into the rest of Avalon. The
>> cornerstone CVS may integrate components from the catalog/agora CVS into
>> the Avalon services/kernel API but I don't see this as something the
>> catalog/agora should do by itself.
>
>I see it the other way around - avalon components should be treated equal
>with components developed by other projects, and "promoted" based on
>their actual use in projects and user adoption.
Isn't that what I just said ? ;)
>Merging this project with avalon would sugest that avalon components are
>"special" compared with components from other project. And that would be
>wrong.
I am not sure where you get this impression - I hope I haven't given you
that impression. Even within Avalon we have had competing implementaions of
things. At one stage we had 3 different pooling frameworks, 3 different
schedulers and different server-socket abstractions. Merit determins which
ones last and which are burned away.
>> By opening another CVS and giving everybody karma/voting rights/whatever
>> then I believe the community would manage itself ;) If you think it is a
>> bad idea to integrate with the framework part of Avalon then don't ;) I
>> would even allow components integrated with other frameworks be added (with
>> the proviso that they would be refactored to use JavaBeans standard
overtime).
>
>Again - I think it's the other way around.
>
>Avalon components could be integrated in the library, if they are not
>dependent on a framework - and avalon decides to.
When you say Avalon - what are you referring to exactly? If you are
referring to the frameowork components or cornerstone components then I
agree - if not then you are going to have to explain it further ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Riffing again on another tangent
Posted by David Weinrich <dw...@home.com>.
On Wed, 28 Feb 2001, Craig R. McClanahan wrote:
> Peter Donald wrote:
>
> > At 09:18 1/3/01 -0800, cmanolache@yahoo.com wrote:
> > >Arguing that this should be part of avalon because it overlaps with
> > >it's goal is wrong - the library will overlap with almost all
> > >jakarta projects. It overlaps with jakarta-tools ( which also overlaps
> > >with avalon ), it overlaps with alexandria. All jakarta
> > >projects are creating some forms of server-side compoents
> > >( including tomcat ).
> >
> > But Avalon was intended to be a shared repository of server-side components
> > - it has no other purpose ;) All the other projects create server-side
> > components as a side effect of developing another product. Avalons product
> > is the components.
> >
>
> Peter, when you say "components" here, I need a clarification. Do you mean "a
> chunk of reusable code" or "a chunk of reusable code that implement's Avalon's
> notion of a Component interface"? These are two entirely different things. If
> it's the former, I'd still prefer agora/commons/whatever to be separate -- if it's
> the latter, then that's just as presumptive as me saying it should live in Struts,
> or Jon saying it should live in Turbine (neither of which is happening).
>
> The shareable stuff I'm interested in is smaller than a framework --- any
> framework.
>
I agree with this completely. I also appreciate your presence and Remy's
presence on the list today as I think this is a pretty good indication
that we are making progress, and that the desire/need for this stuff exists in
jakarta-land. Thanks :)
David
> Craig McClanahan
>
>
>
Re: Riffing again on another tangent
Posted by David Weinrich <dw...@home.com>.
On Wed, 28 Feb 2001, Craig R. McClanahan wrote:
> Peter Donald wrote:
>
> > At 09:18 1/3/01 -0800, cmanolache@yahoo.com wrote:
> > >Arguing that this should be part of avalon because it overlaps with
> > >it's goal is wrong - the library will overlap with almost all
> > >jakarta projects. It overlaps with jakarta-tools ( which also overlaps
> > >with avalon ), it overlaps with alexandria. All jakarta
> > >projects are creating some forms of server-side compoents
> > >( including tomcat ).
> >
> > But Avalon was intended to be a shared repository of server-side components
> > - it has no other purpose ;) All the other projects create server-side
> > components as a side effect of developing another product. Avalons product
> > is the components.
> >
>
> Peter, when you say "components" here, I need a clarification. Do you mean "a
> chunk of reusable code" or "a chunk of reusable code that implement's Avalon's
> notion of a Component interface"? These are two entirely different things. If
> it's the former, I'd still prefer agora/commons/whatever to be separate -- if it's
> the latter, then that's just as presumptive as me saying it should live in Struts,
> or Jon saying it should live in Turbine (neither of which is happening).
>
> The shareable stuff I'm interested in is smaller than a framework --- any
> framework.
>
I agree with this completely. I also appreciate your presence and Remy's
presence on the list today as I think this is a pretty good indication
that we are making progress, and that the desire/need for this stuff exists in
jakarta-land. Thanks :)
David
> Craig McClanahan
>
>
>
Re: Riffing again on another tangent
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Peter Donald wrote:
> At 09:18 1/3/01 -0800, cmanolache@yahoo.com wrote:
> >Arguing that this should be part of avalon because it overlaps with
> >it's goal is wrong - the library will overlap with almost all
> >jakarta projects. It overlaps with jakarta-tools ( which also overlaps
> >with avalon ), it overlaps with alexandria. All jakarta
> >projects are creating some forms of server-side compoents
> >( including tomcat ).
>
> But Avalon was intended to be a shared repository of server-side components
> - it has no other purpose ;) All the other projects create server-side
> components as a side effect of developing another product. Avalons product
> is the components.
>
Peter, when you say "components" here, I need a clarification. Do you mean "a
chunk of reusable code" or "a chunk of reusable code that implement's Avalon's
notion of a Component interface"? These are two entirely different things. If
it's the former, I'd still prefer agora/commons/whatever to be separate -- if it's
the latter, then that's just as presumptive as me saying it should live in Struts,
or Jon saying it should live in Turbine (neither of which is happening).
The shareable stuff I'm interested in is smaller than a framework --- any
framework.
Craig McClanahan
Re: Riffing again on another tangent
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Peter Donald wrote:
> At 09:18 1/3/01 -0800, cmanolache@yahoo.com wrote:
> >Arguing that this should be part of avalon because it overlaps with
> >it's goal is wrong - the library will overlap with almost all
> >jakarta projects. It overlaps with jakarta-tools ( which also overlaps
> >with avalon ), it overlaps with alexandria. All jakarta
> >projects are creating some forms of server-side compoents
> >( including tomcat ).
>
> But Avalon was intended to be a shared repository of server-side components
> - it has no other purpose ;) All the other projects create server-side
> components as a side effect of developing another product. Avalons product
> is the components.
>
Peter, when you say "components" here, I need a clarification. Do you mean "a
chunk of reusable code" or "a chunk of reusable code that implement's Avalon's
notion of a Component interface"? These are two entirely different things. If
it's the former, I'd still prefer agora/commons/whatever to be separate -- if it's
the latter, then that's just as presumptive as me saying it should live in Struts,
or Jon saying it should live in Turbine (neither of which is happening).
The shareable stuff I'm interested in is smaller than a framework --- any
framework.
Craig McClanahan
Re: Riffing again on another tangent
Posted by cm...@yahoo.com.
> But Avalon was intended to be a shared repository of server-side components
> - it has no other purpose ;) All the other projects create server-side
> components as a side effect of developing another product. Avalons product
> is the components.
Which is a very generic term - like saying the goal of a project is to
create java code, or a server-side templating system.
What is specific about Avalon components ? All jakarta projects are
developing server-side software, and most of the good code is organized in
components.
And if you are saying that Avalon was supposed to do what we want for the
libary - provide "catalog" and "common development" for projects - then it
obviously failed ( since jakarta projects are still duplicating code
instead of participating in avalon ) - so there is no point in discussing
this :-)
> I don't see how having two separate projects who do the same thing could be
> good for jakarta. Could you imagine if someone proposed another servlet
> engine at jakarta - Do you think that another servlet engine that served
> roughly the same purpose would be good for Jakarta? (I don't think so)
> Would it be good for Tomcat ? (not really) Would it be good for foo servlet
> engine ? (perhaps they get associated with Apache).
Yes, that already happened and we survived. I would say ( IMHO !!) that
the net effect was quite good (!).
And Apache has 2 xml parsers, multiple template engines, multiple flavors
of regexps. Choice is good - each may be better suited for a different
environment ( like tomcat 3.x is the only solution for JDK1.1 and
catalina / 4.x for people wanting servlet 2.3 support - to give only a
"neutral" example )
> I agree - all code sits on its' own merits and these components should not
> (at least in base form) be integrated into the rest of Avalon. The
> cornerstone CVS may integrate components from the catalog/agora CVS into
> the Avalon services/kernel API but I don't see this as something the
> catalog/agora should do by itself.
I see it the other way around - avalon components should be treated equal
with components developed by other projects, and "promoted" based on
their actual use in projects and user adoption.
Merging this project with avalon would sugest that avalon components are
"special" compared with components from other project. And that would be
wrong.
> By opening another CVS and giving everybody karma/voting rights/whatever
> then I believe the community would manage itself ;) If you think it is a
> bad idea to integrate with the framework part of Avalon then don't ;) I
> would even allow components integrated with other frameworks be added (with
> the proviso that they would be refactored to use JavaBeans standard overtime).
Again - I think it's the other way around.
Avalon components could be integrated in the library, if they are not
dependent on a framework - and avalon decides to.
Costin
Re: Riffing again on another tangent
Posted by cm...@yahoo.com.
> But Avalon was intended to be a shared repository of server-side components
> - it has no other purpose ;) All the other projects create server-side
> components as a side effect of developing another product. Avalons product
> is the components.
Which is a very generic term - like saying the goal of a project is to
create java code, or a server-side templating system.
What is specific about Avalon components ? All jakarta projects are
developing server-side software, and most of the good code is organized in
components.
And if you are saying that Avalon was supposed to do what we want for the
libary - provide "catalog" and "common development" for projects - then it
obviously failed ( since jakarta projects are still duplicating code
instead of participating in avalon ) - so there is no point in discussing
this :-)
> I don't see how having two separate projects who do the same thing could be
> good for jakarta. Could you imagine if someone proposed another servlet
> engine at jakarta - Do you think that another servlet engine that served
> roughly the same purpose would be good for Jakarta? (I don't think so)
> Would it be good for Tomcat ? (not really) Would it be good for foo servlet
> engine ? (perhaps they get associated with Apache).
Yes, that already happened and we survived. I would say ( IMHO !!) that
the net effect was quite good (!).
And Apache has 2 xml parsers, multiple template engines, multiple flavors
of regexps. Choice is good - each may be better suited for a different
environment ( like tomcat 3.x is the only solution for JDK1.1 and
catalina / 4.x for people wanting servlet 2.3 support - to give only a
"neutral" example )
> I agree - all code sits on its' own merits and these components should not
> (at least in base form) be integrated into the rest of Avalon. The
> cornerstone CVS may integrate components from the catalog/agora CVS into
> the Avalon services/kernel API but I don't see this as something the
> catalog/agora should do by itself.
I see it the other way around - avalon components should be treated equal
with components developed by other projects, and "promoted" based on
their actual use in projects and user adoption.
Merging this project with avalon would sugest that avalon components are
"special" compared with components from other project. And that would be
wrong.
> By opening another CVS and giving everybody karma/voting rights/whatever
> then I believe the community would manage itself ;) If you think it is a
> bad idea to integrate with the framework part of Avalon then don't ;) I
> would even allow components integrated with other frameworks be added (with
> the proviso that they would be refactored to use JavaBeans standard overtime).
Again - I think it's the other way around.
Avalon components could be integrated in the library, if they are not
dependent on a framework - and avalon decides to.
Costin
Re: Riffing again on another tangent
Posted by cm...@yahoo.com.
Well, sorry about the previous mail, it didn't sounded as I wanted.
All I'm trying to say is that the Library is significantly bigger than
Avalon - in both scope and intended community.
It does overap with avalon, as it overlaps with jakarta-tools or
alexandria - that doesn't mean it should be merged with any of those.
Costin
Re: Riffing again on another tangent
Posted by cm...@yahoo.com.
Well, sorry about the previous mail, it didn't sounded as I wanted.
All I'm trying to say is that the Library is significantly bigger than
Avalon - in both scope and intended community.
It does overap with avalon, as it overlaps with jakarta-tools or
alexandria - that doesn't mean it should be merged with any of those.
Costin
Re: Riffing again on another tangent
Posted by Peter Donald <do...@apache.org>.
At 09:18 1/3/01 -0800, cmanolache@yahoo.com wrote:
>Arguing that this should be part of avalon because it overlaps with
>it's goal is wrong - the library will overlap with almost all
>jakarta projects. It overlaps with jakarta-tools ( which also overlaps
>with avalon ), it overlaps with alexandria. All jakarta
>projects are creating some forms of server-side compoents
>( including tomcat ).
But Avalon was intended to be a shared repository of server-side components
- it has no other purpose ;) All the other projects create server-side
components as a side effect of developing another product. Avalons product
is the components.
>BTW, the question is not what would be better for avalon, but
>what would be better for this project and jakarta.
To be honest - my order of importance is;
* whats good for jakarta
* whats good for avalon
* whats good for library
I don't see how having two separate projects who do the same thing could be
good for jakarta. Could you imagine if someone proposed another servlet
engine at jakarta - Do you think that another servlet engine that served
roughly the same purpose would be good for Jakarta? (I don't think so)
Would it be good for Tomcat ? (not really) Would it be good for foo servlet
engine ? (perhaps they get associated with Apache).
>Another big problem ( and I'm very strong about it ) is that
>by calling it avalon we'll have to deal with a way to
>position the existing avalon code - since it shouldn't be
>in any way "favorised" versus code from other projects.
I agree - all code sits on its' own merits and these components should not
(at least in base form) be integrated into the rest of Avalon. The
cornerstone CVS may integrate components from the catalog/agora CVS into
the Avalon services/kernel API but I don't see this as something the
catalog/agora should do by itself.
By opening another CVS and giving everybody karma/voting rights/whatever
then I believe the community would manage itself ;) If you think it is a
bad idea to integrate with the framework part of Avalon then don't ;) I
would even allow components integrated with other frameworks be added (with
the proviso that they would be refactored to use JavaBeans standard overtime).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Riffing again on another tangent
Posted by Peter Donald <do...@apache.org>.
At 09:18 1/3/01 -0800, cmanolache@yahoo.com wrote:
>Arguing that this should be part of avalon because it overlaps with
>it's goal is wrong - the library will overlap with almost all
>jakarta projects. It overlaps with jakarta-tools ( which also overlaps
>with avalon ), it overlaps with alexandria. All jakarta
>projects are creating some forms of server-side compoents
>( including tomcat ).
But Avalon was intended to be a shared repository of server-side components
- it has no other purpose ;) All the other projects create server-side
components as a side effect of developing another product. Avalons product
is the components.
>BTW, the question is not what would be better for avalon, but
>what would be better for this project and jakarta.
To be honest - my order of importance is;
* whats good for jakarta
* whats good for avalon
* whats good for library
I don't see how having two separate projects who do the same thing could be
good for jakarta. Could you imagine if someone proposed another servlet
engine at jakarta - Do you think that another servlet engine that served
roughly the same purpose would be good for Jakarta? (I don't think so)
Would it be good for Tomcat ? (not really) Would it be good for foo servlet
engine ? (perhaps they get associated with Apache).
>Another big problem ( and I'm very strong about it ) is that
>by calling it avalon we'll have to deal with a way to
>position the existing avalon code - since it shouldn't be
>in any way "favorised" versus code from other projects.
I agree - all code sits on its' own merits and these components should not
(at least in base form) be integrated into the rest of Avalon. The
cornerstone CVS may integrate components from the catalog/agora CVS into
the Avalon services/kernel API but I don't see this as something the
catalog/agora should do by itself.
By opening another CVS and giving everybody karma/voting rights/whatever
then I believe the community would manage itself ;) If you think it is a
bad idea to integrate with the framework part of Avalon then don't ;) I
would even allow components integrated with other frameworks be added (with
the proviso that they would be refactored to use JavaBeans standard overtime).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Riffing again on another tangent
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> Not necessarily ;) Avalon is a name with many faces. We are trying to
> separate out each of these at the moment but we are still no there. I
> posted a list of 5 things I though Avalon was on general@jakarta (under
> subject "What is Avalon?"). I was also mailed off list with two other
> things that Avalon could be interpreted as being - so I guess when you say
> "Avalon" you have to qualify it which particular component ;)
Peter Donald wrote:
> Avalon is;
> 1. A repository of general utility code
> 2. A repository of patterns and framework code
> 3. A set of general utility code based on (2)
> 4. A micro kernel for running services
> 5. A set of services that are orientated towards server environments
Peter Donald wrote:
> This would be the only sticking point I see. It is unfortunate that other
> projects are seen as "competitors" rather than "companions" but I guess
> until this is "fixed" it could be an issue. However instead of starting
> again I would prefer that we try to start fixing things now.
And in the spirit of cooperation ;-) I'd suggest that since Avalon has
so much on its plate already, why not try and offload (1) to the
Commons, and concentrate more fully on (2) through (5)+.
Peter Donald wrote:
> But Avalon was intended to be a shared repository of server-side components
> - it has no other purpose ;) All the other projects create server-side
> components as a side effect of developing another product. Avalons product
> is the components.
Even with the reorganization, I think the perception is going to be that
Avalon is a framework product that also offers up some general utility
code, the same way Struts and Turbine do.
The difference between Avalon and the Commons is that Avalon is trying
to put the pieces together, and the Commons is really offering pieces,
only pieces, and nothing but pieces. BYOP - bring your own puzzle ;-)
-T.
Re: Riffing again on another tangent
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> Not necessarily ;) Avalon is a name with many faces. We are trying to
> separate out each of these at the moment but we are still no there. I
> posted a list of 5 things I though Avalon was on general@jakarta (under
> subject "What is Avalon?"). I was also mailed off list with two other
> things that Avalon could be interpreted as being - so I guess when you say
> "Avalon" you have to qualify it which particular component ;)
Peter Donald wrote:
> Avalon is;
> 1. A repository of general utility code
> 2. A repository of patterns and framework code
> 3. A set of general utility code based on (2)
> 4. A micro kernel for running services
> 5. A set of services that are orientated towards server environments
Peter Donald wrote:
> This would be the only sticking point I see. It is unfortunate that other
> projects are seen as "competitors" rather than "companions" but I guess
> until this is "fixed" it could be an issue. However instead of starting
> again I would prefer that we try to start fixing things now.
And in the spirit of cooperation ;-) I'd suggest that since Avalon has
so much on its plate already, why not try and offload (1) to the
Commons, and concentrate more fully on (2) through (5)+.
Peter Donald wrote:
> But Avalon was intended to be a shared repository of server-side components
> - it has no other purpose ;) All the other projects create server-side
> components as a side effect of developing another product. Avalons product
> is the components.
Even with the reorganization, I think the perception is going to be that
Avalon is a framework product that also offers up some general utility
code, the same way Struts and Turbine do.
The difference between Avalon and the Commons is that Avalon is trying
to put the pieces together, and the Commons is really offering pieces,
only pieces, and nothing but pieces. BYOP - bring your own puzzle ;-)
-T.
Re: Riffing again on another tangent
Posted by cm...@yahoo.com.
> >Beeing "project-neutral" is important to create what we need.
>
> This would be the only sticking point I see. It is unfortunate that other
> projects are seen as "competitors" rather than "companions" but I guess
> until this is "fixed" it could be an issue. However instead of starting
> again I would prefer that we try to start fixing things now.
Peter,
Beeing project-neutral is very important.
We shouldn't treat the components developed in avalon in a special
way - the fact is that _all_ jakarta projects are creating server-side
components.
Arguing that this should be part of avalon because it overlaps with
it's goal is wrong - the library will overlap with almost all
jakarta projects. It overlaps with jakarta-tools ( which also overlaps
with avalon ), it overlaps with alexandria. All jakarta
projects are creating some forms of server-side compoents
( including tomcat ).
In the end, what matters is what we gain and loose by calling it Avalon.
I think we loose much more than we gain. The only thing we might
gain is avoiding confusion - but that shouldn't be the driving
argument, in any case. ( and there is alreay enough confusion
surrounding avalon ).
BTW, the question is not what would be better for avalon, but
what would be better for this project and jakarta.
Another big problem ( and I'm very strong about it ) is that
by calling it avalon we'll have to deal with a way to
position the existing avalon code - since it shouldn't be
in any way "favorised" versus code from other projects.
Costin
Re: Riffing again on another tangent
Posted by cm...@yahoo.com.
> >Beeing "project-neutral" is important to create what we need.
>
> This would be the only sticking point I see. It is unfortunate that other
> projects are seen as "competitors" rather than "companions" but I guess
> until this is "fixed" it could be an issue. However instead of starting
> again I would prefer that we try to start fixing things now.
Peter,
Beeing project-neutral is very important.
We shouldn't treat the components developed in avalon in a special
way - the fact is that _all_ jakarta projects are creating server-side
components.
Arguing that this should be part of avalon because it overlaps with
it's goal is wrong - the library will overlap with almost all
jakarta projects. It overlaps with jakarta-tools ( which also overlaps
with avalon ), it overlaps with alexandria. All jakarta
projects are creating some forms of server-side compoents
( including tomcat ).
In the end, what matters is what we gain and loose by calling it Avalon.
I think we loose much more than we gain. The only thing we might
gain is avoiding confusion - but that shouldn't be the driving
argument, in any case. ( and there is alreay enough confusion
surrounding avalon ).
BTW, the question is not what would be better for avalon, but
what would be better for this project and jakarta.
Another big problem ( and I'm very strong about it ) is that
by calling it avalon we'll have to deal with a way to
position the existing avalon code - since it shouldn't be
in any way "favorised" versus code from other projects.
Costin