> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> Currently, Cocoon requires the following Excalibur packages:
>
> CLI
Leaves Avalon - out of scope.
> Collections
Leaves Avalon - out of scope.
> Concurrent
Leaves Avalon - out of scope.
> i18n
No opinion.
> instrument
> instrument-manager
> instrument-manager-interfaces
I'm continuously confounded by this project. Architecturally it is at
Framework-level (maybe a step above), and not at all an independent
component. My random though is this:
instrument -> framework
instrument-manager
and -> Merge into one project(?) and keep in excalibur
instrument-client
> IO
Leaves Avalon - out of scope.
> Logger
Stays.
> Monitor
No opinion.
> Naming
Leaves Avalon - out of scope.
> AltRMI
Leaves Avalon - out of scope.
> AltRMI Registry
Leaves Avalon - out of scope.
> AltRMI Server (IMpl/Interfaces)
Leaves Avalon - out of scope.
> Component (AKA ECM)
Deprecate.
// ---------------------------------------------
BRIEF COMMENTS ON EXCALIBUR
Generally, when looking at Excalibur, we have a ton
of really good stuff - naming, pool, etc. that should
be in java.util, if I had my way. But while the projects
are extremely useful, they aren't really components
in the Avalon sense.
I would very much like to see three things happening with
Excalibur:
1. Moving away many things into Commons. Basically,
any project that is more like a bean or that has
no Avalon dependencies (naming, io, i18n),
can go to Commons and be of much more use.
2. A reduction of dependencies.
We saw a circular dependency brought up by Leo Simons
a couple of days ago. I think some of the code we have
can be de-Avalonized and rewritten as beans (Monitor, Cache,
for example. And why is AltRMI dependent on cornerstone and
can AltRMI be split into a non-Phoenix part and a Phoenix part?)
I think we went over this a while ago, having realized that
there is such a thing as "over-Avalonization".
As for the dependencies, quoting Leo Simons:
http://marc.theaimsgroup.com/?l=avalon-dev&m=104566027617644&w=2
altrmi depends on cornerstone, which depends on datasource,
which depends on testcase and component, which depend on
instrument-manager, which has an optional dependency on altrmi.
Which is not good. I wonder if we could layer the
projects in some way so that projects may only depend on
projects below them in the layering. The de-avalonization would
reduce
make this much easier. Another approach would be to differentiate
between
build dependencies and runtime/testnig dependencies. Build
dependencies
may not be circular, but if A depends on B to compile, but B depends
on
A for its unit tests, then you can compile B, compile A, and *then*
test
B and A. If you don't differentiate between these, you get a
circular
dependency: A -> B -> A ...
Another thought: Can we clean things up maybe? I noticed that Event
has its own pool code - to avoid being dependent on pool, I guess.
But can it instead depend on a de-avalonized excalibur-threadpool?
3. Consolidation
Now that we are breaking up framework into interface/impl, could we
move
Excalibur/Configuration and Excalibur/Context into the impl part?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
