Peter Donald wrote:
> At 11:47 28/2/01 -0500, Geir Magnusson Jr. wrote:
> >Peter Donald wrote:
> >
> >> Changing a projects charter from server-side component repository to
> >> component model so that another project can become a server-side component
> >> repository is not something that I think I would like to do ;)
> >
> >One of the ideas that seems to be getting lost is the model of a
> >component repository that is different from Avalon. Where Avalon is a
> >single project entity that has multiple components, the other model is a
> >place that holds/hosts multiple projects, each of a single component (or
> >so). Basically the jakarta 'group of individual projects' model on a
> >smaller length scale.
> >
> >I assume that Sam is going to ask again (correctly) about why this
> >matters - if in the end the result is a set of components, why is the
> >difference important.
> >
> >What I think makes it different is related to focus and packaging.
> >
> >n the new model (!Avalon), I believe the separation of projects would
> >force each component to be adequately packaged and documented, since
> >each is a separate entity with possibly different committers, different
> >users, and a different charter. In contrast, I believe the Avalon model
> >gloms all the components into a single jar and they aren't individually
> >documented. (This is also the case for frameworks like Struts and
> >Turbine.)
>
> Excellent - you just supported/confirmed my point ;)
>
> The only difference is the process/form rather than products/content. ;)
>
> I propose that once the infrastructure is in place then all projects will
> hopefully use it including Avalon. At which point there will be no
> difference between Avalon and librarys charter.
>
I haven't followed every message of every day on Avalon's mailing lists, and it
has been a couple months since I dived in last time (you guys talk a *lot* :-),
but the overriding image I always got of the vision for Avalon was:
* A framework for building servers, and
* A set of services preconfigured to this framework's APIs
This sounds somewhat like what you describe below, although I will quibble a bit
as you will see.
>
> I am +1 on creating a new CJAN/gump/alexandria/infrastructure project that
> sets up the infrastructure.
>
Likewise +1.
>
> However no one has shown that there will be any difference between Avalon
> and library once the infrastructure is in place. The only difference is
> that it is perceived that Avalon is only interested in "frameworkized"
> components which is not true. If you look there are a number of cases where
> we have structured it so that components could be used outside of Avalons
> framework. ie you will see a lot of AbstractFoo/DefaultFoo where
> AbstractFoo is Avalon-framework independent and DefaultFoo is bound to
> Avalons framework (via configuration methods usually). I much prefer to fix
> "fix" avalon than to create a new project to replace Avalon.
>
If AbstractFoo means that the class is abstract in the Java sense (i.e. you have
to subclass it and implement some methods to make it useful), then you are not
seeing the value of the framework-independent shared library components as highly
as I am. Make it ConcreteFoo/DefaultFoo and I would be much happier :-)
Just as an example, let's consider our favorite whipping boy -- database
connection pools. It makes a lot of sense to have a "pure JavaBeans" version of
a connection pool that does all the grunt work, but has no notion of lifecycle or
configuration -- it's up to the user to create the thing, initialize its
properties, and so on.
It also makes perfect sense for Avalon to include a service/wrapper/whatever that
initializes a connection pool at the right time in a server startup, using the
Avalon approach to configuration and component lifecycles. Such a service class
would rightfully be packaged with the Avalon framework, and declare a dependency
on the shared component. Likewise, it makes sense for Struts to do the same
thing -- include Struts-specific code (in Struts, not in the library) to
initialize the connection pool at the right time, based on Struts notions about
configuration file formats and such. And so on and so on.
Trying to have Avalon play both roles (framework and component library) would
seem to cause confusion, or the perception of "most favored nation" status in
cases where conflicting goals between the using frameworks would argue for
different APIs to the shared components.
>
> Cheers,
>
> Pete
>
Craig
PS: On names, BTW, I'm personally +1 for "jakarta-share" since that is what we
are trying to do :-). I'm +0 on any of the other names as well.
