Reinhard Poetz wrote: > Sylvain Wallez wrote: >> 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. > > I can't follow your argumentation here. What are you missing?
Sorry if this wasn't clear. I'm not missing anything, but in a large consumer project you need to carefully know and control what's used to build your software. Having artifacts downloaded from a remote public server doesn't allow for repeatable and controlled builds. Even more when the build/dependency management system itself self-updates from the remote repository. So although a remote repository is really convenient when you are developping (provided that the repository is available and that automatic updates of the build system don't get your team stuck for more that one day as happened to me), it's definitely not something good when a repeatable and mastered build is needed. >> 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? > > Who or what prevents you from doing so? Absolutely nothing! And that's the whole point: people are using Maven-the-Tool because of Maven-the-Repository. Granted, the repository would not have existed without the tool (and the effort of all repository maintainers). But although Maven-the-Repo alleviated some pains and brought some new features, Maven-the-Tool brought new pains. And since the repository is "just" data, there is room for other tools to use and feed it. I don't remember if alternatives existed when Cocoon's move to Maven started and don't want to rewrite history nor Cocoon's build system if people are happy with it, but the point is that there are alternatives now. >> 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. > > If you're refering to Cocoon as a victim damaged by Maven, I'm not > sure that this conclusion is fair. As Daniel pointed out, I think that > we did a lot to damage ourselves by having too many dependencies > across our code base. I disagree: this is not the main cause of damage. Although the current effort is more than welcome, the golden days of Cocoon where when we had myriads of dependencies and an XSL-generated Ant build file. There are many concurring factors, both internal and external, that can explain the project slowdown. A discussion for the Hackathon? <snip/> >> 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. > > no, it's not but all those tedious things have to be done and I want > to warn you not to underestimate the work. I won't stop any of you to > fix what *you* consider as broken but don't expect that I will get > excited about rewritting many things (poms, archetypes, deployer, > documentation) or mimicing feautres that Maven provides out of the box > or via its plugins (many reports, releasing artifacts, etc.). I'm not saying that Cocoon's build *should* be rewritten. Just that Maven, because it's a kitchen-sink that is meant to provide everything and even more actually turned into a dictatorship. Had it been flawless, we could have lived with it. Now it isn't, and the dictatorship actually sucked energy from the project. Makes me think we can write a new chapter in the Software Darwinism story: Software Parasitism, where in order to survive, a project needs to "plug" into existing organisms and suck its vital substance out of them. Some of the host organisms survive and can even take benefit of the parasite (i.e. symbiosis), some suffer badly but survive, some die, and some find ways to get rid of the parasite. Sylvain -- Sylvain Wallez - http://bluxte.net
