cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Maven info wanted
Date Thu, 28 Sep 2006 17:40:11 GMT
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?

> 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?

> 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.

> 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).

I was one of the last people around here that agreed to use Maven as build tool 
but in the meantime I have to say that I like it although not everything is as 
perfect as I would like to see it.

> 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.

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.).

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

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



Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:

View raw message