The use of Maven cripples the mind

I have used Maven 1.1 and 2 for the last 1.5 years, but it always am boggled by the utter complexity of the tool. There are a lot of good aspects about Maven (dependency management, standard tasks etc) but these advantages don’t weigh up to all the problems. For example: If I want to create a war and an ear, I need to create multiple projects. How stupid can you be?

With ANT (used it for more than 5 years) I would add an extra target and I’m done. I can do whatever I want. That is why I add all functionality to my script so I get a one button release. So even though some stuff in Maven is much easier to set up, in the end I’m spending much more time configuring maven than it would take in a different tool like ANT. Other problems of maven are badly documented tasks, tasks that break for unclear reasons (ANT is as solid as a rock). My bet (and hope) is that Maven in a few years is seen as something bad like EJB 2 and replaced by modern build environments like GANT, Rake, Raven or Build’r. Build languages that are just internal DSL’s; so you can switch to the full blown language without needing to create plugins and it also prevents programming in XML (XML was a bad choice for ANT from day one).

22 Responses to The use of Maven cripples the mind

  1. Benoit d'Oncieu says:

    Hi Peter,

    Nice blog entry!
    I completely agree with you. Having been a user of Maven 1 a long time ago, I recently started to work on small to medium projects using Maven 2. It is really frustrating to have to spend so much time on google just because the documentation of Maven is so rubish. I do really hope for the sake of Maven that they stop bundling documentation inside their projects and rely on online wikis instead. It is so easy to update a wiki as opposed to having to do the following: Checkout the project, find relevant page, update it using the project’s preferred document langage, publish web site. Also, only the commiters of a project can do that…

  2. Carter says:

    Totally agree. Maven is maddening to use as an ant replacement. In my personal projects, I tend to use it for dependency management and that’s it.

  3. Carter:

    In that case you might consider checking out Ivy. Ivy does just
    dependency management and plugs into Ant very nicely. Ant + Ivy
    gives most of the best aspects of Maven without some of the ridiculous complexity. Note that Ivy does still have a learning curve, but not too bad since you’re still leveraging your Ant know-how.

  4. I’ve been hating maven2 the first couple of months. Now, after 9 months of heavy maven use, I start to embrace it. It’s very true that it’s very complex, badly documented. Also, as soon as I need to do something harder, I just run another ant script (but started by maven).

    I’ve learned to just NOT use maven for every problem. If you use the basics (packaging, running tests, deploying and reporting) it works perfectly. As soon you do something harder (like deploying an extra ear), I just fire up some extra ant to deal with that.

  5. Max says:

    Ever tried to use an assembly for your problem?
    By the way: my hope is, that Maven takes over the world and I never have to fiddle with an ugly Ant script again 😉

  6. Hi, I completely agree with you. I have tried maven several times and always reverted back to ant scripts because it is more powerful. I think the way of the future is to just take a simple programming language, enhance it with build-related functionality, and use this. Rake and scons are two good examples.

  7. Slim Tebourbi says:

    I completely desagree with you,
    i think that you said that because you haven’t understand the maven’s philosophy and can i guess that when you said “I can do whatever I want” with ant.
    see :

  8. Mike says:

    I disagree. You need to learn how to use Maven, and you need to drop maven 1 in favor of maven 2.

    If you are still using ant, then you have learned nothing from your time with Maven – convention over configuration. If you keep using ant, then you keep writing and maintaining this awful script that you have to carry from project to project and teach future developers what targets to use for what.

    You need to stop using maven, and LEARN to use maven, then go back to using maven.

  9. pveentjer says:

    I need to learn how to use maven…. the more I learn about maven, the more I dislike it. I like the convention over configuration stuff, but when I need to do a lot more work to get it right, the convention wasn’t correct from the first place. Creating multiple projects for doing simple stuff like creating a war and an ear is ridiculous and leads to much more complexity than just adding a single target.

    One of the many customization I have been fighting with is the aspectj bytecodeweaving that takes place when compiling the code. For normal testing purposes I don’t want the bytecode to be modified, only when I needs to be run on the server. So the consequence is that in the unit tests you need to deal with unwanted aspect-code that demands stuff (like a transactionmanager for example).

    In some cases I’m forced to use Maven 1. Maven 2 is unstable: plugins that breaks, repositories that get corrupted (last week my own repository got corrupted and a repository of colleague (different project) and plugins that are part of maven like the war plugin) could not be installed. Only after deleting the complete repository and downloading all the entries, the problem was fixed. Another ‘cool’ plugin is the release plugins; last time it costed me and another developer a lot of time just to make the freaking release! I never had these problems with ANT.

  10. Clark C. says:

    If the context you are developing within is a single application with special needs and lots of personal attention, then Ant may have its place for you. My experience with Maven is that it does have a high ramp up price in initial learning and configuration. However, if you have a software shop that (a) has more than a handful of developers on staff, (b) builds a number of different applications (c) plans to keep solutions around for a while, and (d) is largely or exclusively a Java shop, then Maven is likely a perfect tool for your needs. The ability to standardize build operations and configurations to a minimal and clearly defined set is worth its weight in gold. Ever get asked to pull the code on an application that was put into production a year ago and now needs some maintenance- and the whole team that built it is gone? If Ant was used, good luck figuring out which target is the right target to build the successful app. There’s probably only 20 or more targets in your build file, right?… Likely spread across thousands of lines of XML if the development took very long to complete. With a little work you can start to understand which of them are dependent on the others and start guessing which of the highest-order targets might be the right one. If Maven2 was used, all you do is call the package, install or deploy goal depending on what you are wanting to do. All of the relevant bits that cause chaos in Ant files end up being clearly identified and externalized in settings files (and checked into source control in series) rather than built into parallel Ant targets that you must intuit the difference between weeks months or years later.

    And that’s just the maintenance/build/deploy scenario, there are lots of others during development where Ant’s unlimited options can make finding and managing minor changes to the build script a nightmare- especially across team members.

    From a configuration management perspective, Maven has Ant beat hands down in my book, and that’s before you even consider the benefits of dependency management.

  11. Project Avenger says:

    In my workplace, the manager responsible for introducing Maven 2 in critical, interlinked projects has been fired and we’re trying to implement Ant.
    Maven offered complex and revolting hacks for trivial tasks, permanent nonreproducibility of builds, and many person-months spent unsuccessfully sorting out dependencies.

  12. AlexF says:

    I think your anaysis may be wrong.

    Perhaps your mind was crippled already (maybe from duplicating and maintaining your ant scripts across all your projects?) so that you couldn’t get into maven2..?

  13. Tristan says:

    yeah..personally i just leave THE target as default…or i put a usage as the default. now when the guy across the hall has to deploy my project he types “ANT” thats it. no reading xml.

    thats just me though.

  14. Franz Garsombke says:

    Don’t you get it…convention over configuration.

  15. pveentjer says:


    I agree with you. My (G)ANT projects have documented public tasks that are documented. So ‘gant -p’ and you get the list of public tasks.


    What is there not to get? Maven can’t possible run every projects (with all technologies) without extra configuration. Extra configuration doesn’t have to be bad, but if it is more complex/unnatural than a more direct approach, the convention is not well chosen.

  16. Tero says:

    First, I have not extensively used Maven 1 or 2. I have done a few shrink wrapped builds on it and that’s it. However, I think I get the philosophy behind Maven.

    I have been restructuring the build scripts we have at my work bit by bit when ever time allows. I have been using Ivy and Ant to do that. The simple recipe that I use is to use Ant macros, and imports with Ivy to create modular builds very much like with Maven.

    The result is that your common case of building things becomes very easy. Usually less than 10 lines of XML for just about any module you can imagine. At the same time, you are absolutely in full control of everything from top to bottom. There is a high degree of reuse and your whole stack of Ant scripts is very compact and manageable. But it just would not work without Ivy.

    Ivy is a pretty amazing tool that you can leverage to get the best things out of Maven, and do all the things you do with Ant. The number of projects in a typical build that I have is somewhere around ten or more. Ivy tracks all my project dependencies, manages the build tree, and all I have to do is to watch it do its little dance, and it works like a charm.

  17. Come on people!

    You guys also think scripting is better than object orientation then?
    That is exactly why Maven is simply the next step compared to Ant.

    I agree that some plugins could definitely use better documentation, but that doesn’t make the framework bad.

    Bottom line is that a predefined lifecycle (call it workflow if you want), is definitely the right choice to keep your builds on track.

    @Project Avenger:
    If you are struggling with dependencies between your own projects, whose fault is that in your opinion? Maven’s or maybe your own? Firing the guy that introduced a decent new technology is just too easy. The rationale behind this is exactly the same as why everybody sticks with IBM shit: nobody will blame you for choosing IBM, even if it is the worst piece of crap software you can get. Even if things go wrong (and they will), nobody will say a thing. But if you would have chosen Geronimo, and shit would hit the fan, you would be the bad guy..

    You have got to think about code structure, dependencies between your modules/projects, layers, reuse, aspects, etc.
    Otherwise you end up with one big chunk of monolithic code that simply can not be built separately and is impossible to reuse as components. Ant does not promote component-based projects as well as Maven does. (This does not mean that it is impossible to create well-structured projects in ant of course).

    If you understand the Maven philosophy, you will get lots of things for free and it will make your life easier.. Even for more “difficult” tasks.

    If you think your build is special, think again and you might see that your code and modules could be organized better. Maybe you need to split some modules. Maybe your business code is tangled up in an EJB instead of implementing it in a delegate and use the EJB as an access point. Etc.

    “For example: If I want to create a war and an ear, I need to create multiple projects. How stupid can you be?”

    Excuse my french, but this is utter bullshit. The whole idea of maven is that one module should produce one-and-only-one artifact. A project usually consists of multiple modules, which all produce one output: if you want to package your webapp in an ear, that is a new artifact, hence a new module.

    I am certain that if you read up on it, you will enjoy Maven..

    Good luck and happy hacking!

  18. pveentjer says:

    @Jo Vandermeeren

    I don’t see why scripting should exclude object orientation, so the comparison you make is broken. Groovy is a scripting language, but it certainly is object oriented. But this is another discussion.

    >> Bottom line is that a predefined lifecycle
    >> (call it workflow if you want), is definitely
    >> the right choice to keep your builds on track

    If the life cycle is what is needed, it is great. But as soon as you start throwing in all kinds of technologies (like AspectJ) you’ll get into problems sooner or later. The amount of time to change Maven to allow these technologies is (in my experience) larger than setting it up from ANT.

    >> Excuse my french, but this is utter bullshit.

    We both agree on the fact that multiple projects need to be created. You think this is a fine approach, I think it is a bad approach because the structure of the application is complicated. The structure of a single project with maven is much simpler, but the overal structure of all projects and subprojects gets more complicated. A similar discussion can be found on extra language features in Java:
    – adding them complicates the java code
    – not adding them simplifies the java code but complicates the overall design because you need to introduce heavy weight solution to fix lightweight problems.

  19. Project Avenger says:

    @Jo Vandermeeren

    We don’t have a particularly special build, nor particularly monolithic applications, only about 10 pretty similar J2EE application suites, containing 5-10 modules of their own, 10 -15 own libraries, and 30-40 external libraries
    Each of the application and library modules needs to be a Maven project/artifact: fair enough, except for the massive duplication of information between and within POMs.
    But now instead of trivially packaging the hand picked dependency jars in appropriate “lib” directories in our version control, we are at the mercy of Maven’s dependency resolution.
    For example, there are classpath races between multiple obsolete JAXB implementations in randomly named jars, and we cannot put dependencies under version control: it is not a matter of modules and aspects and layers.

    Who cares about getting useless things for free when feats like stripping version numbers from jar filenames (by client request) or running a custom code generation tool are major hacks?
    Who cares about the “Maven philosophy”, when tool documentation is ridiculous and gigantic bugs are left unfixed for years?
    And what is the philosophy behind fundamentally unusable features like snapshots and dependency exclusions anyway?

  20. den Danny says:

    That’s why we (a 300+ programmer/100+ JEE projects shop) use Maven – because we DO NOT want you to do ‘whatever you want’ – we want you do to what we want (had you been working with us – which luckely for both of us is not the case)

    happy hacking 🙂

  21. pveentjer says:

    You do whatever Maven wants.. not what is the best solution.

    A few weeks ago I had to set up a sub-project under Maven 1 (yes I know, but the quality of Maven 2 still wasn’t trusted by the team). The amount of subsub projects that needed to be created to deal with all the artificact sharing is ridiculous.

    xxx-common (depends on xxx-dto)
    xxx-web (depends on xxx.common)
    xxx.ear (depends on xxx.web) (depends on xxx.common)

    At the moment there are 5 projects to create 1 freaking ear. This maybe is acceptable for you, but not to me. And if nobody looks serious at solutions, and compare the pro’s with the con’s, we would still be using EJB 2.1

  22. Ansury says:

    Sorry but you can keep the “Maven philosophy” and all the assumptions that come with it. The only case where it may be useful (perhaps) is in an environment where you need to maintain very strict and standardized control over your build process, dependencies, and so on. (I’m not so sure I’d like to work in such an environment.)

    But realistically, and for small/mid sized projects, IMO Maven is just massive overkill, providing “free” features that small sized teams don’t even have the resources to fully take advantage of anyway. When it works, perhaps you’re happy, but when there’s a problem–uh oh!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: