On Wed, 28 Feb 2001, Craig R. McClanahan wrote:
>
>
> 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 is how I understand it as well...
> 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.
I see this as a progression: alexandria + gump are products/a product that
the project would use to provide some of the services we have proposed.
CJAN is an evolution that will occur when the process of making these
components is worked out and when the combination of products needed to
support the infrastructure are used together and crash tested ;)
>
> >
> > 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.
>
Again, I agree completely...
> >
> > 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.
>
>
>
David
PPS: Is anyone taking count of the names that have been assigned to this
project/services/subproject(s) yet?
>
