Re: [Excalibur] Release Path

[Stephen McConnell]

Leo Sutic wrote:

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.

Two classes - used in a lot of places - don't see a problem leaving
it where it is.  It could also go to commons.

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

Agree in principal - last time I looked there was a lot of additional documentation needed (instrumentation suite in general).

instrument-manager and -> Merge into one project(?) and keep in excalibur
instrument-client

I disagree with the merge suggestion. Instrument manager needs to be structurally seperated from the transport. This has been done at the level of the code but not at the level of the build (the build still depends on AltRMI). Instrument client seems to be transport specific - for example you will find AltRMI references in things like the menubar implementation. My guess is that the client could be made transport indepndent - but I'm confident that the current implementation does not pass that test.

Personally I think instrumentation should move to sandbox until its ready for a release.

IO

Leaves Avalon - out of scope.

Agree.

Logger

Stays.

Monitor

No opinion.

Me neither.

Naming

Leaves Avalon - out of scope.

There is something going on with a JNDI at Tomcat - a spinoff of a facility to do similar things. I need to do more checking.

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.

+1

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

This is all a result of the fact that out current Excalbur build does not distingish between structural versus tool dependencies. The bulk of these recursive depndecies exist only because Excalibur Testcase is includes as a structural dependency. Personally I would like to see a migration away from Excalibur Testcase in favour of pure JUnit testing. On a side note - the approach to this in Maven is good - the resources you need for applying actions in a build are based on plugins that have their own dependencies which are independent of the dependencies of the target of the build. This means for example that I can use Merlin to test a component that may be part of the actual Merlin system without getting into a dependency issue.

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 think we couold do a lot of cleaning up - but I also think this needs to be done after we address the Meven/Centerpede question.

3. Consolidation
Now that we are breaking up framework into interface/impl, could we move Excalibur/Configuration and Excalibur/Context into the impl part?

Excalibur Configuration +1
Excalibur Context  - not sure what your referring to.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




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