Peter Donald wrote:
>
> 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.
It's not so much the number of jars, its how much we are changing--and how
much cost is involved in maintaining 3 different archives, the associated
documentation, etc. You have to look in three different locations for
Javadocs.
There is alot more than adding 20 different jars if it is required.
> >> * 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 ;)
When are you happy with things? ;-)
> >> * move processor methods to excalibur
> >
> >The processor methods is new terminology to me. What are you referring to?
>
> Stage/Processor/Pipeline interface/classes
OK. they are pretty much narrow in their scope anyway.
> >> * 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).
Ok, but if there is something I need and it is no longer there, expect me
to complain loudly. Really, you can't assume anything about who is using
the framework and in which way.
> >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 ;)
Oh, please. All beta means is that the api is stable--the code can be
in varying stages of usability, but the API is stable. Avalon NEEDS this
SOON. If we keep rearranging things all the time we are going to piss
alot of people off. I want beta because I want stability. A snowflake
has a better chance in hell than me convincing my management to base
any of our software on this project because things are moving around
so much.
If people only want to use the framework then they can. If they want
to use the utility code, then it is there to make life easier for
them. Let's not hold beta hostage until we all come around to your
oppinion.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
