avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <jvan...@zenplex.com>
Subject Re: Synergies between Avalon and Commons projects (was: Re: Breaking Excalibur into smaller swords)
Date Sun, 30 Dec 2001 01:09:04 GMT
On 12/29/01 12:15 AM, "Peter Donald" <peter@apache.org> wrote:

> On Thu, 27 Dec 2001 02:29, Jason van Zyl wrote:
>>> 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.
> 
> you would be surprised. I wasn't around at the start of Avalon but when me
> and Berin joined up there was several moves to reuse existing infrastructure.
> JDom for config, JNDI instead of ComponentManager, Log4j instead of LogKit,
> etc. In some cases they didn't suite and we couldn't change (ie JNDI). In
> both JDOM and Log4j I tried to get the developers to adopt changes to make
> them suitable for our use but in both cases the authors refused or botched
> the suggestions. We got nowhere and down the track Ceki ends up calling me a
> liar and a thief.

Not touching that one with a ten foot pole.
 
> Don't be so sure that we (or at least I) haven't tried to work with these
> other packages. Sometimes there was different aims between packages and
> sometimes it has been difficult people running them. In all cases it was
> cheaper to work without interaction and it produced a better framework in the
> end.
> 
>> Don't be
>> surprised if the whole of avalon is rebuilt in the commons in little pieces
>> because it's going to happen.
> 
> and quite a few people encourage it.
> 
>> 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 Berin was irritated because you are going to push it into another
> project. 

I don't see that as anything to get upset about.

> As I suspect you understand rarely is anything as temporary as
> people think and it is highly likely that it will end up living on - <insert
> obligatory SNMP was only a temp spec but look at it now story>. Given how
> close parts are likely to be to Avalon/Framework ...

Stratum hasn't gone into a repository yet and pieces that were in stratum
have already gone into the commons. The graph package is an example of that.
I realize that software that is released tends to stick around and linger,
but before turbine 3 is released I plan to move everything into the commons.
 
> Think of it this way. Currently I have a fork of velocity sitting on my
> hardisk as it didn't provide what I was after - namely a dynamic
> invocation/bean api (similar to that which is in almost every script language
> and present in other templating languages). When I finally upload phoenixs
> management console I doubt you would aprove if I also uploaded "raptor" a
> clone of velocity with the changes made that I needed made.

Honestly, that wouldn't bother me at all. If you need to add things so that
it works the way you need than I'm glad that the base code was a useful
start for what you needed. I have never chastised anyone for taking a piece
of code and modifying and even offering it to others to use. If you put
raptor in CVS it wouldn't bother me one iota.

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message