Re: Avalon Project Hierarchy

[Nicola Ken Barozzi]

Noel J. Bergman wrote:

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.

From a conceptual view, we seem to agree, yes.

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

In fact Excalibur -now- is such a module, and it contains also some container too (it's basically a big bag ;-).

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

Yes

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.

Yes

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.

Yes.

IIUC Berin wasn't thinking of merging them, but simply making Excalibur a place for a set of components that are intended to run inside of containers.

Thus my request to change the name to avalon-components.

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?

IMHO no, this is a correct summary.

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.

It's a radical change for Excalibur; well, effectively we are killing it, as well as Cornerstone.

Now:
Cornerstone keeps some Components.

After:
"avalon-components" will keep them, and we should make them as cross-container as possible

Now:
Excalibur keeps generic utility classes, Avalon utility classes, components, containers and scratchpad stuff. Seems strange, but it is.

After:
- generic utility classes -> Jakarta or Apache Commons
- Avalon utility classes -> not sure, but they are components or
go in framework as utilities
- containers -> toplevel Avalon subprojects
- scratchpad stuff -> avalon-scratchpad

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.

I don't want to see java package name changes just for this.
If an excalibur project will go for example to avalon-components, or a cornerstone one, it can/should retain his package name.

It's just a matter of being clear about the Avalon projects. Package names are not necessarily to follow suit.

--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>