Peter Donald wrote:
>
> At 12:29 28/2/01 -0800, Morgan Delagrange wrote:
> >Note that Avalon is a _framework_ for servers, which
>
> Not necessarily ;) Avalon is a name with many faces. We are trying to
> separate out each of these at the moment but we are still no there. I
> posted a list of 5 things I though Avalon was on general@jakarta (under
> subject "What is Avalon?").
To wit:
< http://www.mail-archive.com/[email protected]/msg00022.html >
Avalon is;
1. A repository of general utility code (CLI parsing, cascading
exceptions,
StringUtils, etc)
2. A repository of patterns and framework code (ie component lifecycle
code
and mamanagement code - think logging, configuring Startable, Stoppable
Suspendable, Reesumable)
3. A set of general utility code based on (2) that offers "doing" code
and
extended patterns. (ie object pooling, thread management, classloader
management, policy management, utility classes that "run" components
lifecycle, Container-Component patterns and implementations,
Kernel-Application-Component patterns and implementation).
4. A micro kernel for running services
5. A set of services that are orientated towards server environments (ie
SocketFactories, ConnectionManagers, Schedulers etc)
After hearing this they look at it and goes - is good but is alpha -
call
me when it's beta ;) It is then I explain that (2) can be considered
largely stable and fixed, (1) and (3) usually are added to and would be
considered beta-stable. The only components that are alpha would be part
of
(3), (4) and (5).
And even within in that there are distinctions. ie The client interface
to
the kernel in (4) is stable but the actuall kernel implementation is
not.
(Consider this the same as difference between servlet and servlet
engines).
So recently we voted and decided that we want to release the different
components on different schedules. We have three basic components
avalon (1)->(3) (Thou eventually (1) should move to it's own project ala
AUT)
phoenix (4)
cornerstone (5)
That can stand on their own and have varying release schedules and
degrees
of stability. Initially you may look at it and say that cornerstone is
not
separate enough from phoenix to be worthy of a different release
schedule
and there is not enough content in it. I initially tended to agree but
there is indications that soon (post valentines day) there will be a
surge
in the number of core services offered and there will be enough for it
to
have a separate release schedule.
At this point it may seem like it would be a good idea to ask the PMC to
split the project into multiple sub-projects. However I would tend to
disagree. The same people are developers for all three sections and it
would be dividing too many resources. Maybe in the future it may be
advisable to do this but it is not the future yet ;)
So we would like to split the CVS into three separate
subprojects/subCVSes
(jakarta-cornerstone, jakarta-avalon and jakarta-phoenix). This would
allow
us to safely have different release schedules and would give a sense of
stability to those who just want to use the jakarta-avalon component. It
would also force us to stabilize faster as we wouldn't be able to as
easily
intermingle changes ;)
So in summary what we would like to do is have three deliverables within
the same project. Namely;
jakarta-avalon (Beta->STABLE)
jakarta-phoenix (Alpha->Beta)
jakarta-cornerstone (Alpha)
Thoughts?
Cheers,
Pete
