Peter Donald wrote:
>
> At 10:14 19/4/01 -0400, Berin Loritsch wrote:
> >Cocoon is very near complete and ready for a Beta release on May 1--provided
> >nothing glaring comes up. The only thing holding us back is the lack of an
> >official beta release for Avalon.
> >
> >As far as I can tell, the class restructuring is almost complete for Avalon.
> >Do we have a list of things that need to be done for Avalon's release? It
> >would help focus and get the thing done.
>
> * 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.
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?
> * move processor methods to excalibur
The processor methods is new terminology to me. What are you referring to?
> * write a python/perl/other script to convert (i am currently using elisp
> which is not useful to everyone else)
Cool beans.
> * move camelot/atlantis to phoenix CVS
+1
> * remove compat hierarchy
Are you talking about the old places for the interfaces that are now deprecated?
If so, +1. If not, then I need more info.
> * 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. If the utility
code is only working in Pheonix, or not likely to be used outside of the Avalon
project itself, then we can move it.
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.
I think we might be trying to do too much in the push for beta. It only serves
to slow down adoption of Avalon.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
