cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Maven-based builds (was [heads-up] Block builder available)
Date Wed, 23 Feb 2005 15:53:26 GMT
Ralph Goers wrote:
> Reinhard Poetz wrote:
>> Mark asked me about my vision about blocks. Well, I think, its very 
>> close to that what Stefano proposed 18 month ago.
>>  - A block is a service provider (components, pipelines, flowscripts)
>>    that other blocks can use.
>>  - Blocks can depend on other blocks (use or extend them)
>>  - starting your Cocoon based project is done as a block
>>  - the general behavior of a block is described at a _single_ place
>>    (block descriptor)
>>  - a very lean Cocoon core (only pipeline and flow stuff)
>> As you can see, my vision has nothing to do with Maven, Ant or any 
>> other build tool. Personally, I like Ant more because *I* understand 
>> it and I know exactly what it is doing. *My* personal experience is, 
>> that whenever I used Maven, I ran into problems and it took me ages to 
>> get things going. Probably my personal stupidity :-) Two other reason 
>> for me : Since Ant 1.6 reusability (import and macro) is possible 
>> (it's not true any more that you have to write your Ant scripts over 
>> and over again) and that nearly everybody is able to read and write 
>> Ant himself.
>> Hence I went for Ant. Writing an XSLT that transforms the block.xml 
>> into an Ant script wasn't very difficult and the best solution *for me*.
>> If somebody can show a (better?/another) solution using Maven, we have 
>> a whiteboard. It can be used to setup the ideal environment for Maven 
>> and we can decide whether we think the required changes are good or 
>> not. The only requirement I have is, that block.xml should be used to 
>> drive the build but it was shown that this isn't a problem at all.
> I'm in total agreement with this. The main difference is, that anything 
> you can do with ant you can also do with maven since ant is an integral 
> part of it.  I envision two parts to a building a block.
> 1. Build the block jar. This would contain the classes and configuration 
> that every implementation of the block would need.


> 2. The cob.  This would merge the block jar and the sample into an 
> installable or deployable block.

I wouldn't call it sample. It's a Cocoon application that provides pipelines 
(via sitemap) and flowscripts. We will have to find a better name than sample.

> Obviously, the output of step 2 has to contain what is needed for 
> deployment and have the correct layout, so this needs to be well 
> defined.


> Is it already?

not yet (that's the resons why there is no cob target in the block-builder) - we 
have to define the contract of a COB (metadata, directory structure, versioning)

>>                                       - o -
>> Block deployment is another story. I've started to work on the 
>> deployer which is in its core an API that does the actual deployment. 
>> Different tools (Ant, command line, Maven, Eclipse plug-in, ...) can 
>> use this API. Here I would be _strong -1_ to have a tool specific 
>> solution, e.g. an Ant task that is more than using this general API - 
>> otherwise we have to maintain the deployment behavior several times.
> Is the deployer a runtime deployer or does it just merge the block into 
> the cocoon webapp? 

The second. The runtime deployer could (should) use the block deployer

> I don't have a problem with a tool that can be 
> invoked via an ant task.

or by a Maven plugin :-)

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

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


View raw message