Berin's "[Excalibur] Release Path" summary triggered an idea in me.
Basically, the problem is that we have dependencies all over the place,
some of them circular (as Leo Simons discovered a couple of days ago).
A solution is to split Excalibur and Avalon into layers, where a layer
may only depend on the layers below it. The basic idea I intend to
go along is to first split what we have into a bunch of big layers,
and then further split those into sub-layers as needed, with the
goal of having as few layers as possible while still allowing
for the dependencies that are practical.
I'd just like to share a first attempt at constructing that structure.
First, by dependency I mean compile-time dependency. Not testing or
runtime dependency, although it would be nice to split between
{build, runtime} and {test}.
Legend:
MAJOR LAYERS
Minor Layers
In order from top to bottom:
COMPONENTS
Oh well, let's see if we can move any of these to the lower layers.
See the "DE-AVALONIZATION" part below.
In no particular order:
Excalibur/
baxter
cache
component
configuration
container
converter
datasource
event
extension
loader
logger
monitor
policy
sourceresolve
store
template-product
testcase
thread
threadcontext
tools
util
xfc
xmlutil
instrument-client
instrument-manager
CONTAINERS
Phoenix, Merlin, Fortress, etc. Placing the containers above
framework
and below components give them the proper scope.
FRAMEWORK LAYER
This is where the Avalon architecture starts.
Avalon/Framework/Meta/Impl
Implementation of Meta.
Avalon/Framework/Impl
Default implementations of Avalon/Framework
Avalon/Framework/Meta
This is the place for common metainfo and metadata specs and
similar projects. They should have framework scope, but yet not
be part of framework.
Avalon/Framework
Framework interfaces only.
Excalibur/instrument gets merged into Framework conceptually,
and in practice kicked into sandbox.
UTILITIES
These are things that would look nice in java.util or in some
other java.* package. For example:
Excalibur/
altrmi
cli
i18n
io
jprocess
naming
pool
That is, they wouldn't look out of place in the Java2 platform.
They are *not* Avalon components and have no dependency on
Framework. (Yes, I have included AltRMI, more on this below.)
Any project in UTILITIES is a candidate for Jakarta Commons.
-----------------------------------------------------------
DE-AVALONIZATION
I did put AltRMI into the UTILITIES layer, even though it has
dependencies on Phoenix. What I was thinking about was a split
into Avalon and non-Avalon code. That is, AltRMI should be a
replacement for RMI in every aspect, but still be deployable
as a block in Phoenix (the Publisher, for example).
I was thinking the same about the Excalibur/Monitor package:
Would it be possible to split it into a non-Avalon part that
can go into UTILITIES, and a component wrapper that goes into
COMPONENTS?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
