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 am +1 on creating a new CJAN/gump/alexandria/infrastructure project that
sets up the infrastructure.
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.
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 |
*-----------------------------------------------------*
