From: Stephen McConnell [mailto:[EMAIL PROTECTED]
What I propose is a package in avalon vs named avalon-configuration
avalon/avalon-configuration api <--- contains MutableConfiguration impl <--- contains DefaultConfiguration contains DefaultMultipleConfiguration and possibly the rest of the content currently under framework/impl/.../configuration
... then we have a clear separation of the container side concerns relating to configuration as distinct from the container/component contract concerns that are dealt with under the framework space.
I oppose an avalon-configuration package. However, abstracting one level up may be required.
OK ... but relative to location this implies
avalon/xxxx
or
xxx
It seems like we have three types of things under org.apache.avalon.framework:
1. Lifecycle contracts and supporting interfaces: Such as Initializable, Configurable, Configuration, etc. Basically the interfaces and classes involved in getting a component good to go, and decomissioning.
yep
2. Default implementations of the interfaces in (1), and utility
classes:
DefaultConfiguration, DefaultConfigurationBuilder, DefaultConfiguration, DefaultContext, etc.
and so log as these remain realistic default implementations these make sense - and in the scenario of this thread we are talking about the introduction of an implementation contract which is below the api and above the implementation
3. Additional interfaces: Abstractions of default implementations such
as
MutableConfiguration. To understand what I mean by this, consider a
world
where we have java.util.ArrayList, but no java.util.List. Then
someone thinks: "Hmmm. An ArrayList is just an implementation of a List. We
should
perhaps define such an interface." That's my thought about
DefaultConfiguration/
MutableConfiguration.
I understand this completely. The question I have concerns the relevance of DefaultConfiguration to this discussion. IMO DefaultConfiguration is simply an unqualified implementation example.
What makes this such a mess is that we have (2) under org.apache.avalon.framework! (2) are basically utility classes - none of them figure in any lifecycle contract, which really makes them not part of framework. You can write a source and binary compatible container without ever using them.
Which is the reason why this needs to be resolved properly. Take for example the stuff I'm doing on the avalon-logging package .. its replacing classes in avalon-framework/impl because the impl is structured. I see direct and immediate parallels between this and the concerns relative to configuration.
And since we have implementations in framework, (3) pretty much has to
go there as well.
On this I disagree.
We can create org.apache.avalon.configuration and include withing this namespace the things that really make sense as pertains to the question of configuration implementation strategies.
What we should have done is:
1. org.apache.avalon.lifecycle
2. org.apache.avalon.util
3. org.apache.avalon.util
(Note that I don't propose the above.)
But now we're stuck with what we have - we have implementation and
supporting classes in the same java package as the interfaces. I can understand the
implementation classes but not the support classes. I mean, would you put
SAXConfigurationBuilder into
org.apache.avalon.framework.configuration today if you had a choice?
Moving classes around packages is suicide at the moment, so we're sorta stuck with what
we have.
I disagree - the APIs are contact - what we do with the impl is another question. Create fred.xyz.DefaultConfiguration - does not matter - it does not impact the framework contract spec.
So instead of having:
avalon-framework-api avalon-framework-impl avalon-framework-configuration
perhaps:
avalon-framework-api << Configurable, Configuration
avalon-framework-xapi (eXtended-API) << MutableConfiguration
avalon-framework-impl << DefaultConfiguration, DefaultConfigurationBuilder
What is the difference with the above and :
avalon-framework-api avalon-configuration-api <-- container side apis avalon-configuration-impl <-- implementations
or
avalon-configuration-xml <-- implementations
The difference is that your not saying that something is part of the component/container contract ... instead your saying ... "relative to the container/component contract there is an implementation solution".
Dependencies are: impl depends on xapi depends on api.
I understand (and agree) except for the "framework" aspect ... because its not actually framework .. its just an implementation strategy that happens to have an interface associated with it.
Stephen.
/LS
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
