Util

[Federico Barbieri <sc...@betaversion.org>]

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. 

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. Phoenix oriented stuff should go into
phoenix of course while the general purpose stuff can either stay or go
into a jakarta general util package (cvs?).

I'll commit the proposal if it's fine with you and show more in detail
what I mean.

Fede

Re: Util

[Peter Donald <do...@apache.org>]

At 05:14  25/2/01 -0800, Federico Barbieri wrote:
>Peter Donald wrote:
>> 
>> At 03:09  25/2/01 -0800, Federico Barbieri wrote:
>> >> >I'll upload the proposal later today.
>> >>
>> >> kewl - could it be in proposal/4.0 or proposal/red or something
similar ;)
>> >
>> >done. There is a changes.txt. More work is needed thou.
>> 
>> Could you move it to proposal/4.0/src/java instead of src/proposal-4.0
>> because will eventually need to alter the remaining build process etc to
>> match the proposal (like excludes if j2ee.jar not present). This way the
>> proposal is completely decoupled from real source tree. Probably the best
>> way to do this is to just log into daedelus and move it manually on
>> filesystem.
>> 
>
>done. I'll create a proposal/build.xml as well tomorrow (it's 5.15 am
>and I'm feeling sleepy... :-).

egads ! 

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: Util

[Federico Barbieri <sc...@betaversion.org>]

Peter Donald wrote:
> 
> At 03:09  25/2/01 -0800, Federico Barbieri wrote:
> >> >I'll upload the proposal later today.
> >>
> >> kewl - could it be in proposal/4.0 or proposal/red or something similar ;)
> >
> >done. There is a changes.txt. More work is needed thou.
> 
> Could you move it to proposal/4.0/src/java instead of src/proposal-4.0
> because will eventually need to alter the remaining build process etc to
> match the proposal (like excludes if j2ee.jar not present). This way the
> proposal is completely decoupled from real source tree. Probably the best
> way to do this is to just log into daedelus and move it manually on
> filesystem.
> 

done. I'll create a proposal/build.xml as well tomorrow (it's 5.15 am
and I'm feeling sleepy... :-).

Fede

Re: Util

[Peter Donald <do...@apache.org>]

At 03:09  25/2/01 -0800, Federico Barbieri wrote:
>> >I'll upload the proposal later today.
>> 
>> kewl - could it be in proposal/4.0 or proposal/red or something similar ;)
>
>done. There is a changes.txt. More work is needed thou.

Could you move it to proposal/4.0/src/java instead of src/proposal-4.0
because will eventually need to alter the remaining build process etc to
match the proposal (like excludes if j2ee.jar not present). This way the
proposal is completely decoupled from real source tree. Probably the best
way to do this is to just log into daedelus and move it manually on
filesystem.

>Ok so let's dig out the 4.0 proposal! I'd like to have everybody's
>opinion since that is supposed to be VERY VERY stable! :-)

I won't have a lot of time at first as most of my effort is going to go
into stabilizing 3.x but after that I be good with it.

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: Util

[Federico Barbieri <sc...@betaversion.org>]

Peter Donald wrote:
> 

> >Separation is kinda difficult... I was thinking: avalon.configuration,
> >avalon.context, avalon.component are all decoupled one from the other.
> 
> I don't mind that (actually I advocated that ages ago) but I also remember
> Stefano convinced me this was bad ... though I can't remember the reason.
> It should be in the archives ;)
> 

don't know but now if you look at the package you can easily see the
different design patterns decupled in their folder... it's more
intuitive.

> >So should be avlaon.container.
> >avalon.camelot should contain higher level classed that uses all the
> >avove packages to be more usable.
> 
> perhaps - but as it stands camelot interfaces only use a small proportion
> of it but the implementations are themselves built on top of the other
> bits. I think we need more justification to split camelot at this stage.

Need to work more on that... camelot is a bad beast! :-)

