Hi,
"What is Avalon?" is a question I often hear - quickly followed up with
"Why should I use it?". To the first question I usually answer
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 loggign, 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
*-----------------------------------------------------*
| "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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
