Leo Sutic wrote:
From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
Currently, Cocoon requires the following Excalibur packages:
CLI
Leaves Avalon - out of scope.
We should be able to do this--Commons CLI has all the same
functionality.
Collections
Leaves Avalon - out of scope.
Already done--we have a graveyard deprecated sub project still
in CVS
Concurrent
Leaves Avalon - out of scope.
Same here
i18n
No opinion.
What about merging this with Commons Resource?
IO
Leaves Avalon - out of scope.
Commons IO has all this functionality and more.
Monitor
No opinion.
Naming
Leaves Avalon - out of scope.
Going where? There is no clear commons package where
this would go. Any opinions?
AltRMI
AltRMI Registry
AltRMI Server (IMpl/Interfaces)
Leaves Avalon - out of scope.
Essentially done. It is in Incubator right now.
Component (AKA ECM)
Deprecate.
Not yet though. We need to get Fortress out
there first, and provide the proper migration
for ECM based users.
// ---------------------------------------------
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.
I agree.
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".
Cache was started, but never fully finished. There is already a
Commons cache. Things like that need to be looked at and decided
whether we are going to simply drop it or merge it in with something
else that is currently supported.
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 ...
We do need to consider the layering approach. It is a common diagram
for many API developers. It will make our lives alot easier to
graphically show how the different projects interrelate in layers. It
is very clean, and easy to explain.
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?
I started out with a separate replacement for Pool, which got merged
into Event. I prefer having Event not depend on Threadpool at all
because the code has some bugs. I prefer to use the better tested
Doug Lea utils.
3. Consolidation
Now that we are breaking up framework into interface/impl, could we
move
Excalibur/Configuration and Excalibur/Context into the impl part?
:)
Yes. I do believe that the breakup is going to be post 4.1.4 release
due to what it will take in CVS restructuring (to do it cleanly).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
