cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <>
Subject Re: [RT] a simple release plan
Date Thu, 16 Mar 2006 23:54:35 GMT
Reinhard Poetz wrote:

> Daniel Fagerstrom wrote:
>> The blocks FUD
>> ==============
>> I'd like to remind once again that the blocks work doesn't 
>> destabilize the traditional use of Cocoon the slightest, see 
>> It just cannot affect that as there are no dependencies from the 
>> "traditional" parts to the blocks fw whatsoever. Concerning the OSGi 
>> stuff it is not even part of the build yet.
>> So the idea that the block work should hinder anyone to work as usual 
>> is just plain wrong.
>> M10N
>> ====
>> What hinder people to work as usual is that the M10N isn't finished. 
>> Now it isn't that hard to use Cocoon anyway as I described in the 
>> reference above. But of course it would be nicer to be able to use 
>> Cocoon with some blocks OOTB. If you don't want to take part in 
>> working on the blocks fw and deployer and is impatient, it wouldn't 
>> be that hard to write a plugin or an Ant task called from Maven that 
>> does the file copying that is described in the reference above.
>> BTW, I'm quite surprised that you want to go back to the messy Ant 
>> build from 2.1.x after having argued for building Cocoon with Maven 
>> for years. Have you lost your faith in Maven?
>> Springification
>> ===============
>> Talking about destabilizing, a couple of weeks ago the trunk was 
>> usable after the file copying referred to above. Actually it was so 
>> stable that I developed a small customer application with it without 
>> any problems. And AFAIU Reinhard have developed a large application 
>> in it. This is not the possible anymore, after the Springification.
>> I tried to start a freshly checked out trunk together with the ajax, 
>> form and template block after having copied the configuration files 
>> and samples to cocoon-webapp as described above. The start page 
>> worked, but all access to sub sitemaps gave null pointer exceptions, 
>> where the TreeBuilder configuration can't be loaded. IIRC there where 
>> other things that was reported that didn't work a couple of weeks ago 
>> as well.
>> I suggest that the container should be reasonably stable before even 
>> thinking about doing any big moves.
>>            --- o0o ---
>> Not surprisingly I'm -1 on your points 2 and 3. If you want to 
>> continue in that direction which IMO represents a huge step back. I 
>> insist on that you prove that it work and that you actually have the 
>> persistence to carry it through, on a copy of the trunk in the 
>> whiteboard. After that you need to cast a vote about making that the 
>> new trunk.
>> Also it should be much easier to update the Ant scripts than changing 
>> the directory structure.
>> Anyway, why you would like to make such a huge effort in such an 
>> backward pointing direction, instead of helping to finish the blocks 
>> work or at least the M10N, is just beyond my imagination.
>> /Daniel
> I agree with Daniel.


Best Regards,

Antonio Gallardo.

View raw message