The Avalon project hierarchy has a concept that works, but
the implementation that doesn't. For instance, from the
thread "Single Avalon Implementation yes/no/why/how", we
have Noel writing:
> > Please be specific about what you mean? As I see it, the
> current division
> > of Avalon technologies makes sense to me:
> >
> > * Avalon Frameworks - these are the basic contracts that
> > authors can expect to be guaranteed in all platforms,
> > plus some simple utilities.
> >
> > * Avalon Excalibur - a major implementation of the
> > the Frameworks. But not the only possible one.
> >
> > * Avalon Containers - container implementations.
> > Guaranteed to support Avalon Frameworks, and
> > typically written using Excalibur classes.
> >
> > * Avalon Cornerstone - common pluggable services.
> > Best case says that they should run in any
> > proper container.
> >
> > * Avalon Applications - a repository for "demo"
> > applications that don't have their own place.
And Nicola responding:
> Basically it makes sense.
> There are some issues though:
>
> * Excalibur is not a major implementation of the the Framework. It
> contains utility stuff to create containers and some
> containers itself.
>
> * Avalon Containers is not there, and containers have been growing in
> Excalibur.
>
> * Avalon Cornerstone has components that cannot yet run in all
> containers. We should ensure that it can happen or that it's properly
> labeled where really impossible to make it cross-container.
Which represents some conceptual friction.
Nicola's solution includes:
> 1) Avalon becomes a single repository with framework and
> utilities. All
> utilities that are not Avalon-specific move to J-Commons- or Commons.
> This has already been started.
>
> 2) There is a place where to breed containers. Can be Avalon
> scratchpad
> or container scratchpad.
>
> 3) there is a place to keep containers. In my proposal it's in a
> ./containers subdir of the Avalon CVS. If the container becomes big
> enough, like Phoenix, it becomes an Avalon subproject in its
> own right.
>
> 4) Avalon Cornerstone and Avalon Applications are placed in a
> repository
> where multiple parties can collaborate. So it can be Apache Avalon
> Commons ot Apache Commons Avalon, but the concept remains.
As of right now, everyone seems to be in agreement that Framework is
at the core. It is by itself. Where the differences in ideas/oppinions
come is where components and containers go. For that reason, I would
like to propose the following solution.
* Avalon Framework remains as is. We can look at Avalon 5 later after
the dust has settled.
* Avalon Excalibur gets repurposed to strictly a location for Components.
All support code gets moved to commons (unless the move is already
done with Jakarta commons like in the case of Collections or replaced
by a more robust library like Concurrent).
- The TestCase and Instrument projects need to be handled as they are
specific to Avalon.
- It can probably be argued that Instrument might make an excellent
candidate for Avalon Commons. It is some top notch code.
- We may want to make the core Instrument library part of Avalon
framework (discussion must occur first).
* Avalon Scratchpad is a location for maturing subprojects to grow.
* As containers become mature, they move out of Avalon scratchpad and
become a top level sub-project. I.e. Avalon Fortress and Avalon Merlin
at the same level as Avalon Phoenix when they are released.
* All components in Avalon Cornerstone get merged into Excalibur. This
means we have to come up with some standard Context name/value pairs
that always exist--as this is the only reason why most cornerstone
components require Phoenix.
* I am not sure what to do with Avalon Apps. We need to look at the
possibility of moving them out of Avalon's sphere of responsibility.
I would have a hard time justifying their existence in an Avalon charter.
But we may also want to follow the same rules as containers for the
applications.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
