> From: Peter Donald [mailto:[EMAIL PROTECTED]] > > On Sat, 23 Nov 2002 00:54, Berin Loritsch wrote: > > > From: Paul Hammant [mailto:[EMAIL PROTECTED]] > > > > > > On that note we previously voted on whether to split > > > avalon-framework.jar into two* -> > > > avalon-framework-api.jar and avalon-framework-refimpl.jar. > > > Can someone run thru the votes and see > > > if we got majority. It was a week ago I think. Can't do it > > > myself as on webmail presently. Maybe > > > it needs crisping up a little bit before enacting. > > > > I wasn't aware of that proposal/vote amid all the noise. > > > > -1 from me. There is no reason to split the framework into > > two jars. Not only is it already small, but the default > > implementations of the Configuration/Context/etc. are all > > part of the interface. I can't imagine what gains can be > > made by separating interface/implementation for the Jars. > > What about the Parameters object? There is no separate > > interface, although it is directly named in the Parameterizable > > interface. It provides no real benefit that I can see. > > The one benefit is for classes which have external dependencies (ie > Logkit/Log4j etc). Splitting the jars makes it possible for > us to keep > LogKit/Log4j out of the base Classloader but we can still > resolve them higher > up in the chain where the classloaders are present.
I can support this approach: 1) Core Avalon (no requirements for dependencies from any other jar including LogKit/Log4J) 2) Add-on Jars (adding LogKit/Log4J functionality using the external jar). But this also begs the question why have a Jar for one or two classes? If the LogKit/Log4J compliance is done at a higher level (i.e. those classes are moved into Excalibur Logger for example), then the core Avalon is dependency free and still one jar. Is that a viable solution? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
