Re: Synergies between Avalon and Commons projects (was: Re: Breaking Excalibur into smaller swords)

[Jason van Zyl <jv...@zenplex.com>]

On 12/26/01 8:42 AM, "Berin Loritsch" <bl...@apache.org> 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:
>> 
>> http://jakarta.apache.org/~jvanzyl/stratum-proposal.txt
>> 
>> 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.
 
-- 

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Synergies between Avalon and Commons projects (was: Re: Breaking Excalibur into smaller swords)

[Jason van Zyl <jv...@zenplex.com>]

On 12/29/01 12:15 AM, "Peter Donald" <pe...@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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Synergies between Avalon and Commons projects (was: Re: Breaking Excalibur into smaller swords)

[Peter Donald <pe...@apache.org>]

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. 

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. 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 ...

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.

-- 
Cheers,

Pete

*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device.      |
*------------------------------------------------------*


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>