At 07:41 31/1/01 -0800, Jon Stevens wrote:
>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
Actually I think there is credits of a Turbine developer in our StringUtils
(I snagged it as a commit went by ;-])
> Cascading Exceptions
> Services (if what you mean by this is a singleton framework, then that
> is what we are duplicating.)
Similar thou not 100% the same. Turbine more follows the JNDI/J2EE
application level model. (ie grab the service from a central
application-wide directory). Avalon is more focused on per component level.
(ie components are mapped from global area to a local per component area
which the component accesses). But other than that they are very similar ;)
> Database Connection Pooling
> Schedulers (ie: Java based cron with a RDBM's backend)
Theres possibly even more overlap than you think ;) We have
Initializable/Disposable interface which IIRC are similar to Turbines
interfaces. We also have the next-evolutions of many of original jserv
interfaces/classes (Configuration etc). There is also similarities between
many of the ideas except Avalon is a lil more general (ie we use Context a
generalisation of RunData etc).
There is other remarkable simularities and if you were to read the Avalon
archives for last few weeks I have been advocating changes that would
enable a TurbineKernel and TurbineApplication objects (so you could load
independent apps into one turbine instance safely). So you could say I
think in a turbine-esqu way ;)
>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.
yer thats where the problem is. The only production level stuff is either
solely based on the "framework" part or using ancient versions of the kernel.
>> 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
yep thats an alternative. It was just that Sam complained about this a
while back with respect to tinderbox and nesting of projects.
It could also cause more issues because we could have cornerstone relying
on version 3.1.1 of avalon, 3.2a of phoenix and actually being 3.2beta
itself. The only way we could fix this is to store versioned jars in CVS
(no biggue for me) and put in gratutous documentation stating that you can
not copy /avalon/dist/lib/avalonapi.jar to /phoenix/lib/avalonapi.jar and
expect it to work as they are on completely different release schedules.
This could add a fair bit of confusion during building and attracting more
developers.
>> 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.
That would be fine if they were different versions of the one product.
However they are different products that just happen to be part of the same
project ;) each having different release schedules. I guess it would be
similar to some think like
jakarta-avalon (or perhaps jakarta-framework) == c std library
jakarta-phoenix == linux kernel
jakarta-cornerstone == linux kernel modules
Cheers,
Pete
*------------------------------------------------------*
| "Computers are useless. They can only give you |
| answers." - Pablo Picasso |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
