February 18, 2008

ant, maven, ivy

ant vs maven... again... and more

maybe we should refactor our ant and try adding ivy to the mix?

a few resources

Maven and Ant - the eternal debate

basically, if you want total control, use Ant. If you are willing to comply with the Maven way of doing things (and there is a lot that makes sense), then Maven can give you a lot of added functionality free. However, the learning curve is a lot steeper than with Ant.

Tapestry and HiveMind: Maven: Won't Get Fooled Again
I can't express how much grief recommending Maven has caused me. I had a good experience with Maven for Tapestry 5 for quite a while and had the hubris to recommend it for The Really Big Project.
....

Maven simply doesn't scale to this level. Sure, the command line build does work in relatively short order (more on this shortly) ... but for day-to-day usage it's all about the IDE, and the IDE support for Maven just isn't there yet, may never get there.

In both Eclipse and IDEA, the Maven support has been very slow, buggy, and unstable.
....
Perhaps the worst part of Maven is the documentation

from the comments:

my friend Merlyn checked [Buildr] out. Liked it initially, but it started failing with no error message as soon as he started to use it in earnest. Not ready for prime time.
(Howard)

I feel your pain. We are using Ant now for big stuff, because it takes just too much time and knowledge to maintain a Maven build. Even the Ant build is not very simple, but at least it doesn't break all the time. Next time I'll resort to Bash scripts. All this programming in XML is just a major PITA.
(Ortwin)

Strictly limiting myself to Maven-IDE integration, I can tell you from personal experience that Eclipse-Maven integration is a big JOKE.
(bhaskar)

Ivy is with no doubt a great tool. People say that Maven's dependency management came from Ivy.
(Josè)

Don't bother with Ivy, either.

Ivy doesn't really handle broken POMs very well (I think the one for Tapestry-4.1.3 is broken, actually), whereas maven may very well work with it. The Ivy folks say the POMs need to be fixed in the repository, the repository admins say everything works fine in maven, so you end up with a nice little stalemate where you're the ultimate loser.
(Kevin Menard)

I feel your pain, I used to evangelize Maven but have since become an Ivy advocate.

Ivy is far more flexible on how you setup your repository and, because building is delgated to Ant, Ivy doesn't try to dictate your project structure like Maven Does
(distiller)

I've been burned in many ways the same as you have - downloading broken releases, documentation that is flat-out lying, etc., but what's an alternative? Give me another tool that uses convention over configuration, dependency management and copius plugins and i'll consider it.
(Jay)

Personally, I have had such bad experiences with Maven based projects now that I refuse to contribute code for any project which uses Maven (because I refuse to use Maven).

Replacing Ant with a Ruby solution isn't ideal either. Buildr is a good idea, but not the right implementation.

From where I sit right now, the best thing would be to do a Groovy based tool set (gant is a good start because it gives you the power of Ant, Groovy and Java in one tool, but it lacks the structure of Maven).
(J S Stevens)

Maven problems (especially with IDE):

Eclipse crashes<

Long (10 - 20) minute start up times, as POMs are processed and dependencies downloaded

Intense efforts to hunt down conflicting dependencies

Huge memory consumption

Insanely bad IDE performance

Unwanted dependencies between projects (that both happen to use Maven)

IDE hangs bringing up the Maven settings panel

IDE hangs opening the project after upgrading the Maven Eclipse plugin version

Broken Maven plugins that fail to work as advertised (i.e., do the wrong thing in multi-module with no recourse)

Plugins that stay as an alpha for 2 - 3 years (though surefire 2.4 finally did come out)

Inability to get any useful debugging information out of some plugins (surefire/testng can bomb out with no output anywhere, no clue what the failure is)

Plugins that break if you aren't using the standard Maven project layout (i.e., are hard coded to src/main/site, etc.)

Utter lack of documentation
(Howard)

No comments: