avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: FW: avalon moved.
Date Sat, 24 Feb 2001 05:56:42 GMT
>>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).

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.

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

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

>>My guess is that we need a separate detailed votation but please add
>>your comments.

I sent a vote to the other list a bit back but I will bounce it to new list.

>>more to come....

kewl - keep it coming. A lot of the duplicity stuff in Avalon though is
done to support backwards compatability in some form or another.

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


Mime
View raw message