avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Excalibur] Release Path
Date Thu, 20 Feb 2003 18:50:44 GMT


> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> 
> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message