configuration packaging

[Stephen McConnell <mc...@apache.org>]

Leo Sutic wrote:

> 
>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>
>>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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
> 
> 


-- 

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|

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