At 09:18 1/3/01 -0800, [EMAIL PROTECTED] 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 |
*-----------------------------------------------------*
