I've been a bit late to catch on to Maven2 - it's been around for about two and half years now. I've previously been put off by the reputation of Maven1, the language used to describe Maven and some fanatical "fanboys". I know a lot of people of who are generally up-to-date on the latest technologies who haven't given Maven2 much of a chance, I'm guessing for similar reasons.
I'm no "fanboy" - more like a "somewhat in favour of it middle aged man" - so I want to explain to my fellow sceptical oldies who have avoided Maven why they should give it a chance.
The very first sentence on the Maven web site is exactly the sort of language that puts me off it.
"Maven is a software project management and comprehension tool."
It doesn't tell what it really is and it doesn't sound like what I'm looking for. I'm going to try to explain what it is in a way that would have got me trying it sooner, so I hope my description is suitable for others too. To be fair to the authors of Better Builds with Maven they do say that calling it a "project management framework" doesn't really tell you what it is. I know the first author, Vincent Massol, from XTC and he's a cool guy so I hope he won't take offense at my somewhat simplistic description of Maven - I'm missing out lots, I'm no expert in Maven, and I'm describing it with a different philosophy than the authors of Maven may have intended - but I am trying to describe what is it in a way that I would have "got it" if it had been described like this to me.
For example, I say that Maven is Java-centric. You can use it for non Java projects, but in many ways it shows it's "Java project" based history. And that's OK.
I've seen the same stuff in Ant build files repeated again and again from project to project. Compiling the code, running the unit tests, packaging into a war etc. Either hand-crafted for that particular project, or copied and pasted from a previous project. These Ant build files say much the same stuff but not exactly the same stuff.
Maven is like a set of sensibly written Ant targets which can be used with hardly any effort as long as you use the standard Maven directory structure. Things like compiling, running the unit tests and creating a war. It also provides a suprisingly large number of more advanced build related things, like running code coverage or pmd reports - also very easy to use without having to write a load of stuff.
Some people object to Maven "telling them that their directory structure should be". It does seem like the tail is wagging the dog. However, I say "get over it". Personally, as long as the directory structure is sensible then I don't care much exactly what it is. There are lots of directory structures and naming that would be equally OK - the choice, in many cases, seems somewhat arbitrary to me. The Maven standard directory structure is as sensible and good as most, so my advice is don't fight it - just go with it. If you really care that your source is in a folder called "source" rather than "src" - or whatever - then I think you should get out more. If you really care then you can configure Maven to cope with whatever you want - but why bother? I think the benefits outweigh the righteous indignation of "not being dictated to by a tool over the names of folders".
Ant built projects often have a "lib" folder containing the jars that they depend on. Using Maven, instead of having a lib folder per project, you have a "local repository" (just a bunch of files in a particular directory structure) instead where your jars can be used by multiple projects. Each project defines it's dependencies in a sensible declarative way and Maven sorts out the classpath for compiling the code, running the tests, or even packaging everything into a self contained executable jar with all dependencies. This sort of stuff is what Maven means by the phrase "dependency management"; "dependency" is one of those words which means lots of other things to other people.
Having the project's dependencies specified in the Maven way means that you only need this information in one place. For example, you don't need to specify this in your IDE as well (if you use one of the supported IDEs) - Maven can generate the project files for IDEA or Eclipse, so if you add a new dependency, rather than fiddling with both the build and the IDE's classpath, you just specify the depenency in the appropriate Maven file (pom.xml) and it sorts out the classpath for compiling, running the tests etc for both Maven and the IDE.
I've found Maven to be overall pretty good for some smallish projects that I've written recently. However, sometimes I've found it difficult to get it to do what I want. The documentation is patchy (particularly if you want to do something a little bit different from the standard case) - but I would recommend downloading Better Builds with Maven.
I haven't tried it, but I've heard that ivy does similar "dependency management" stuff to maven - but it's not clear to me whether it does the same other build stuff too.
Posted by ivan at February 28, 2008 7:59 AM