Jose has posted 9 posts at DZone. View Full User Profile

Finally... Maven

  • submit to reddit
I've always been a happy Ant user. Even more so since Ivy has been available. Obviously that puts me in one side of the fence and I've been a very proactive supporter of that kind of project configuration. I must admit that included some rants about Maven here and there. In my biased opinion Maven lacked the flexibility that Ant provided and it was all about dependency management which was handled fine by Ivy. Probably my lack of confidence (knowledge) with the tool had some influence there too.

Four things made me reconsider my position: Hudson, Sonar, Netbeans 6.7 and the amount of time I was spending writing scripts. At work I had to install a CI server a couple of weeks ago and I was not using CruiseControl if at all possible (bad bad memories, I guess). That left Hudson as the best option (well, for me). I spent some time through the documentation and quickly realized that Maven was quite more straightforward than Ant this time. I needed a quality tool as well and Sonar has always been on my radar. Sonar works (again) out-of-the-box with Maven and requires some extra configuration with Ant. Being the lazy developer that I am I decided to test Maven with one project and see the results.

My first impression was pretty favorable. Migrating a simple Java project was a breeze and setting the job in Hudson trivial. I had the statistics online in less than half an hour. Finally I was understanding what was so good with Maven. It was not transitive dependency management, it was Convention over Configuration with the added benefit that other people where writing very interesting plugins for me. With absolutely no work on my side I had an automated build, quality control (testing plus quality assurance) and Jetty running. By now, I was in love with Maven. In more detail:

  • Zero configuration
    So much time lost with Ant refurbishing the same scripts time and again...

  • Dependency management
    I found Maven quite easier to handle than Ivy. I really really missed the master configuration of Ivy though (it saves time when you don't want transitivity for any reason).

  • IDE support
    Today all major IDEs include seamless integration with Maven2. Latest Netbeans release, in particular, works wonders (the reactor plugin is awesome). Ivy support is scarce by contrast.

  • Redistribution
    I've had to invest quite some work, many times, to offer Ant+Ivy scripts along with different project files (Eclipse, Netbeans, IDEA) to appease all kind of users. Not any longer. POMs are treated as first class citizens everywhere now. With the added benefit that I'll be able to upload the builds to the central repository.

  • Future
    I'm under the impression that things like OSGi will be pretty much simpler with this approach.

All in all, I'm leaving Ant. For good. I can't say anything but praises about Ant, it's been years of comradery. And yes, it's a somewhat sad situation but I can't help seeing it obsolete, overridden..


Published at DZone with permission of its author, Jose Noheda.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mike P(Okidoky) replied on Wed, 2009/07/08 - 12:19pm

My experiences with Maven in the past have been bad.

Every time I downloaded an open source project that required Maven to compile, it just didn't work. Always some excuse, some incompatibility, libraries missing, on and on it went.

It's possible to make managing ant files a little better. You can use include files through xml entities. But what I do is I run my very basic project xml files through a bunch of xsl files and generate the build.xml file. I then include the build.xml with the source control or distribution. That way, no one has to worry about any funky build process related programs or procedures. Just hit 'ant' and it just works.


Geoffrey De Smet replied on Wed, 2009/07/08 - 1:41pm

Maven is great. Hopping into a maven based project is easy, especially if they follow the standard directory structure.

These days, when I have an issue with an open source project, I either check it out and do a "mvn clean install -DskipTests", try to fix the issue and contribute the patch back to the open source project, or - if it doesn't have a maven pom.xml - I don't.

Michal Huniewicz replied on Thu, 2009/07/09 - 5:19am

Well, plain Ant with Hudson works just fine (and pretty seamlessly with Sonar). It only requires filling few fields. However creating similar Ant build files for different projects is definitely not an elegant task.

cowwoc replied on Thu, 2009/07/09 - 8:15am

At first glance Maven has two problems:


1) Use of XML leads to readability problems (similar to Ant I guess but it seems even worse)

2) The directory structure convention seemed to target computers instead of human beings.


Wouldn't it be nice if a build system was actually readable for once and didn't require you to totally mess up your directory structure?

Jared Bunting replied on Thu, 2009/07/09 - 3:17pm

1) The xml can sometimes seem excessive - one design decision they've made that I don't particularly agree with is not using xml attributes - that seems to make it a lot more verbose.  That being said, if I pick up a pom.xml from someone else, I understand what it's telling me several orders of magnitude sooner than if I pick up a build.xml from someone else.  And yes, I'm fairly familiar with both tools.


2) You don't have to mess up your directory structure.  On the other hand, if you use a custom directory structure, you lose a lot of the advantages of convention (over configuration).  Also, once I got used to the directory structure,  I found it very useful and straightforward.

Walter Bogaardt replied on Fri, 2009/07/10 - 5:42pm in response to: cowwoc

Maven has a project convention of how a project should be, but it can be overridden to the so called "human friendly" format.

XML is actually quite readable and Eclipse actually has a plugin to view Maven build files as a nice input form.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.