cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
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}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

	

	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

Mime
View raw message