> 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.
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.
2. Default implementations of the interfaces in (1), and utility
classes:
DefaultConfiguration, DefaultConfigurationBuilder,
DefaultConfiguration, DefaultContext, etc.
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.
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.
And since we have implementations in framework, (3) pretty much has to
go there
as well.
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.
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
Dependencies are: impl depends on xapi depends on api.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
