Maven2 detractors are right

There is a crisis going on within the Maven community. Some think that Maven has become something too complicated, too difficult to maintain and evolve. I say it loud (even if few people care): I fully support these detractors.

Being a Maven2 users on a daily basis, I’ve been looking for a replacement for a long time. I tried Buildr (wasn’t convinced). I’ll give a try to Gradle soon. The reason? Maven is the kind of tool that solves a lots of problems but invents new ones. At the end of the day, I’m not sure it helps my team to be more productive.

Why? Maven relies on two lies:

  • First lie: Transitives dependencies.
  • Second lie: Universality.

Transitives dependencies
This will never work. Bad poms, library conflicts, runtime dependencies… At the end of the day, it’s better to explictly declare all dependencies. Relying on implicit dependencies is a short term gain. A build system is here to stay so it shouldn’t rely on short term gains.

You can build with maven, and run tests, and integration tests and deploy, and generate reports, and, and… Stop, stop, this is already too much. Yes the plugin system is a nice to have but it tends to make users think everything can be done within Maven. Me included thougt that I should put as much as possible in my pom.xml when a simple ant file could replace in a very reliable manner a bunch of buggy plugins. Maven should do one and only one thing right: build jars from sources.

Complexity is ok, lies are not
For most people, it’s hard to accept that a system too powerful is dangerous for the users. I think a system can be powerful. It can even be complexe but it shouldn’t make users believe in lies. Same thing for Spring. It’s powerful. It’s complexe. I like it. But it makes people think that JavaBeans is a good design.

