> 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
