avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Avalon Project Hierarchy
Date Wed, 20 Nov 2002 19:54:04 GMT
> The Avalon project hierarchy has a concept that works, but
> the implementation that doesn't.

I think I agree with that in concept, but I don't think that there was
actually disagreement between Nicola and myself at all.

> For instance, from the thread "Single Avalon Implementation
yes/no/why/how",
> we have Noel writing:

> >   * Avalon Excalibur - a major implementation of the
> >     the Frameworks.  But not the only possible one.

> And Nicola responding:

> > * Excalibur is not a major implementation of the the Framework. It
> > contains utility stuff to create containers and some
> > containers itself.

> Which represents some conceptual friction.

Nicola's correction / clarification *is* better.  Nicola's correction is
that Excalibur isn't the implementation, but is rather a collection of
useful code used to implement containers, which (from the perspective of a
component) is the implementation of Frameworks.  And if that isn't what
Nicola meant, then I apologize and need to re-read his message.  :-)

My understanding of Nicola's approach is:

   - Avalon is a repository containing Framework and
     Avalon-specific utilities

   - There is a area for container development

   - There is an area for pluggable components

I might re-cast that as:

   - A repository containing Framework, which
     is the Avalon contract definition.  This
     is what you can count on to be present,
     or optionally present with a guaranteed
     interface, in any compliant container.

   - Containers, and container-specific
     components.

   - Portable components.

   - Container development.  Those classes
     that are provided to aid in developing
     new containers.

When I then look at your solution:

> * Avalon Framework remains as is.  We can look
>   at Avalon 5 later after the dust has settled.

Agreed.

> * 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).

> * 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 see that you and Nicola agree on this approach, but it confuses me.  Why
merge projects that seem to be at different levels within the model?  One is
a set of common classes used to implement containers, and the other is a set
of components that are intended to run inside of containers.  They appear,
to me, to be two completely different categories.

Basically, I see these categories:

   (1) contract exposed to components,
   (2) containers
   (3) components

and common, Avalon-specific, code that can be used to develop new
containers.  This seems to be conceptually in keeping with both the current
project notions and the various plans being proposed.  Am I missing
something?  I do agree with Nicola that using descriptive names in these
discussions is best, regardless of what brand names may be applied to the
projects, so maybe I am responding to a naming change, but I don't think
that's it.

By the way, speaking of naming changes, whatever changes occur, don't forget
that those of us with projects already built on these technologies have both
dependencies and inertia.  Avalon is a platform.  Because you have outside
client code, you can't dance as nimbly as you might want.  Packaging for
outside consumption is an issue.

	--- Noel


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message