cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [RT] a simple release plan
Date Wed, 15 Mar 2006 23:27:19 GMT
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.

                                     - o -

I want to add some thoughts to Daniel's idea of writing some Ant script for the 
build: trunk has been mavenized and split up into many modules. The missing 
thing is some tool that will create a web application out of a number of blocks. 
In a "world of real blocks" that's the job of the deployer that I wrote.

If somebody has the need of writing some deployment tool without having to 
understand blocks-fw, he could write an Ant script or an M2 Mojo that get some 
kind of configuration which blocks should be installed:


Then the mojo deploys them to the right place and takes the component 
configuration out of it and puts it into /WEB-INF/xconf.

As M2 offers some Ant tasks to get access to M2 repos, this could be done with 
Ant too.

I don't have the time right now and also don't have the urgent need for it - I 
will concentrate on learning more about the configuration service, implementing 
the OSGi contracts within the deployer and write a Daisy M2 plugin.
But of course I will help with my experiences with M2 mojo development. Also 
checkout the cocoon-deployer-plugin module, which should give some 
implementation hints.

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


Telefonate ohne weitere Kosten vom PC zum PC:

View raw message