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:

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

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

> IO

Leaves Avalon - out of scope.

> Logger


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


// ---------------------------------------------


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

 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:


        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
    make this much easier. Another approach would be to differentiate
    build dependencies and runtime/testnig dependencies. Build
    may not be circular, but if A depends on B to compile, but B depends
    A for its unit tests, then you can compile B, compile A, and *then*
    B and A. If you don't differentiate between these, you get a
    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
    Excalibur/Configuration and Excalibur/Context into the impl part?


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message