> 
> >I'll upload the proposal later today.
> 
> kewl - could it be in proposal/4.0 or proposal/red or something similar ;)

done. There is a changes.txt. More work is needed thou.

> 
> >> >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.
> 
> Perhaps but I want to finish 3 to make it usable and largely stable. I am
> building stuff on top of it at the moment. Theres a few things currently
> lacking (logging/exception hanlding and management) that I want. After that
> I was just going to clean and refactor.
> 
> While working on 4.0 now is alluring I think we should at least finish 3 ;)
> (Or at least I will).
> 

Tha't exactly what I'm saying... we can't go for a 4.0 without a 3.1
final release. That whould be a very bad development choice. On the
other side we can make 4.0 clean and nice!

> Besides I have some big visions for 4.0 (or maybe 5.0) that involve a lot
> of stuff Berin was talking about. ie using MOM/JMS and LDAP/directorys to
> build distributed and replicateable (is that a word?) server farms. However
> that is definetly in the arena of "pipe dream" at the moment ;)

Keep it worm... if we set up things the right way 4.0 generation will
really kick asses! :-)

> 
> >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?
> 
> Don't need to formalize it now.

just to keep in mind and work trasparently in public... 

> 
> >i see three slightly different set of classes
> 
> Very similar to the first three levels I described avalon as on my post to
> jakarta-general ;)

not everybody reads jakarta... it must be posted here too! :-)

> 
> >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?
> 
> Sounds like my plan ;)
> 
> Cheers,
> 
> Pete
> 

Ok so let's dig out the 4.0 proposal! I'd like to have everybody's
opinion since that is supposed to be VERY VERY stable! :-)

Fede

Re: Util

[Peter Donald <do...@apache.org>]

At 06:42  24/2/01 -0800, Federico Barbieri wrote:
>> >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.

oh okay - there is Avalon related container components and the generic
container components. I was thinking of eventually sub-packaging em (ie
camelot.avalon.* but as camelot is not widely used yet I thought it was a
little premature. Also considering the recent refactoring burned away a lot
of the Avalon specific files (there is only 4 left that I can see) I am not
sure an extra package for 4 classes is worth it.

>Separation is kinda difficult... I was thinking: avalon.configuration,
>avalon.context, avalon.component are all decoupled one from the other.

I don't mind that (actually I advocated that ages ago) but I also remember
Stefano convinced me this was bad ... though I can't remember the reason.
It should be in the archives ;)

>So should be avlaon.container. 
>avalon.camelot should contain higher level classed that uses all the
>avove packages to be more usable.

perhaps - but as it stands camelot interfaces only use a small proportion
of it but the implementations are themselves built on top of the other
bits. I think we need more justification to split camelot at this stage.

>I'll upload the proposal later today. 

kewl - could it be in proposal/4.0 or proposal/red or something similar ;)

>> >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. 

Perhaps but I want to finish 3 to make it usable and largely stable. I am
building stuff on top of it at the moment. Theres a few things currently
lacking (logging/exception hanlding and management) that I want. After that
I was just going to clean and refactor. 

While working on 4.0 now is alluring I think we should at least finish 3 ;)
(Or at least I will).

Besides I have some big visions for 4.0 (or maybe 5.0) that involve a lot
of stuff Berin was talking about. ie using MOM/JMS and LDAP/directorys to
build distributed and replicateable (is that a word?) server farms. However
that is definetly in the arena of "pipe dream" at the moment ;)

>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?

Don't need to formalize it now. 

>i see three slightly different set of classes

Very similar to the first three levels I described avalon as on my post to
jakarta-general ;)

>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?

Sounds like my plan ;)


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: Util

[Federico Barbieri <sc...@betaversion.org>]

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

Re: Util

[Peter Donald <do...@apache.org>]

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 ?

>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 ;)

>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.

>while the general purpose stuff can either stay or go
>into a jakarta general util package (cvs?).

yep.


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*