2010-03-01

Maven Intimidation-Over-Convention

The beginning


Some time ago I looked at my Ant files, maybe a 1000 lines each, and I thought: this needs to change!

With Ant, everything is possible, but at the end of the day you just copy your Ant stuff from your previous projects to your new ones because things like compiling or running tests require a lot of boring and mindless XML coding, so you want to save yourself from it and do a bit of copy-paste instead. That's a little sin everyone commits. No need to mention that it quickly becomes hard to modify and maintain.

The long awaited solution?


So I decided to try Maven. Everyone has probably seen the Maven adoption curve by now, I'm sure. Nevertheless, I called Maven to the rescue and... now I'm looking at 1000 lines long Maven files. Great.

The complaining


Wait a second! What about those promises that Maven is so concise compared to Ant? What happened to convention-over-configuration?

Okay, so a large number of those 1000 lines is dependencies. But then - have you ever tried integration tests with Maven? Not supported by default. Copying a file after the build is done? Hmm... problem. What's more, I've seen people posting questions about Maven and getting an arrogant response similar to "If Maven can't do it then you're doing it wrong; you don't need it, you just don't realize it yet". Quite buggy support for Maven in Eclipse (and IDEA, I heard. Update 2010-03-02: However, Lieven suggested that IDEA support has been greatly improved, thanks Lieven. I tried it myself and found it a bit rough (how do I even add repositories? I can't modify the list), but at least it works.) is another thing... Eventually, I even mastered writing Maven plugins.

This stuff makes your pom.xml file damn long! That's not what we wanted!

Will code Maven plugins for food

The consolation for Maven


Anyway, the list of problems with Maven is quite long and it is not my intention to write another one. Don't get me wrong, Maven is a fair tool, it does bring some conventions after all (at least the projects look similar which makes them easier to pick up) and at least it solves the compilation, unit tests, and dependency management for you (but then, some say it is too much for one tool and against the Unix philosophy - do one thing well).

The expectations


Now, what would I like to see in a project management tool like Maven?

  • Relieve me from tons of XML
  • Provide application-type-specific solutions (something like JEE Profiles?), more sophisticated than just selecting the output file extension
  • Provide support for more than one kind of testing
  • Allow for scripting flexibility (like Groovy or Scala; this is happening)
  • Support all JVM languages seamlessly
  • Nice documentation
And if only it had strong IDE support...

The conclusion


I don't regret trying Maven and if you haven't done it yet yourself, it's time to get your feet wet! But before you decide to migrate to Maven, perhaps you should:

To conclude, I think that Maven is a righteous step on our difficult and perplexing road leading to a mature and flexible project management tool so that .NET can copy it and rename it by adding an N in front of its name everyone is happy. A righteous step. And it's time to make a new one.

Please feel free and encouraged to leave your thoughts below the article.
Posted by at 1:47 PM
Labels: , , ,

8 comments:

  1. Funny. I was at a .Net flavored Open Spaces event this weekend where we talked about possible solutions for a gems-like experience for .Net. Very little consensus of any kind, but everybody agreed that a Maven analogue was not desirable;)

    Jeremy D. Miller
    ReplyDelete
  2. Good post, and I agree, that the first POM of a project series is gargantuan.

    One thing you might want to try is creating a single parent that houses:

    1 - All the reports you like to see
    2 - All the build steps you use.

    Then have your internal projects inherited from that basic POM. Once setup, you can have an inherited POM in as few as 6 lines of XML. (I typically have about 20 because I specify SCM, name, and a few other metadata-elements).
    ReplyDelete
  3. Sure, since when build tool became a damn BS framework? Make, Ant, Maven are all good. They all have special purposes. I prefer Ant but it just so dang boring and time consuming setting up a project. Maven is smart for one thing, stupid in another (copy file after build foe example). I may check out Graddle after all. Don't stop, believing (insert lame Journey's lyrics here)...
    ReplyDelete
  4. Very nice. Get ready for the Mavenites to swarm in and let you know you are just too stupid to use it right.
    ReplyDelete
  5. i agree with your expectations. and indeed they are working on some of the issues for maven 3.

    i'm using maven frequently ever since 2.0 came out and i must say i'm feeling pretty comfortable at the moment when it comes down to building java projects with it. i think there's one real 'problem' though, like you said: too much for one tool. as a consequence it attracts a lot people, but you can't please everybody. also, when you aim to do it all (deps, lifecycle, reports, releasing, ...), you need to provide a pretty big library of documentation.

    i don't know if maven 3 will convince people who are not satisfied with the current implementation. don't know if that's the point either. i've seen some examples about declaring dependencies in for example a groovy DSL. but for me that doesn't change anything if the DSL is simply to provide an alternative to XML. i don't really care about the number of characters (within certain constraints of course). i think the actual (for me minor, but still) problem is still not solved: how to do stuff which is not available in a plug-in? will it be possible to write a groovy recursion on a couple of directories and do some magic stuff, right there in the groovy pom file? that's what people are talking about when they say maven needs scripting support. gradle offers this kind of stuff, but has a long way to go.

    so for a while i'll keep on using maven and (g)ant and keep up-to-date with gradle.

    @Tim we maven users like to call ourselves The Apostels, so pay some respect and address us with the appropriate title or at least something equivalent. no wait, what i meant to say was: grow up ...
    ReplyDelete
  6. Cześć Michał :)

    Here are my random comments:

    "Copying a file after the build is done?" - the particular problem (log4j) is explained in stackoverflow. General problem of copying a file - use Hudson :) Maven will build your artifact (it was designed to do it) and Hudson will do the after steps.

    "with Groovy instead of ugly XML" - is YAML or Groovy POM really that better than XML one (http://www.sonatype.com/people/2009/11/maven-3x-paving-the-desire-lines-part-two/)? XML gives you XSD based hints and believe me - after few years of using maven I can check out nearly every single Apache/Codehaus project and type "mvn package" to build the distro instead of "ant -p" to search for the right target :)

    Grzegorz Grzybek
    ReplyDelete
  7. On the IDEA support, the article you linked to is 2 years old and handles IDEA 7. We're already at 9.0.1 and the Maven support is unparalleled. Even Netbeans' support is superb. Only Eclipse is lagging behind a bit, but even m2eclipse is not bad at the moment.
    IDE support may not have been that great 2 years ago, but now? You'll have a harder time finding decent IDE support for Gradle, Rake, Buildr, ...
    ReplyDelete
  8. @Jeremy Miller
    Well, I'm by no means a .NET expert, but perhaps .NET people need to have a tool for dependency management, for building projects etc. But yeah, that's many tools and not one.

    @Mike Rimov
    Thanks for your advice. In my case it would only partially solve the problem as my pom.xml files tend to be different depending on the project type. I think it shows my Ant background...

    @Doug
    Couldn't agree more!

    @Tim
    We both know people don't take software personally. Ha ha

    @sdb
    I do share your doubts and I am certainly hoping for scripting flexibility from Groovy and not just an XML notation replacement!

    @Grzegorz
    Cześć Grzesiek :), I know Hudson (or other Continuous Injection engines, for that matter) can copy files to places. It's just that this is a bit too simple in my environment when we have multiple locations and each developer has their own; and the requirement is that I decide when to copy the file - not an automated Hudson process. For the record, I solved it with the maven-upload-plugin.
    About the standardization - absolutely!

    @Lieven
    Thanks for your information, I will check it out and update the article.
    I am having serious problems with m2eclipse at the moment (https://issues.sonatype.org/browse/MNGECLIPSE-2110), so I am a bit skeptical about it.
    I will try using Maven in NetBeans though.

    Thanks everyone for reading and your comments!
    ReplyDelete

Subscribe to: Post Comments (Atom)