On 12/26/01 8:42 AM, "Berin Loritsch" <[EMAIL PROTECTED]> 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
