Torsten Curdt wrote:
Aehm... I thought the deal was: if someone comes up with a good alternative we can discuss it. ...wish is not what I would call "voted down". ...or am I mistaken?
cheers -- Torsten
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108543355819355&w=2
When the topic is specifically discussed and voted upon and gets no +1 votes and gets 5 -1 votes (Stefano, btw - contrary to his memory, did not vote no - he just didn't vote +1), I don't see the point in spending effort on it. This has not been the only discussion on maven here and it has seemed in the past that there was strong resistance against it. So if there are committers who are totally opposed to maven, I really don't want to engage in a waste of time.
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.
- 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.
--
Reinhard P�tz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}web(log): http://www.poetz.cc --------------------------------------------------------------------
