On Aug 28, 2009, at 1:16 PM, Kito Mann wrote:
> Jason,
>
> Why Maven? What about just using Ivy and Ant, or maybe even Gradle?
>
> I like the dependency management part of Maven, but the rest of it...
Ryan and I have talked about his a LONG time. At one point, we
thought we'd try ant+ivy, but it just made the build uglier. It's
been too long, so I don't recall the specifics, but it didn't come
close to helping.
TBH, I have only a passing knowledge of Gradle, but, from scanning the
docs, it has the same problem ant does (IMO) in that there's no
standard.
Having said that, here's why we want to move to Maven:
* Standard project layout. When I move from one ant project to
another, I have to take time to read the build file (ant -p doesn't
always list the interesting targets, as the developer has to give it a
description. Dumb). I have to scan the source tree or build.xml to
figure out where the source files are, the resources, the web files,
the tests. Where are the build artifacts put? Where is the final
deployable archive put? Yes, there are some common locations for all
of these, but ant doesn't enforce it, so you can't just assume. With
Maven, in every project I've looked at, I *know* where those are.
* Convention over configuration. Along those same lines, maven
assumes a lot (much to the Hibernate team's dismay), but that makes
the build files much simpler in the common case. Until I start doing
"strange" things (cobertura, YUI compressor, e.g., from a couple of my
projects), the build files are typically very simple, and always look
familiar.
* IDE Integration. With NetBeans, at least, and I'm pretty sure
Eclipse and IDEA at least have plugins for this, I can point my IDE at
a POM file and I have an instant project in my IDE.
* Built-in dependency management
* Built-in repository deployment
And I'm sure there are some others. Personally, there are some things
I'd like to see changed:
* The POM file is too verbose. It seems no one on the Maven team has
ever heard of XML attributes. Not everything needs to be a child
element.
* It's a bit rigid. For those times when you *have* to jump of the
rails, Maven can make that difficult. I've done OK with the antrun
plugin, but a cleaner, scripted approach (say, anything JSR-223
compliant) would be awesome.
* It can be slow. Reading and parsing all those XML documents can
take a bit longer than an equivalent ant build (I'm guessing. I've
not actually tried, because...) but the effort it would take to build
an ant-based build system for a multi-module project is worse than a
slightly slower build.
And I'm sure there are more. :)
Since no one has raised any show-stopping complaints, we'll probably
press on with Mavenization. At this point, we're just rearranging the
source tree to the Maven standard layout. In the interim, should
someone propose a compelling alternative build tool, this directory
layout can still be used more likely than not.
Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com