on 1/31/01 6:12 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:
> 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)
We have some overlap in functionality in Turbine, but that is ok. At some
point, I'm sure we will be working together.
Overlap:
StringUtils
Cascading Exceptions
Services (if what you mean by this is a singleton framework, then that
is what we are duplicating.)
Database Connection Pooling
Schedulers (ie: Java based cron with a RDBM's backend)
> 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).
Funny thing is that I hear the same types of things about Turbine and also
have a lot of the same responses <smile>. However, in Turbine, most of the
code overlap is NOT alpha or even beta quality code, but production level
code that *is* being used in production environments.
> 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.
Sounds good.
> 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 ;)
I agree. Keep them in one place.
> 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 ;)
I don't think that you have to have different CVS trees to accomplish this
at all. You can simply have your Ant build scripts generate the appropriate
releases.
./cornerstone.xml
./avalon.xml
./phoenix.xml
> 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)
That is fine, but I think you should call them all Avalon and make them
named releases. Otherwise, you are going to have mad (cow <smile> ?)
confusion on our already confused user base.
Avalon (Cornerstone release)
Avalon (Phoenix release)
Avalon (Final release)
This would be similar to how companies like Redhat name their distributions.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
