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