Re: Avalon Project Hierarchy

[Leif Mortenson]

- It can probably be argued that Instrument might make an

excellent

candidate for Avalon Commons. It is some top notch code.

What is Avalon Commons in your view?

Umm, I meant Apache Commons.  I.e. Instrument gets a more broad
audience than just Avalon.  I don't want to loose Leif, though ;).

instrument is basically dependency free. There is the exception of the
AbstractLogEnabledInstrumentable class. The other two packages contain
dependencies. But could be reworked a bit to live over there. How would
that work? Would I need to change the dependencies to use commons
jars. Or make use of released versions of the Avalon jars?

Instrument-Manager just uses framework, instrument and altrmi.

Instrument-Client is stand alone, so its dependencies are not so critical. What
it uses can be reworked without affecting existing users.

But overall, I like Avalon. :-) And would still stay. Trying to keep up over on commons
in addition would also end up taking more more of my time. So if it makes sense,
leaving them here would be nice :-)

- We may want to make the core Instrument library part of Avalon
framework (discussion must occur first).

+1

Let's see the feelings on the list. before we go too far in this
direction.  If we move Instrument to Apache Commons, then we would
have a dependency of Framework on Instrument, or an understanding
that Instrument is a supported option for components.  The nice
thing about Instrument is that if a component uses Instrument but
the container does not support it, then the component is not broken.

I had thought about moving instrument into framework before. I view the core classes
as being on the same level as the logging classes. Kind of a set of base utility classes.
Like logging, the actual implementation is separated out and exists right now in the
instrument-manager classes. A different implementation could be written at any time
and all of the components using the instrument classes would still work with the new
manager implementation.

I think it would be simpler for users to add instrument to framework than to add a
dependency to framework on instrument. The drawback is that instrument would lose
the ability to be used outside of avalon. I doubt that is an issue with any users right now
however as the instrument-manager requires avalon classes.

Note that components always require the core instrument classes to be present. They
will work whether or not they are registered with an instrument-manager however.
This was done to ease the implementation into a world with lots of existing containers.
Of course I think that any good container should have the goal of supporting
instrumentation :-)

Cheers,
Leif


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