Leo Sutic wrote:
Jason,
a very good argument against moving it to framework level.
It would seem that we can only move it to framework level if
Instrument is a correct formalization of instrumentation - which it isn't, if I understand your argument.
I see these solutions for the instrument interfaces:
1. Don't move them into framework.
2. Move them into framework, but *always* provide them in a separate jar. (avalon-framework-ext-instrument.jar or somesuch.)
3. Move them into some org.apache.avalon.framework.ext.instrument package, always bundle in separate jar.
For now, I'm +1 on 2 or 3. Having the instrument package at a framework level makes sense, dependency-wise, although not
from a formal POV, as you say.
Hi Leo:
I think there is a mix-up in the above between "packaging" and "technology". From a technology point of view the instrument package can be considered as an optional extension to a component lifecycle. However, the framework is not and should not be dependent on the notion of instrumentation. Much closer to the framework technical abstraction are the meta and lifecycle-extension concerns. These packages both address the means through which we facilities such as instrumentation (or other functional extensions) can be introduced into the framework without disruption.
The packaging point of view concerns the separation of things in Avalon that are "core" (referred to in this thread as framework-level), "facilities" (a lot of the stuff in Excalibur), "components" (stuff in Cornerstone and to some degree in Avalon Apps) and "extensions" (something largely not considered to-date). I personally think of the "core" or "framework" level as two distinct groups - (a) the client contract (largely what we have today in framework.jar) together with lifecycle extensions and meta info, and (b) the containment facilities. I see something like instrumentation as an "extension" as it provides the classic client contract interface and the container side management aspects.
Cheers, Steve.
Does any of the above make sense?
/LS
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
