Peter Donald wrote: > > At 05:53 24/2/01 -0800, Federico Barbieri wrote: > >Digging into the avalon.util package you can see quite a mess... the > >reason being there is a mix of general purpose ulitity classes, avalon > >related classes and some phoenix oriented classes. > > >The same apply to camelot. > > could expand on that ?
part of camelot is what I've renamed avalon.container as it's a general purpose set of patterns for container, contained, etc. while part is much more linked to the specific kernel implementation. As example Container, Deployer are general purpose and should go into avalon.container. AvalonState not. Separation is kinda difficult... I was thinking: avalon.configuration, avalon.context, avalon.component are all decoupled one from the other. So should be avlaon.container. avalon.camelot should contain higher level classed that uses all the avove packages to be more usable. I'll upload the proposal later today. > > >I'd like to move out of the util all avalon related classes and find > >them a place in avalon.* like avalon.log avalon.thread etc. > > certainly possible - though we would end up leaving heaps of deprecated > methods around in util that may make it look a little less than clean ;) That's the idea... that's a 4.0 proposal! No back compatibility. :-) I know I'm going to be flamed but... IMHO cleaning 3.1a is wrong... it's going to need thousand of deprecation and we'll never reach a final release. Expecially if we deprecate stuff without a final 4.0! It's much better to work on 3.1a to get a beta and a final release while we'll finalize the 4.0 proposal. We'll be able to support old API (3.1) with more than an alfa/dev product and get rid of all the old trash for a clean next generation (4.0). The evolution will be more or less 3.1a-> 3.1b-> 3.1-> 3.2->4.0 that is: let's get a final release of what we've got and work on 4.0 in parallel. 3.2 includes the deprecation needed to move to 4.0. Sound reasonable? > > >Phoenix oriented stuff should go into > >phoenix of course > > which stuff do you consider Phoenix stuff. I assume that would be > DefaultLogManager, DefaultPolicy and DefaultThreadManager ???? If so I > think they are general enough to warrant being in util - not sure. nor am I... :-) i see three slightly different set of classes -low level general purpose util: Enum, util.pool, util.io -avalon design patterns: avalon.configuration, avalon.component, avalon.container etc. -avalon related /high level utility: avalon.camelot, avalon.thread, avalon.log etc. thou I don't know if it makes any sense trying to separate them... for the sake of sharing code it makes quite sense to separate the first into avalon.util while the other two can coexist in avalon.* Any ideas? > > >while the general purpose stuff can either stay or go > >into a jakarta general util package (cvs?). > > yep. > > Cheers, > > Pete > Fede
