Monday, September 18, 2006

Vote to stop Maven infesting Spring

The recent announcement that Spring will start using Maven exclusively for their build has sent horrors down my spine. Fortunately, I'm not the only one who feels this way with many blogs around the net spreading their dismay.

Maven, in my opinion, has caused more hassle than it is worth on two projects I have been involved in (Groovy and Cocoon) and I made a concious decision to avoid it when starting Grails.

Luckily, there is a new issue on the Spring JIRA that lets you vote AGAINST Spring using Maven. Cast your vote now. Your grandchildren will remember you for it.

21 comments:

Anonymous said...

Doh! We were planning to move Terracotta's build system from a custom solution built on Jruby wrapping Ant to Maven2. Could you tell me more detail about the heartache it has caused?

Anonymous said...

Does it matter how they build their software? We get a Jar that is built and don't really care how it got there.

If they want to get all the heartache and problems from Mavin (like on a project I was on where any code changes required mavin to recompile so sometimes it took 10 minutes between a change and testing that change).

As long as they produce a Jar that will work in a project without Maven, it shouldn't matter.

Daniel Serodio said...

Also, what is the problem with Maven?
If you've been burned by Maven1, try Maven2 for a pleasant surprise.

Anonymous said...

Lacking support for Maven2 is why I don't use grails. Maven2 has been used on 4 projects that I started and totally rocks over ant for "convention over configuration".

You're stuck, dude. Don't let fear control you.

Graeme Rocher said...

Actually, I've been given a demo of Maven 2 at JavaPolis and although I would still not touch it for my own projects I understand why some may like it.

We may actually provide some level of support for Maven 2 in Grails to placate disillusioned users like yourself ;-)

Oh and btw Grails is moving away from Ant for 0.4 so your point about Grails being based on Ant will become irrelevant

Fact is XML is not the right choice for a build language, period. Whether it be Maven or Ant.

Oh and I don't feel any different about Maven 1, which is one of the most horrific pieces of software I've ever had the displeasure of using.

Anonymous said...

Don't get The Maven Fear. You better put that blade away and get your head straight. Maven2 is a vast improvement over Maven1. Download Better Builds With Maven (http://www.mergere.com/m2book_download.jsp) for free.

Graeme Rocher said...

Thank you, but I would rather write my build in MAKE or bash than maven

XML based build systems are dying. Next. ;-)

Anonymous said...

XML based builds are dying? You'd rather write MAKEFILEs all over the place that are unique for each platform? Sounds like you have an aversion to learning new technologies. The only constant in life is change - embrace it.

Anonymous said...

@Anonymous: Grails is based mostly on tech that's _newer_ than XML or Ant. I think Graeme's just saying XML for builds is yucky. Nothing to do with new or old.

Anonymous said...

I've worked in many projects using maven2. It was allways a greate pleasure to work with maven2. The lacking maven support in grails is a big disadvantage. There is nothing to say against grails, except the maven support.

Anonymous said...

Lack of Maven support is also our reason not to use Grails. In fact, within our TomTom department, we don't have any projects *not* based on Maven.

Laurent PETIT said...

Really, XML use in maven cannot be compared to XML use in ant.

In ant they have created a more verbose way to program 'tasks' : no abstraction there, they have reinvented java functions + some minor improvements ('depends', ...).

In maven (1 and a step further in 2) the use of XML is for the descriptive part of your project's meta-data, only.

The 'task' parts are hidden in the plugins internals.

Yes, the maven syntax is still way too verbose, but this could certainly be simplified with, say, a groovy Builder syntax ? (maybe this already exists ?) :-)

The biggest problem with not using maven is, for me, the lack of a clean possibility to do configuration management, in a standard way.
I really miss the possibility to explicitly define the (versions of) dependencies of my project.
I'm not sure how I can declare I use a plugin or a taglib with having to copy'n paste it into the grails project, ...

There certainly is place for improvement in this area.

Maven is fairly good at that, and that's certainly why so many people ask for an integration with maven.

Anonymous said...

Maven2, despite its shortcomings, make development in Java a little better. The worst thing is hunting down jars and adding them to your build and to your ide classpath ... People like you make Java harder than it should be. I've been playing with grails for fun but if it doesn't provide first class maven support it won't be used at work. I have too many other problems to solve.

Anonymous said...

I would use Grails if it had Maven support.

Graeme Rocher said...

You guys are not going to shift my opinion on Maven/Maven2, I believe that it can be successfully deployed if you manage your own repo, but out sourcing the dependencies of your project to a remote server you don't control is a crap idea. end of story.

As for Grails and maven support. There is a third party "Maven tools for Grails" project that provides maven integration if you need it: http://forge.octo.com/confluence/display/MTG/Home

Arnaud said...

Yes you have in a corporate environment to manage your own repository(ies). It's a very useful tool to control dependencies used by different projects. Which dependencies are used and more important where they are coming from. For example in grails (http://jira.codehaus.org/browse/GRAILS-1386) I wasn't able to locate where you found approximatively 15 jars. It can be a real problem to integrate in a grails application which require another version of a grails dependency.

Anonymous said...

Hey,
I guess you better use Make. Ant is too complicated and Maven2 is quite stressful.
And also there's a brand new editor in the market called VI. Use it. Eclipse and Idea are stressful as well.

;)

Graeme Rocher said...

Cheers, but I'm quite happy using Gant (http://groovy.codehaus.org/Gant) ;-)

Igor Polevoy said...

I have been using Maven 2 for about two years. It has be hugely advantageous on many corporate projects. We do use a local repository, which we use for posting snapshots and releases from various projects and even sub-projects. This allowed us to build a common repository of components at virtually no cost. Lumping Maven and Ant into a category of XML -based build tools is somewhat misdirected. I started looking at Groovy and Grails, and of course, lack of Maven support is a big disappointment.

Unknown said...

Maven Gant Ant Make who cares as long as it is used and usable consistently across projects. Maven is the only such project showing any hope in that area - which is why I put up with it's horrendous crap, and happily. So if you dish Maven and replace it with yet another brand of chaos that doesn't work with the rest of my projects then I'm pimped and you are proved right because who can compare apples to oranges ? It would be easier for me if there was less self righteous chest beating and more dual system builds that allowed both Maven and Gant. That starts with directory structure and fans out from there, in my view.

crowne said...

Quite late, but I agree.
I very nearly used grails last year but for the lack of maven support.
I would have been happy do build my own later on, if the directory structure started as per below:
src
   /main
   /test
target