avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Status of framework beta release?
Date Thu, 19 Apr 2001 23:48:40 GMT
At 11:01  19/4/01 -0400, Berin Loritsch wrote:
>> * create new CVS for excalibur
>
>-1.  By separating the utilities and excalibur into another CVS we are
raising
>the cost of using Avalon.  As it is, we need to include two jars (LogKit and
>AvalonAPI), and adding another one for very little benefit seems like
overkill.

One of the reasons Avalon is not used widely is because of it's monolithic
nature. Including 3 jars rather than 2 is not a hardship - I would actually
say it is easier.

>Having the excalibur components in Avalon Framework's CVS provides
examples of
>the framework in action.  I don't mind them being in another Java package,
>but I am very hesitant to separate them in different CVS directories at this
>time.
>
>When JSR-111 is finished, and we decide to use those interfaces
(javax.service.**),
>we can revisit the subject.  Of course, at that time, Avalon framework would
>be encapsulated in the services framework (hypothetically speaking of
course).
>
>> * finalize *activity* related methods (init/start/resume/etc)
>
>Ok.  Where are we with that?

I am not happy and are experimenting with things ... get back to you in a
bit ;)

>> * move processor methods to excalibur
>
>The processor methods is new terminology to me.  What are you referring to?

Stage/Processor/Pipeline interface/classes

>> * migrate code in avalon.util to better resting place (either as components
>> in phoenix or into the void)
>
>Don't get rid of _all_ the utility code!  Lock, and potentially Semaphore and
>other thread managing classes need to be part of the core API.  

It is already in excalibur (excalibur.concurrent.Lock). A lot of the code
is underused and thus really should not be kept in main tree (maybe in
whiteboard tree though).

>CLI, DataSources, Component Management Framework, Thread Management classes,
>and Pool classes really should be in avalonapi!  The IO utilities like the
>FileFilters also should be in the core API.

well I guess I differ in opinion ... enough to veto a beta release ;)

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


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message