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.
yes
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.
yes
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}web(log): http://www.poetz.cc --------------------------------------------------------------------