25 thoughts on “Maven2 detractors are right”

  1. I get what you’re saying but your arguement is flawed. First, that transitive dependencies are short-term gains only is wrong and leads to your disappointment. Yes the public repositories are scattered with POMs that are invalid or incomplete, and perhaps there could be better metadata and support for native libraries and other languages but transitive dependencies provide a mechanism for maintable builds. They do this by relieving you of the burden of managing the dependencies of your dependencies. Imagine you have a massive Spring project that uses all the popular frameworks of the day (Hibernate, JPA, Struts2, etc) of particular versions which have their own secondary dependencies of varying sources and versions, without the POMs for your primary dependencies you have no implicit information as to which secondary relates to which primary. Imagine you move on and 2 years later someone else is tasked with updating the project to the latest version of xxx. An additional benefit is that using the dependency resolution mechanisms in Maven only one copy of each dependency-version is included in your final output. Transitive dependencies provide long-term gains as the quality of metadata in the repositories improves for legacy (pre-maven2) projects and new projects are added “the Maven way”.

    Maven is trying to do one thing and do it well: be a framework for building. You have gripes with particular plugins, that’s different. The compiler plugin does its job of compiling java sources pretty well and the jar plugin too.

    IMO a less frequently mentioned benefit of Maven over an ant script is that there is no consistent format for ant scripts. Maven scripts all look pretty much the same, they have a format defined by a DTD. Once you have passed the inital, steep, learning curve you will be able to quickly work with any new maven build and be able to determine its contents.

    I’d be interested in a few more detailed examples of where you think a simple ant script would be better πŸ™‚

  2. Thank you @James for your comment. That’s exactly the lie I’m talking about: “transitive dependencies provide a mechanism for maintable builds.” I prefer to say “transitive dependencies would provide a mechanism for maintable builds if it was not flawed”. That’s the difference between the goal of Maven2 and the real life.

  3. Its not sin to use ant scripts with maven, maven has good support for it. You should not use it to build war and ear, but if you need something not supported than use ant.

  4. Having used ant and maven extensively, we switched to gradle some time ago and have never looked back.
    Better documentation would be nice, but the community is quite responsive and that helps.

  5. you can execute ants script on given phase, like package. in one project i build with and some exoctic archive and ant works great here. Now i can forget that i have ant script, it doesnt matter if i do package,install or deploy. it will always execute and i think thats cool.

  6. >> Maven should do one and only one thing right: build jars from sources

    I could not disagree more. If all you need is a declarative-compiler-invocation-tool (aka Ant), then why did you even consider maven?

  7. I am a bit confused by your post here (Disclaimer: I am on the Maven PMC).

    Talking about transitive dependencies, I agree you may end up in weird use case that you will have to deal on a case by case basis. On the other hand, knowing your dependencies is a must have anyway. If you configure your dependencies metadata with optional exclusions, there’s nothing that the tool will actually prevent you to do. Besides, if you have a lot of modules internally, using the transitive dependencies mechanism with good metadata will greatly improve the management of your project.

    Regarding universality and complexity, nobody forces you to use the extra features that some plugins offers such as site generation and integration tests. If the only thing you want to do is compile your code and generate jar files, I am not sure to get how hard this will be to achieve this with Maven.

    That being said, I agree that Maven has a higher learning curve but it has greatly improved with the books that have been written in the past months. Nothing come for free I guess πŸ™‚

  8. For me it still comes back to one issue, Maven is the first and only tool I’ve used so far that allows me to check a project out of source control that a co-worker has been working on, and there is ONLY source in the repository, and have it build first try, something that sometimes took DAYS using Ant.

  9. I am a long term user of maven and ant, however I have increasingly found that any xml driven framework, whether maven, ant or otherwise, presents many problems. I have a great deal of respect for maven and am definitely not a detractor and acknowledge that it has a use on many projects.

    However I’ve always thought there should be a pure java alternative and the only projects already in existence all seem to be abandoned or works in progress. This prompted me to release a new open source project called ProtoJ, whose main goal is to integrate a project use-cases both horizontally (the build phase) and vertically (from build to execution).

    And it’s that vertical slice that I’ve found that cannot be done if you base your project on xml foundations, for example it can be very difficult to access your version number from a running application in a clean way. If you are interested, then take a quick look at the features and links below:

    * support for aspectj with no other software required

    * support for automatic dependency management with ivy and maven, optional transitive dependencies

    * support for managing multiple configuration profiles across the network

    * support for property interpolation (replacing references in properties files)

    * support for signing your artifacts with gpg and publishing to a repository

    * velocity integration means even your text files can integrate with your project API

    * ProtoJ is easy to learn, you only ever create a single pojo

    * traditional directory structure with lib/ directory

    * licensed under Apache License, Version 2.0

    * tested on unix (Mac OS X), Linux (Ubuntu) and Windows (XP)

    * Java 5 and Java 6 binaries available for download

    real world example:

  10. @David
    There are a lot of reasons one might call out to build scripts. For example, I call an Ant script to build a custom JNLP distribution or to run database integration tests.

  11. Maven has their weakness, but it’s the best tool (until now) for their job.

    From time to time I have to fight with a pom.xml, but I will stay with it until a better solution arise πŸ˜‰

    Maven’s dependencies management and build system are very good, not perfect, but very useful.

  12. @Mike You’re right that this is the nice thing about Maven. Still, when pepole rely on a private repository, which is considered a good practice, the whole thing might stop to work for you if you don’t have access to this private repo.

  13. @Stephane I understand that nobody forces me to use Maven for everything. And I don’t. I mean that people are lured that it can be used for everything more or less connected to the build process.

  14. I think you wrote this just to drive traffic, and because these arguments are plain retarded. You act like.. that using ant you will not have to know your dependencies, and they will magically appear because your using ant. 2nd, If all you want to use maven is to build, thats all you have to use it for. Stop being a moron. You’re fired

  15. @Hohonuuli These are perfect use of ant script. Works better than custom plugins in Maven IMHO. My question was: why use Maven to launch the scripts ? It reinforces Maven in its universality lie.

  16. @Stephane Exclusion mecanism is the proof that transitive dependencies is flawed. I have to add more and more exclusions as time goes by. However it has to be clear that I still use Maven2. It’s just that the effort to KISS is too high.

  17. @David
    It’s not a “lie” to launch Ant scripts from within Maven: in many cases it’s imminently practical, particularly when they’re (the Ant scripts) tied to a step in the build process. Why *wouldn’t* you want an integrated build process?

    Whether or not Maven is “good”, or you like it, the arguments presented aren’t very good arguments against Maven.

  18. I personally think that multiple source roots can be a problem especially for
    large projects. I’ve worked in teams where there are at least two dozen or more
    child projects, where each produces a jar. This isn’t a problem per se, but
    you tend to end up with classes from the same package scattered across several
    jar files.

    And once you’ve gone down this road it’s very hard to fix, namely
    because chances are that deployment requirements depend on the particular
    blend of jar files. You know when your downstream deployment requirements
    have affected your upstream build decisions when a developer asks: “where
    is the deployment guy, I need to know which child project I can type my next
    line of code in”.

    Worse still – and this is the elephant in the corner for me – once package
    scattering occurs, the potential for domain driven design is greatly reduced
    because namespaces are no longer implemented by the now redundant language
    level package concept, but instead by manipulation of the filing system into
    “components”. And an important part of developing a ubiquitous language for
    domain driven design is the ability to group related domain objects into
    namespaces – say I πŸ˜‰

    Another solution is to place emphasis back on the package by using a single
    source root and leave it to the deployment use-case to decide how the class
    files and resources should be carved up into jar files – this is what ProtoJ
    does using simple ant filters. And of course it’s much easier to rename/delete/merge
    or otherwise refactor packages than do the same with source roots.

    On the other hand a very good reason for using multiple source roots is if
    your project is a market place of architectural components to be shared by
    other projects in a large organization. But I view this as the exception
    rather than the rule and one that can easily be dealt by other means as
    indicated above.

  19. @David
    Come on πŸ™‚ I can’t buy that. The argument that it is flawed because Maven provides a way to customize is quite funny.

    Exclusions are there because metadata are sometimes wrong. Do you know a transitive dependency mechanism that works properly in all cases on every project? It probably does not exist, which is why exists in the first place.

  20. Anyone who gets through the first page of maven getting started and STILL uses Maven is a sucker.

    Put your repo in THIS format. Wow what does that say about your tool? That my build has to be in THIS format. Ever here of You cant even make an ANT template? It says your a gimmick, and as quirky as ANT is Ill hang back while you change the world.

  21. @bob
    It’s not “your” repo, it’s “the” repo. There’s a difference. If you want to be able to grab 3rd party dependencies in a unified way, you need some sort of standardization. Besides, who cares? I mean I don’t give a crap about the repository format, all I want is that I can download/install/use some 3rd party lib without having to download it myself and copy it in some location (jars in the source code repo anyone?)

Comments are closed.