commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Synergies between Avalon and Commons projects (was: Re: Breaking Excalibur into smaller swords)
Date Wed, 26 Dec 2001 15:29:54 GMT
On 12/26/01 8:42 AM, "Berin Loritsch" <> wrote:

>> James Strachan recently committed werken.opt to the Commons sandbox,
>> illustrating that if Avalon doesn't take the initiative by moving stuff
>> to Commons, code will materialize from somewhere else. Take a look at:
>> cache, configuration, lifecycle, pipeline, pool... it's like a second
>> Excalibur, only without the IoC emphasis.
> Ok, that I do *not* understand.  We already have a framework project, and
> that's Avalon.  If the authors want to work on a framework work on this
> one.

Who is we? After the Jserv project both Avalon and Turbine were started and
continued down their own paths. Do we not have a right to pursue what we
think a framework should be? I have some thoughts and designs that I would
like to try that might not necessarily fit in with Avalon. I am not going to
stop and try and make everything work with Avalon right off the bat.

And Avalon did not start as a general framework, it started as a server
framework and has slowly started changing it's charter over time to subsume
more and more just as Turbine has. At the moment I want to work on Turbine
not Avalon. All the code that will be pulled into stratum is code that I've
refactored and pulled out of the original turbine code base. I'm not going
to toss it all and start using Avalon.
> When I see multiple projects all with similar lifecycles, using different
> libraries, and thus uncompatible it makes me sick.

C'mon, you guys have done the _exact_ same thing. Logging, pooling, database
connection pooling, configurations. Lots of these things existed elsewhere
but you wanted to try the IoC pattern with things and maybe some of these
existing components weren't 100% usable in their existing form but I don't
think anyone went out of their way really to try and work on these other
packages to make them fit into avalon.

Now don't get me wrong, I have done the same thing in many cases myself
because it was easier to make things fit and I too didn't want to give up
control over the development of a particular component. But don't try and
tell me that Avalon has the only legitimate claim to being a framework
around here because that's just nonsense. Competition is good, diversity of
ideas is good even at the cost of the replication.

Lots of people don't want to use Avalon, even more probably don't want to
use Turbine and competing packages are showing up everywhere here and that's
the way it is. There's a new services package in the commons which I'm sure
will spawn some sort of lifecycle and configuration as always happens. That
doesn't bother me at all.

I know why people don't want to use Turbine and I honestly rarely recommend
using it because it's not for the faint of heart right now. If someone can
get the job done easier with something else like Struts than all the power
to them. Turbine exacts a high toll in terms of forcing people into a lot of
patterns (some that aren't very good I admit) and Avalon does the exact same
thing which is why many turn to the commons for components. Don't be
surprised if the whole of avalon is rebuilt in the commons in little pieces
because it's going to happen.

I have something nifty that I want to try in stratum and then I hope to put
all the pieces into the commons. I don't think stratum has a long life
expectancy but I need it to refactor Turbine. But in the long run I think
people are going to look toward the commons for components.

I think I share with you the philosophy of providing a consistent mechanism
for develop WRT to components and methodologies  all wrapped up in one
package but I am always arguing with people about this. I like my arguments
with Geir because he often counters my sometimes monolithic approach to
things. I am honestly trying to provide a consistent development environment
in Turbine just as you are in Avalon but it's a monumental task. Plus I
think that around here people are more like us anyway and are going to take
the bits and pieces and roll their own systems. And the components in the
commons make this easier so it's something I'm definitely rethinking.


Jason van Zyl

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message