Reinhard Poetz wrote: <snip/>
> We have invested a lot of time into making trunk build with M2. And > don't forget that it's much more than just compiling the thing. > > We have two archetypes, one deployment plugin, the documentation which > is exported using Maven, a working integration build, reports and > certainly much more. Also don't forget that releasing a Cocoon > artifact has become very simple. And one last point: If you build > Cocoon using some different build system I think that we cannot > forbear providing Maven 2 metadata files (pom.xml) because many > developers will ask for them. I'd like to react on that last point: a POM is just XML. And if there's a place where we know that XML is an interchange format, this is for sure here in Cocoon-land. And we know there are plenty of solutions to generate XML files in whatever format we want from whatever data source we have. There is a good thing in Maven: the repository, where people can pick up dependencies (well, when it works) rather than copying them in their own source control repository. This is not good for a large in-house project where you want to control and version everything, but a good way for OSS projects to lighten their development process. Now the problem with Maven is that, because people are interested in that good thing, they feel obliged to use the tool where that repository and the associated file format was born. Why should that be a requirement? Why couldn't the POM be used/created by other tools as well? With its POM and repository, Maven managed to create an amazing dictatorship on the entire OSS Java community. That buggy tool (because yes, it is buggy) with no clear documentation is becoming a vital part of many projects. So vital actually, that it has endangered and damaged some of them. Look at what happened here: I personnaly stopped looking at the 2.2 branch after spending too much hours trying (and finally giving up) building Cocoon with Maven. The broken 2.2 build lasted for weeks and months. The switch to Maven is one of the reasons of me leaving the project, even if I wasn't against it a first (I wasn't particularly enthusiastic, but trusted the majority that wanted this move, and was also naively caught by the hype). Similarly, Jorg became a Maven expert, actively participating and contributing to Maven. Very good for Maven that earns his skills and time and kudos to him for all his efforts, but so bad for Cocoon that lost his valuable time for more useful things. Ant+Ivy just works, and you understand what happens in your build. It provides dependency management, and can also use the Maven repository (yes, XML makes things interoperable). Converting an Ant build to an Ant+Ivy build merely means writing an ivy.xml (or pom.xml) expressing the dependencies and changing the <classpath> instructions so that they're build from the dependencies artifacts that Ivy will download, rather than from e.g. "lib/*.jar". And writing Ant tasks that mimic an artifact, deploy and release things are not rocket science. My 0.02 euro. Sylvain -- Sylvain Wallez - http://bluxte.net
