Peter Donald wrote: > > >>the build build just one big jar including util with all the rest. I'd > >>like to have two jars, one for org.apache.avalon.util and one for the > >>patterns. > > sounds good to me. > > >>This can't be done now becouse there is a loop dependency... > > Theres a few of them actually ;) > > >>My proposal is to move Pipeline, DefaultPipeline, ProcessorPipeline, > >>ProcessorStage and Stage to the util.processor package. > > I don't mind that. > > >>org.apache.avalon.util.log: AvalonLogFormatter and DefaultLogManager > >>should go (IMO) with Loggable and Abstract Loggable in the avalon.log > >>package. > > I don't really mind but others have noted they didn't like the Loggable in > org.apache.log.* because it is part of Avalon lifecycle. If we moved > AbstractLoggable into log it also could not implement Component which a few > people asked for (convenience of programming I believe was their reason).
It's part of avalon lifecycle since avalon uses logkit... it's not part of the integration framework itself unless logkit is. About AbstractLoggable I just think component is a separate concern and being an empty interface is not such pain to write "implement component"! > > AvalonLogFormatter relies on StringUtil so until aut or the library > projects gets of the group then it depends and thus should stay with > Avalon. DefaultLogManager relies on Configuration and thus should be within > the Avalon framework. > > >>util.lang.ThreadManager is part of util.thread. Either it goes there or > >>util.thread goes into util lang. There is no reason for package > >>separation. > > legacy. lang was the old place but quite a few users of Avalon utilize it. > It is deprecated and will prolly be removed after next release. > ok > >>util.test, util.cli.test etc.: shouldn't those be in the testlet > >>package? Or if it's specific to test the kernel into phoenix? > > they aren't testing framework but test cases. ie in each of those packages > is the unit tests for superioir package. > > >>avalon.service.Service: just a thought... shouldn't it be in > >>apache.avalon? > > It *should* be in the kernel as it is part of kernel contract. I just moved > it there. > good > >>avalon.configuration: I like a separate package for conf related classes > >>but first we need to finalize the specs. Lot of discussion have took > >>place... my feeling is that we reach the "I like it" vs "I don't like > >>it" point where more talk is just a waste of time... > > It's never been a "like" thing for me for if it was I would probably still > be voting for JDOM ;) For me it is a necessity. The fact that the only > place I haven't forked configuration to make it useable is in the Avalon > CVS should be indicative of that ;) > let's say "opinion". I don't like semi-structured confs, you do. We explored all issues related with both cases and I don't have any more hope to convince you that you to change my mind. :-) So let's solve this once for all and just go on! > > kewl - keep it coming. A lot of the duplicity stuff in Avalon though is > done to support backwards compatability in some form or another. > I know and that's the main pain! I don't want to repackage and rearchitect everything nicely and screw all code. But deprecation in this situation is such a pain! So we could go for a 4.0 proposal while tuning the 3.1x branch. votes? > Cheers, > > Pete > Fede
