1.25.2010

Top 10 reasons why Maven sucks...not!

I'm having a hard time understanding all the Maven bashing that takes place these days. Maven has been a real joy for me. It could be the simple fact that I can move from colleague to colleague's project without wondering what ant tasks are available or where the files are. It could be the fact I don't have to configure IDE's anymore, not even for downloading sources. It could be some of my favorite plug-ins. Maybe it's the 250,739 artifacts that are available in three lines of copy paste declaration. There's a lot to love.

I'll admit, it didn't make sense at first. It felt a little too large and I was leery of the potentially restrictive guidelines.  I was also very nervous to commit to the predefined life cycles and directory layout. Within a short period of time I learned a minimal pom provided more function than a minimal ant script and the conventions are actually what enable you to easily add more to the build. After an objective comparison to previous projects I've worked on I determined that while less flexible, Maven's life cycle is both adequate and consistent. Over a few years of use, adequate and consistent has proven to be far more valuable than unique or powerful. This is the build, not the software we're building.  There's plenty of business logic to make our systems complex.  The statement that alternative build tools are more powerful is also debatable.

Let me be clear, I'm not recommending we all use Maven or stop working on alternative tools. I am, however, asking that people give Maven a break. A lot of Maven criticism borders on ludicrous. We're all open source advocates (right?). If you dislike it, you know what to do. If you have a specific need, write a mojo (and share it, or don't). If you're going to speak out, offer constructive criticism. In the very least, try not to make your anti Maven rant based on a string of fallacies. I'm trying not to pick on any specific alternatives or individual, but let's walk though this one item by item:

10. maven corrupts – software, people.
Maven exposes circular dependencies and actually uses the checksums it generates. The software aspect isn't true. Maybe I'm a little corrupted, but I'd consider it more like being spoiled. There's also the expression that power corrupts and with a side note about absolute power. The availability for corruption seems to resonate more strongly with the thought of an entire programming language at your disposal. It's all up to how the power is used.
9. maven uses an archetype(appfuse) and expects that all your projects look like the apache projects – even those that are not webservers.
I'm not really sure what this means. I think Maven expects that your projects look like Maven projects. That's what the convention means. When I looked at appfuse projects, they looked like Maven projects to me but maybe it's a chicken and egg thing, which much like the riddle itself, doesn't have much incentive to solve.
8. maven has only four build stages – compile, test, install, package – if you have a requirement to automate performance testing you are out of luck
There are quite a bit of hooks in the build lifecycle. It was added later, but I believe you want integration test (with pre and post integration hooks). I use a fully automated functional test suite that deploys and fires up selenium. I heard Terracotta was using it to fire up two instances of Tomcat to test fail over scenarios. These aren't performance tests, but I'm sure it's achievable. 
7. maven requires you to have a standard directory structure that is 5 subdirectories deep – regardless of the fact that your project only has 10 java files.
src/main/java . Let's see that's 1,2,3. I think it's a good convention and so do several other alternatives.
6. tasks that are not implemented in maven have to be implemented in ant and need to be integrated with maven – a big nightmare.
The only situation where I've been forced to use Ant was to sign an applet jar to put into a war-file. That unfortunate situation was due to a defect we experienced jar:sign goal. After 10 minutes of trying to get it to work, we found a defect in a jira somewhere. To work around the issue we tossed in the Ant task from the original build script. Since then the maven-jarsigner-plugin has evolved and I'm pretty sure we could remove the ant-run task if we were into fixing what ain't broke.
With that said, it's stupidly simple to use ant-run. You don't even have to go download Ant, nor does the n'th machine that your build will run on have to download it.  Nightmare? I've spent more time setting ANT_HOME and configuring PATH variables.
5. maven encourages you to integrate via binaries – thus making continuous integration difficult
I've used Hudson and Bamboo extensively. Both have excellent facilities specific to Maven. I don't even understand what the alternative to binary integration is. I wish the complaint had a specific scenario for me give a valid counter point. 
4. every time maven builds it connects to the internet (to verify/update dependencies) – building your project without the internet is extremely hard.
Not true.  Maven grabs it once then it never needs the internet except once a day for snapshot, which is for your convenience and can also be disabled. Don't forget offline mode. And you really should take 5 minutes to setup Nexus for a little durability in the event of an internet outage.
Follow up question, how easy is doing anything without the internet? Specifically, how easy is executing code you don't have on your local machine without the internet?
3. maven manages the projects and subprojects implicitly (since there is convention and then there are overrides) – it makes debugging your build impossible.
You can always see the effecive-pom if you need to. It's not very hard to see exactly what overriding is going on.
2. maven manages the project dependencies in its own repository – called the .m2 repository – which is not part of your application folder – thus making it impossible to track and package development environments.
This repository is the local repo. It is not part of your application folder because you probably have more than one project that requires commons-logging.jar.  You can track which files make up your development environment pretty easily. You can also copy them to your development environment or package them for several different environments. Pretty flexible facilities in place for dependency management
1. maven always downloads the whole internet – to keep its dependencies up to date – even though you don’t want to.
Whole internet? At this point I'm trying hard not to reply with sarcasm. I'm not trying to attack the author, just disprove the points. And to address the point, 2.0.9 and up has predefined plug-in versions. They do not update on their own. Anything else it updates because you didn't tell it not to by specifying a version for your plug-ins.

This is the type of FUD you can easily find by doing a Google search for "Maven sucks". Here's why I believe it doesn't suck.

Maven's declarative model allows you to prepare structured data, the primary application of XML, to a system that knows how to do what you want. Very goal oriented. The primary motivation of Ant was to have platform independent scripts for Java which was platform independent. That's why at the time, Ant was hot sauce on fried chicken! The problem for me with scripting language based build systems is that most remain task oriented. Staying disconnected from the tasks required to complete a goal is a great gain in overall usability. Maven stays focused on the latter and offers the flexibility to tweak the tasks when necessary.

In addition to the lack of branch logic and variable declarations, the main gripe on XML is that it  is too verbose. But so is the documentation for an ENTIRE LANGUAGE!!! DSL subsets make it easier but there's still a learning curve, especially if someone gets clever. Learning Maven definitely does not happen immediately, but what you are learning is domain knowledge for the task at hand, build management. Every other build tool I've given the cursory glance to required I learn about its build process in addition to a full language or DSL. XML, for all of its lousiness, is ubiquitous and self describing. Lack of cleverness can be a good thing.

That might all be a moot point since polyglot maven is right around the corner. I'll probably stick to XML because I don't write XML, Eclipse does (so do many text editors, with syntax and error checking to boot). Still I am very interested in the project and using it as my primary excuse to get some Clojure in my life. I do have fearful thoughts regarding what tricks someone will put into their builds using these alternatives, but if it means more people are happy about Maven I'm all for it.


After all, why shouldn't Maven cater to those who crave the additional power. Let's not forget that it was created to help you, not make your life hell. There's an age old expression I learned from Gary Coleman at a young age regarding different strokes and world domination. Some people drive stick and others prefer automatic. I prefer automatic because it allows me to do other things like spam text messages instead of shifting. A manual transmission might just encourage me to speed off the road or get a traffic violation. There's a method to the madness of preventing someone from acting foolish. Think of that traffic law as a metaphor to prevent a rake script gone crazy. I personally feel that when Maven isn't making something easy, it's because it probably shouldn't be done in the first place, not in the build at least. For all other times, there's the gmaven plug-in, but I really really try not to make my colleagues go through the unfortunate pain of learning a new language just to execute my tests or create a custom jar file.  

Is the power of a Turing complete language really necessary to compile, execute tests, package and/or deploy your code?

So to wrap it up, I don't understand the hatred towards Maven. Some people act like it stole their prom date. I'm happy for alternatives like buildr and gradle and realize no matter how great any project is it will eventually be replaced.  I don't discourage people from trying or developing new tools, even though I would love to see those efforts put into Maven instead. Different strokes!  Opinions aside, it is and will forever be a tool that redefined build management and whatever tool replaces can only improve upon the baseline it has established.

But the inaccurate, almost childish Maven ranting has to come to an end! It's downright ungrateful and disrespectful to the people who have worked very hard to provide a free and open source option.  Newer alternatives greatly benefit from the groundwork laid by Maven in the first place including the repository or directory layout conventions. So in the least pay homage

66 comments:

  1. The XML sucks.
    The transitive dependencies suck.
    The basic design of Maven is sucky.

    Sucky through and through.

    ReplyDelete
  2. you talk about how you don't have to "configure your IDEs" anymore.
    Hellooo?
    The plugins are broke. Maven decides when a complete build of Eclipse is required.

    The transitive dependencies of Maven mean that ALL the downstream jars are included in each project's dependencies (even if only 2 or 3 are used). This means, as a new developer (getting up to speed quickly!) how do I see just the jar files a project uses?

    It also means we have conflicts where previously we had none. This is why Maven provides support for "Conflict Resolution" -- a problem created by Maven that can't be solved by Maven.

    This is so funny, from the Maven website:
    -----Begin Maven Snippet------
    "Strategies for conflict resolution need to be pluggable and stackable.

    In some cases, the resolution of a version may be workable, but not ideal. For example instead of erroring out, we may just drop to a different method of conflict resolution if there is no match in the first method (ending up using the current nearest wins algorithm).

    Some suggested techniques would be:

    * use version specification (as defined above, default)
    * use nearest (always get closest transitive dep regardless of version specifications)
    * fail if no match found
    "
    ----- end Maven Website Snippet

    This is a joke. Go back to school, Maven boys, that's NURSERY school!

    ReplyDelete
  3. 7. maven requires you to have a standard directory structure ...

    src/main/java ...

    How 'bout the bigger tree:

    project/pom.xml
    project/src/main/java
    project/target

    and note that project/target is where generated artifacts go ... and since it's _inside_ the project directory, if the "project" directory is what you "version control" (svn, cvs, or whatever) (and "project" is what you should version control, since pom.xml lives there), well, maven pollutes your version controlled source tree with generated artifacts!

    ReplyDelete
  4. I appreciate the comments but there's nothing compelling here.

    XML is sucky? Maybe. Reading your ruby script is worse to me. Everyone in every language reads XML. Hell I could show XML to my fiancée and she'd get it in about 5 minutes.

    Transitive dependencies suck? Really? Why would automatically getting what you need and automatically resolving conflicts suck? Does having an autogenerated report in dependency:tree make less sense than "load lib/*.jar" (pusedo coded)? The problem with Maven pulling in too many jar is usually a symptom of people putting out shitty pom files that include the world even though they don't need them. Just remember you asked for the kitchen sink by not reading the fine print. For them, I'd recommend dependendency:analyze. For you, excludes (or provided as a global excludes). I've seen several open source projects refine their dependencies to minimize the number of required artifacts. Then the problem becomes having to manually include everything yourself. You can't please everyone. I personally don't care to think about an extra 4 or 5 jar files that have no impact on my project in lieu of a ClassNotFoundException in the middle of the night. What's the matter? Don't have an extra 80k to spare?

    M2eclipse is not broke(en), it's usually eclipse freaking out about something. The work sonatype has done on M2eclipse is just awesome and other IDE's deal with Maven natively.

    Did someone just complain about project/target polluting the version control? Wow! Where do you generate your artifacts and have you ever _heard_ of .ignore files?

    You guys are helping me plead my case. Anti Maven rants are rediculous. Be a little more constructive in your criticism.

    ReplyDelete
  5. Not mentioned, which is key to debunking the "standard directory structure" myth, is that you can easily configure and override Maven to use whatever source and target directories for your project you would like.

    If you want your source to appear in just "/src", you can configure that.

    If you want your classes to be compiled to "/target", you can configure that.

    "Convention over configuration" means that if you don't like the convention you can configure alternatives, it doesn't mean you are stuck with the convention.

    ReplyDelete
  6. Nice writeup, mate - it's nice to see some rational thoughts on Maven for a change.

    ReplyDelete
  7. Someone said "The XML sucks."

    Well, maven is already working to be less attached to XML
    http://polyglot.sonatype.org/

    Still, would be possible to do XML, groovy, scala, ruby, java, js, assembly... or whatever you are willing to write a parse.

    ReplyDelete
  8. Nice writeup - and I agree about the xml not sucking (I _HATE_ that argument).

    Xml is really easy to read, anyone can pick up where to do what.

    Good counter on the excludes bit (silly thing to argue over).

    Look - long ago it was make, then people wrapped up "javac" in some scripting language. Then came ant. When people got sick of developers hacking in random, silly stuff into 5000 line build.xml files, some one crafted maven. Now we have maven 2 (and soon maven 3).

    Seems like people are unable to adapt...

    Go maven!

    ReplyDelete
  9. I expect point number 5 is actually that Maven encourages you to only integrate via release versions.

    The problem appears when a number of utility projects (of the type that you generally always want to use the latest version of) are used from number of other projects, and the utility projects are actively developed.

    If the dependees depend on a release version, they won't see the changes made to the utility project when the changes are made - only when the utility has been released and the dependees are (manually) switched to use the new release version. Thus no continuous integration.

    The dependees should instead depend on a snapshot, but this makes them unreleasable (requiring one to release the utility project whenever any of its dependencies is released, and requiring all other dependencies to be updated at the same time to avoid them dependending on stale snapshots).

    I wouldn't mind the latter approach so much if I could sanely automate the step where I start making changes to a release version utility project. I.e. bump the utility project to next snapshot version and switch all snapshot dependees to depend on the snapshot. This is plenty of manual labour at the moment, when there are lots of dependees.

    ReplyDelete
  10. Hello anon guy on point number 5. Thanks for your input and valid Maven discussion point. I had to answer a lot of questions regarding this at my previous shop and here are some of the things I've done to work around it.

    To your first point of dependees not seeing changes made to a utility project, there is the ability to wildcard the version number so your dependents will automatically get the new release. If your dependent has good enough test coverage you can probably get away with this but just like the issue of updated plug-ins breaking a build, you run the risk of a project breaking because something downstream was updated. In short, it's usually preferred to maintain manual control of updating your dependencies, but the mechanism is there.

    In terms of dealing with the churn of utility projects while still avoiding SNAPSHOTS is just to simply release the project far more frequently, incrementing only the build number. Although public projects tend to only have 3.1.3 pushed to central there's nothing stopping you from having 3.1.3.[1-4000] in your internal repo and communicating which specific build version to use.

    Unfortunately, while build numbers are free and disk space is cheap, getting a "release" might be a costly process but that's probably a problem of policy, not Maven. I suffered from this too but was able to convince our configuration management team to eventually let us run releases directly from our CI server for common code artifacts. So you may end up with a lot more versions of utility artifacts, some of which may never actually be used, but it avoids the no SNAPSHOT in releases dilemma. I'm not afraid to say this isn't the most graceful solution but the reality is there's a lot of churn on artifacts like this and that entropy naturally generates some chaos. This worked very well for our scenario.

    I hope this helps and would love to have further discussion in this comment thread about it.

    ReplyDelete
  11. I just love maven! It really helps a lot. mvn:prepare and mvn:perform are so awesome - creating a release build complete with tags in your scm, a updated project page, generated java doc, automatically updated version numbers and so on ... it's a joy :D I'll never want to go back into ant or worse build hell!

    nice post! and I've just stopped trying to convince people that just don't want to get it of maven. you get it or you don't. I've made my choice and as I said, I don't want to ever go back! :)

    ReplyDelete
  12. I promised myself not to comment on another ridiculous anti-maven comment, until I read this.

    "if the "project" directory is what you "version control" (svn, cvs, or whatever) (and "project" is what you should version control, since pom.xml lives there), well, maven pollutes your version controlled source tree with generated artifacts!"

    this is a great one... ever heard of svn:ignore? Don't blaim the build tool because you can't properly configure your source control...
    Ant users put their dependency jars in source control for each and every project without reuse between projects and you make this comment? Priceless.

    ReplyDelete
  13. I have a comment concerning point #4.

    Not in all cases, but in quite a few, I had/have problem that although I am using released artifact, not SNAPSHOT, and I have proper version in .m2 repository, maven downloads this artifact every time. I am not taking about artifacts dependencies, but about itself. The same jar file is picked up over and over again. The worst is, it is even downloaded during 'mvn clean'. Very annoying.

    Other than that I love maven and couldn't possibly live without it nowadays. Ant Ivy is cool, but have default maven targets I can always pickup whatever project out there and start working on it without reading tons of custom build scripts in ant.

    ReplyDelete
  14. hey, please look at me, i'm so cool. i hate java, xml, ejb, sun, oracle, maven, IDE's ... i love python, ruby , haskell and my mac. i hang out all day on reddit with my mates acting as if we are 50-years old bearded guru's. i have never actually worked on a complex project so far but i don't think that's relevant, is it? i have written my own blog in python though. you java boys ... you're all obsolete.

    now serious, i've written a similar post a couple of weeks and the maven haters also showed up at my party. just lake the comments here, they failed to bring up any real arguments. a lot (not all) of the people ranting about maven are just parrots repeating whatever they hear and read from the rock star programmers they admire.

    polluting the source tree, omg, just plain dumb remark from an obvious beginner.

    nice post, btw :)

    ReplyDelete
  15. I truly expected reasons, as I am evaluating Maven over Ant. But as I see it, you're dismissing each "argument" with a wave of a hand.

    I'm not a maven-hater, neither an ant-lover. Just a debate-freak.

    ReplyDelete
  16. Hi Soronthar.

    I'm not trying to evaluate Ant vs Maven in my post. I'm simply trying to shed light on the childish nature of anti-Maven material because it's unfair to the people who are trying to evaluate which build tools to use.

    I did dismiss these arguments with the wave of a hand because they are completely irrational. I've responded to some comments above and I'd be more than happy to take on more discussion with specific pain points of Maven right here in the comment threads.

    Got any?

    ReplyDelete
  17. Thanks for the very nice write up. I have used Maven since the 1.0 releases, and I am very happy to see how it evolved over the years.

    We have successfully used Maven for building a large number of projects, both legacy and from-the-scratch ones. I was able to adapt my POM files to multiple variations of directory structures, or other external constraints, and the end XML file were still preferable to ANT.

    Maven encourages convention over configuration, so if we comply with Maven conventions, then your POM files will be short. But there is nothing preventing you from doing all kinds of customizations to suit your needs. And even in this case, you don't necessarily have to end up with a huge XML file, thanks to the ability to inherit from base POM files.

    By the way, it is not fair to compare Maven to ANT, because these have different tools. Maven is both a build script AND a dependency management system. If you don't want to use Maven, then I hope that you are using Ivy+Ant. If you are not using Ivy or Maven, then you are in big trouble and you don't even know it!

    ReplyDelete
  18. "hey, please look at me, i'm so cool. i hate java, xml, ejb, sun, oracle, maven, IDE's ... i love python, ruby , haskell and my mac."

    you really think a python/ruby/haskell coder cares about maven? Most of them probably don't even know what maven is.

    But anyway, I'm in the gradle camp. Much more flexible and more easily extendable. More appropriate for extending your build system into automation. I am always amused at how the java world is so manual. Given it's ant xml hell legacy and lack of a scripting language standard, the java world lags far behind say the ruby world in automation (like EC2 deployment, auto-installs, etc)

    I am interested in Maven 3 though.... but what is taking so long? It's a build system, not a space mission.

    ReplyDelete
  19. crap I spelled its "it's". For shame!

    ReplyDelete
  20. I've been using Ant for a decade, then Maven 1, 2, now 3. I cherish both Ant and MAven, and they harmonize very well.

    In my current project, we're invoking Maven from Ant (for complex multi-module integration tests) and vice versa. The seamless IDE integration for Eclipse, IntelliJ, and Netbeans saves time.

    A vast ecosystem of plugins means you don't need to re-invent the wheel. Have a look at the Codehaus Sonar quality metrics framework as a point in case, which is rapidly picking up speed.

    Maven 3 is already released in an early access version (alpha 6) and works remarkably well. The latest Eclipse Maven plugin has it bundled.

    ReplyDelete
  21. Nice article. I like maven as well and have been using it for years. I was getting irritated by many recent articles against it. Sure, it has some flaws, just like everything else does! But, it works great for most purposes and I like it very much. I'm looking forward to Maven 3.

    ReplyDelete
  22. I have to admit that most googles you see on Maven are just factless rants on points that if you look a bit harder, either make no sense or would make sense being done differently.
    I'm no Maven expert as I'm not using it professionally, but I've tried to imagine all the types of build releases that I've had to work on in my life and all of them would work with Maven.
    Like a couple of replies to this blog if you just google a bit more (or RTFM) then you'll find the right answer, for example to the scm 'polluting' question then see http://maven.apache.org/scm/maven-scm-plugin/checkin-mojo.html

    ReplyDelete
  23. Hmmm.... I've been using build systems for quite some time - make, scripts, ant. Maven is the first system I found completely incomprehensible and painful to set up.

    Maven may be wonderful as you all assert, but it didn't give me a good first impression. Make and Ant both provided obvious value when I came across these for the first time but I can't say the same about Maven.

    It disturbs me that you are all so dismissive of the (rather large) number of people saying that there are difficulties with Maven. Maybe there's something going on that needs to be addressed rather than chating "Go Maven!"

    ReplyDelete
  24. Make are scripts are simple tools. Ant is just an XML based script to keep Java builds as platform independent as Java is. I am not dismissive of people who say there are difficulties with Maven. Not only did I have to help over 30 projects either get started or convert to it, but it took me a long while to wrap my head around it.

    The bottom line is that Maven is to any build process what Rails is to web development. Harder to tweak but well worth it in the end.

    ReplyDelete
  25. So you have no problems debugging a web application with multiple project dependencies using Maven and Eclipse? Maven and the Eclipse Web Tools Platforms do not work together in my experience and this seems like a big deal to me. Anyone have any alternative experience?

    ReplyDelete
  26. Years ago, when I introduced a bunch of programmers to MAVEN, I experienced the following way of rejection:
    Everything MAVEN is doing, we are already doing it in our own way. Since they have succeeded in projects, naturally, they did a build and after a while most got accustomed to a painful process until they regarded the pain as a 'fact of life'. The pain of changing was obviously perceived as worse.

    When later they were forced by management to change to maven, they continued along this line: They copied the pain from the previuos system to MAVEN and then complained: see, it does not make much of a difference.

    The real advantange begins when you adopt to the new way of thinking that comes with (in this case) MAVEN.

    ReplyDelete
  27. Hi Joseph. Nice post. I remember you helping me out convert existing projects to Maven. I have had a good experience so far with Maven. It's just that you need to know a few tricks and then everything works great.

    ReplyDelete
  28. This is the shittiest software lifecycle bullcrap i have ever seen. Fudging cunts came up with this $hit...

    ReplyDelete
  29. The above anonymous guys seems to have lost his job to not being able to use maven.

    He has no facts just rants. Hell don't make a fool of your self.

    ReplyDelete
  30. Sometimes, I go on the net and search for "maven sucks" to vent my frustration through other's words. Every once in a while I come across one of these "maven is the best, you just don't know how to use it" articles, and this is the first time I've decided to comment on an article from either one of the camps.

    I am currently deep in the lifecycle of maven, trying to add my own stuff to make it do what I need (which also makes it build over 10 times faster than with provided plugins and bloat), it's a serious pain that I would hope nobody has to experience.

    Look how much documentation there is for the methods:
    http://maven.apache.org/ref/3.0/maven-core/apidocs/org/apache/maven/project/MavenProject.html

    Search for components.xml reference...

    Try creating an aggregator mojo, (if you get as far as to finding how to create one.), and try figuring out what it does...

    These are just three things from the top of my mind, I've gone though annoyances like this over and over again for the last couple of days, Maven is pretty much like J Fritzl, and your his manhoe.

    Point is, it's all fun and games, until you need to do more than archetype:generate and add some dependency to pom.xml.

    ReplyDelete
  31. Thanks for venting. I would help you, but you haven't really explained your problem.

    You say the provided plugins are slow and bloated. The default is essentially compile, compile tests, test, jar. Where is the bloat and how did you get it to build 10x faster. Whatever it is you need, I don't know how you avoid the "bloat" of the 6 mojos that execute in the default lifecycle (excluding install, a local file copy, and deploy, a remote file copy).

    The other part is that it seems you are having frustrations with the assembly plugin. Components.xml is described here: http://maven.apache.org/plugins/maven-assembly-plugin/component.html. It took me 1 minute and 5 clicks to find.


    Regarding the poor JavaDoc for the MavenProject object, it's essentially a JavaBean of getters and setters. How well do you want them documented and what are you mucking around in it for in the first place? I bet you don't need to be.

    Ask a question like "how do I do Y" and I'll answer it for you. But generic I can't get it to do all the stupid shit I want to (in the last couple of days) do not make me or other people who can benefit from Maven manhoes.

    ReplyDelete
  32. In principle, a good happen, support the views of the author

    ReplyDelete
  33. I surely believe there is a workaround for each and every problem that comes with using maven:
    - wildcard version numbers
    - tell it not to download the whole internet
    - spent time telling it my project structure is different
    - overwrite faulty transitive dependencies
    - disappearing/missing jars
    - injecting jars into your repo

    Yes, you can do all that. Congrats!

    But I prefer to spend my valuable time coding...

    And writing a simple Ant script to wrap up your code in a jar file isn't really that hard, trust me. And for all the exotic stuff, I challenge you I will do a quicker/better with Ant, while you're writing your custom plugin.
    Isn't that what agile is supposed to be : no frills, just results !

    ReplyDelete
  34. and you didn't debunk any of these arguments :
    http://fishbowl.pastiche.org/2007/12/20/maven_broken_by_design/

    ReplyDelete
  35. I have used Maven 2.x with some success and only a little bit of hand wringing. I use it for a half dozen or so in-house Java projects.

    Now, Maven 3, from my initial impressions of test driving it, is terrible.

    It removes built-in ssh/scp support. Now this must be declared explicitly. Wow, what Maven guru thought this one up? Let's include something important and necessary by default, and then we'll un-include it. What fun!

    The site plugin is broken and they are "working on it." Great.

    Several other important plugins are broken in Maven 3.

    This version is, at best, beta quality and more like alpha.

    From version 1 to 2, the POM model completely changed and Maven was rewritten from scratch.

    Now, going from 2 to 3, I see some serious problems and think 3 is a no go for me, for the time being.

    Maven 2 is working fine. And transitive dependency resolution is awesome. If there is a problem with Maven, it isn't this. You can control which dependencies are pulled in and getting "the world" means that you need some tweaking of dependencies in your POM file.

    The main problem is that the developers seem to have no concept that thousands of people now depend 100% on their tool to build their Java projects. They seem to have a pretty cavalier attitude towards changing it and breaking things.

    I, for one, would like to see better stability for this project. The devs need to focus on "getting it right" instead of rewriting major parts of the application and its plugins. I know, this doesn't conform to certain modern coding precepts.

    But, really, do you want to have to deal with this stuff every time a new major release comes out?

    ReplyDelete
  36. @KOMA

    Yeah, so how do you tell Ant what external jars your project depends on? How long did that custom bit of Ant script take to write? How do you handle dependency versions? How do you handle releases? How much time have you spent writing your own homebrew Ant scripts? Have you ever tried modifying someone else's Ant scripts? How'd that go for you?

    Let's take your "points" one at a time...

    - wildcard version numbers

    Never had to do this...ever, and I use Maven to build a fairly complex set of projects.

    - tell it not to download the whole internet

    It downloads the jar files that your project needs to compile and run. Am I missing something here?

    - spent time telling it my project structure is different

    Yeah, it takes a grand total of about 5 minutes to change the defaults. Real hard.

    - overwrite faulty transitive dependencies

    Again, I have never had this problem.

    - disappearing/missing jars

    Never had this problem either.

    - injecting jars into your repo

    mvn deploy

    Yeah, that was really difficult.

    You're kinda spreading the FUD here.

    You can setup something quicker/better with Ant?

    It takes me a grand total of about 10 minutes to create a new Maven project. That's around the time it takes to have a short coffee break.

    Maven does far more than Ant and works at a higher level. Ant is much more like Make for Java. Both tools have their uses, but for overall project management, Maven is far superior. Ant doesn't even provide most of the functionality that Maven has so I don't see how you can argue that you can do it "quicker/better" with Ant. Because, um, no...no you can't.

    ReplyDelete
  37. dont bother; i am lost for maven, pls go ahead and loose your time; read this first though:
    http://fishbowl.pastiche.org/2007/12/20/maven_broken_by_design/

    ReplyDelete
  38. Oh, hi, KOMA. I didn't know you were lurking here still.

    Maven is generally a time SAVER. If I want to waste time, I'll go try to understand the Ant scripts that were used previously. The build procedures are usually something like, "Yeah, go to this project and execute this, which copies this jar into this directory. Then go to this project..."

    While most of the time my Maven builds boil down to...

    mvn

    Let me address the "Broken by Design" article, because he makes some valid points. But, as a Maven user for a couple years, I don't agree with a lot of what he says.

    "Responsiveness"

    Yes, the first time you have untarred Maven, it downloads quite a number of jar files. Then, the next time you run the command, it doesn't and just executes your build.

    You may also execute an offline build to disable all possible updating.

    Furthermore, the part that typically takes the most time is compiling and/or creating things like runnable jar files (which contain all dependencies in them...very nice) and then running the tests (if you're being a good boy).

    I have a project of around 500 Java files that builds in about 25 seconds. And it is doing a lot more than just compiling the sources. Is that unresponsive? Not to me.

    Perhaps Ant would be a few seconds faster, but that's pretty trivial and no reason for preferring it.

    "Reliability"

    Keeping your dependencies in source control has its own annoyances. You either end up with a bunch of jars with unknown release versions or many different copies of the jars labeled with different version numbers. Then you have to provide some mechanism for selecting among these different versions. This is exactly the annoyance that Maven solves quite well.

    You only do this in the first place, because Ant has no better mechanism. And Maven does.

    "Repeatability"

    Unless there is a "SNAPSHOT" in the name of the dependency, a version number refers to one deployed jar. Period.

    Now, tell me exactly how easy it is to manage a lib directory in your project that looks like...

    SomeDep.jar
    SomeOtherDep.jar
    YetAnotherDep.jar
    AVersionedDep-1-2-3.jar

    Where did these jars come from? What are their versions? How do I build them? How do I know I have all the jars that SomeDep.jar requires? How do I know that AVersionedDep-1-2-3 is the exact same as another jar file with the same name? etc.

    He has some valid points, but, really, this hand-waving over the far future is silly. Ten years down the road...please! That's like a 1000 years in this field.

    If he is that worried about these issues, then the solution is to make a local repository and freeze it. And then use offline builds. Then there is no possible way Maven itself could change behind your back.

    "Dependency Management"

    The transitive dependency management introduced in Maven 2 works great. His solution is...what?

    You flatten out your dependency tree yourself and include the jars in the project's repository, for every project. That is exactly what Maven is trying to prevent you from having to do in the first place. Do you know how much WORSE this is than what Maven gives you for free?

    It seems Ant "just works" for you, and more power to you for this. But I really want to know, how much time and effort have you spent getting to that point? Were you able to get a project up and running, with all the bells and whistles, in 10 minutes, the FIRST TIME you ever used Ant?

    And, hey, if you need Ant, then you can call it from within Maven. ;-)

    ReplyDelete
  39. "And writing a simple Ant script to wrap up your code in a jar file isn't really that hard, trust me. And for all the exotic stuff, I challenge you I will do a quicker/better with Ant, while you're writing your custom plugin."

    Making a simple jar file from project sources is easy as cake in both frameworks.

    Now please tell me how you manage a complex dependency tree of versioned jar files using Ant.

    Are you going to write that script in the time it takes me to simply add another dependency element to my POM file?

    Is there actually a standard way of doing this is Ant? Um, no there isn't. You're on your own or you can use Joe Coders custom ant scripts from his internet site. I'm sure you'll get great support there.

    And regarding custom plugins...most people don't write them, so usually this is a non-issue. And, if you do need to write one, it isn't really that hard. It is like writing a custom task in Ant, which you need to do from time to time.

    Maven provides a certain structure and a set of mechanisms for managing complex Java project. Ant does NOT do this.

    If you want to point to another tool that is better than Maven which actually has the same feature set, maybe I'd entertain your criticisms. But it doesn't exist at the moment.

    If I had to write Ant scripts to replace the POM files for my projects, I'd probably go crazy.

    Yet if you want to replace Ant scripts with a POM file, it usually isn't too difficult.

    That should tell you something.

    ReplyDelete
  40. really - don't bother; I am happy for you.

    ReplyDelete
  41. RE: Broken by Design

    This guy is complaining that a software tool depends on the internet, which is quite dated.

    apt-get anyone?

    Many utilities depend on an internet connection and on certain repositories of data, etc. being present with a certain directory structure. This is not a new concept, nor is it a flawed one.

    I even have an autoconf/make based project that uses wget and cvs to get sources off the internet for various project dependencies. What is the big deal? If the URL of these sources changes or cvs gets switched to svn, I change my scripts. And if the equivalent happens in Maven, you can probably fix it by changing one or two lines in a POM file. If a whole repository goes down for good, then you switch to another repository.

    I kind of look at Maven as having some similarity to a package manager for Java, like CPAN for Perl. It isn't just a simple build tool like Ant for executing local builds without an internet connection. If that's what you want, then Maven ain't it.

    ReplyDelete
  42. Maybe you're too young to remember what the first solutions in the field looked like : http://en.wikipedia.org/wiki/Dependency_hell

    ReplyDelete
  43. @KOMA

    Okay, you've made up your mind. I'm fine with it. It is just an internet argument, after all. But you haven't exactly made too many convincing points here. I'm not even convinced that you've ever used Maven for any significant length of time, which kind of makes your arguments a bit specious.

    Ant and Maven are both good tools. They're just different. I'm not even trying to say that Maven is "better" than Ant in all cases. It just has a much different...er...task. Maven is like a build tool plus a package manager (among other things).

    And I was actually curious how you manage all your deps with Ant. The scripts I have seen for doing this are...interesting and involve a lot of properties files (ugh). What's the best way? How do you do it quicker/faster than Maven? Please enlighten me if you're such an Ant guru.

    I know I won't convince you of the superiority of Maven for project management over Ant, but can we both at least agree that CMake royally sucks?

    ReplyDelete
  44. A generic wiki link does not make a convincing argument, sir. If anything, it supports what I'm arguing.

    Maven tries to solve "dependency hell" for Java projects in a structured fashion, like a Linux package manager, and it largely succeeds. Other things in Maven sometimes annoy me, but the dependency management is usually not one of them. It has some quirks, but by no means is it a fundamentally flawed way of dealing with the dependency issue.

    Java projects MUST depend on specific versions of their dependencies, because there is no preprocessor to deal with the possibility of different versions, unlike in C/C++.

    I don't understand what you think the alternative should be...everyone writes their own custom Ant scripts to do what Maven does?

    Each project stores every last one of its dependencies in its source repository?

    I thought we went through that already and determined that this sucks even more than you think Maven does.

    ReplyDelete
  45. LOL@ "when Maven isn't making something easy, it's because it probably shouldn't be done in the first place"

    How convenient, so Maven is the "definition of perfection"? Can I play this game too? "I personally believe that if Ant doesn't make something easy, it shouldn't be done at all!"

    By the way, you don't give a RATS *** if Maven can be configured "not to connect to the Internet", or even if it "only connects once" when you're working in a SECURE environment specifically designed not to allow Internet access. Just another stupid assumption made by fools with the arrogance to assume they understand the needs of every development environment on the planet. And no, I'm not wasting my time setting up an "offline" site for the Maven rubbish. I have real work to do!

    ReplyDelete
  46. Maven is fully moist.

    ReplyDelete
  47. Why Hibernate moves away from Maven ! Now tell me the Jboss/Hibernate guys are only doing toy projects : http://community.jboss.org/wiki/Gradlewhy

    Quote : "The release plugin is completely worthless." ... "But there is a problem with making GoodGuidelines into AboluteTruths... they seldom are." ... " "inherited pom data" and "module aggregation" into a single file. I think it is an awful idea"
    and so on and so on...

    have fun on the "serious" projects, guys!

    ReplyDelete
  48. For me,

    the issue with maven is that it's hard to understand what's going on under the hood. I have worked with some maven archetypes from some remote repository and build times for a simple hello world app (one JSP file, no java) takes + 30 seconds. That should have been done in 100ms. Specialyl when you use such a remote repro, and do a hello worl and you need to download 30 minutes of 'stuff' (I am at 512Kbit) then you wonder why it's all needed.

    so in general, to much to read and understand, and 'maven for dummies' frontend to configure some of the needed items to speed up compilation. Maven assumes you will read a maven book and learn it like the holy bible.

    ReplyDelete
  49. Maven's problem is that Maven was originally created for people who apparently couldn't handle ant. Ant, when using a base master build file with macros, becomes a very easy system to use with individual build files being no more than a classpath statement per project, and maybe an override task for a specific step. For a 40+ component project with hierarchal dependencies, my individual ant build files averaged about 6 lines each.

    You can't touch that efficiency in Maven.

    Another problem I have with Maven is dependency mapping. As noted above, it becomes a nightmare when you have hierarchal builds with incremental versions. With Ant, that's not a problem, as this is one of its core competencies.

    I also don't like that Maven pulls from a repository that is outside my source control system. It's yet another thing to maintain and manage. I personally prefer to have known and controlled third party artifacts in my build, and I don't buy the "I am unsure what I have when I go to a colleague's machine". If you are unsure, you don't have good SCM in place. My projects generally require pulling 2-4 repos from SCM, and then running a single build script. 1 of those repos is the Ant master build project, which is shared across all projects, and can even include ant itself if you like, solving the problem of "which ant version are you running and with which plugins".

    Additionally, the last 6 major projects I worked on were all entire system builds - many components comprising a system built as a single version and created as an installable/deployable unit. I don't mean a WAR file either, but the entire application server, as it was modified as well in 2 projects. Doing this in Maven is like removing impacted molars by yourself.

    While you don't understand the Maven bashing, I don't understand the need for Maven at all. As you state, I'm not in the business of fixing what's not broke. Ant is not broken. Maven is.

    ReplyDelete
  50. I'm pretty knowledgeable with ANT and I just can't get through with using Maven. I'm a professional services team member and occasionally I need to build an add-on component for our platform. trying to do that in maven requires a lot of changes since I'm not interested in building all the dependencies, I have their jar files locally and I'm just trying to build the add-on. so I need to go an change my deps to scope system add the full path and even then it refuses to build due to artifactItem is not picking up my system scope deps and cannot copy them. That was just one hurdle I faced with Maven that would have been a no brainer to fix with ANT. not to mention all the download I had to wait for on the initial run, and some more artifactItem references that could not be resolved. This is my second or third time trying to get Maven working without success, giving up forever.

    ReplyDelete
  51. I have to comment re: "Now please tell me how you manage a complex dependency tree of versioned jar files using Ant."

    is there a problem with just putting the jar files in a directory (to "manage" them)?
    And then the version is in the name.

    So, finished, right?

    Why would I create a jar repository (introducing the possibility of very tricky bugs (yes it has happened on a large project at a company where I worked)) when I can just put them in a directory?

    The entire Maven philosophy is junk. I could go on and on. Maven is destroying modern Java software development. As far as that goes, Spring is also a dopey and bloated piece of shit. Hibernate/JPA is junk (I used to think otherwise, but bitter experience has taught me better).

    ReplyDelete
  52. Actually, it occurred to me that the poster of "Now please tell me how you manage a complex dependency tree of versioned jar files using Ant" actually thinks this is somehow necessary.

    Nope. Not necessary.

    Maven is a broken solution to an invented problem.

    ReplyDelete
  53. Maven (with transitive dependencies) hides direct dependencies (a so called "feature" of Maven).

    With transitive dependencies it is no longer possible to look at a module (or dependency if you prefer) and determine its direct dependencies.

    This actually has the effect of decreasing modularity, as the precise dependencies are no longer specified (just tossed into the transitive Directed Acyclic Graph).

    This is why a (really bad) plugin is necessary that breaks Eclipse's default build.

    Example:

    Without transient dependencies:
    Let "A->B" indicate "A depends on B".
    Suppose
    A->B
    B->C
    C->D

    Suppose also that A->D.

    In maven, using Transitive dependencies:

    In A's pom:
    A->B

    In B's pom:
    B->C

    In C's pom:
    C->D.

    By only looking at the poms, it is not clear whether:

    A->C?
    A->D?

    Now, why would you throw away this information? How on earth could it be an advantage to no longer be able to determine the required dependencies? I posed this question to the Maven fanboy we had at work, and he continued to insist that the (well nigh useless) graphical tool was in fact showing me the dependencies. You see, he really loved the Emperor, and marveled at his new clothes....

    ReplyDelete
  54. Hater's gonna hate!

    Your fanboy should have told you to use dependency:tree. Then you'd know what you are using and from whence it came.

    Silly Ant user. Your build is so special isn't it?

    ReplyDelete
  55. I don't want my developer's using maven. It introduces dependencies in code. It brings in code with licenses which are unknown.

    In short, it looks like a tool made for the Java community, by the Java community, for people who love lots of Java frameworks.

    Frameworks = bloat. Just like "process" in a company, "frameworks" should be limited to the absolute minimal amount to get the job done. Not frameworking for frameworking sake. Frankly, after years of programming with everything from C++, to embedded systems, to big Java backends, I believe tools like maven are solving problems which simply shouldn't exist.

    If you don't know EXACTLY what libraries you need - you shouldn't be using them. At least don't come to my shop with them.

    Bring a JAR, tell me the exact version number, and move on.

    ReplyDelete
  56. Regarding "XML sucks" argument I must say that XML really sucks for build tool. For example once I wanted property with random suffix. You can't do that in Maven (2). Hell you can't even include properties file. I'd rather see it as DSL (Groovy, Scala, Perl, ...). They exists, I know.

    ReplyDelete
  57. Another thing is that Maven (2, 3) is great security hole. Now I'm not trying to sound like security guru. But it really doesn't matter how much effort you put into securing your system (anti-virus? useless). Man in the middle attack on LAN is trivial. Since Maven downloads half of universe in every run it's very attractive for doing whatever a bad guy on LAN want on your computer. And all that's left is to run your unit test for example. I don't care how you install software but re-inventing wheel (package manager) with no security at all is clueless. There is a draft but it seems it'll take another 10 years to implement it...

    ReplyDelete
  58. Edit to my previous post: Here is the draft: http://docs.codehaus.org/display/MAVEN/Repository+Security

    Maven as a package manager piece of crap.

    ReplyDelete
  59. Maven is is horrible and freaking irritating as hell. What a waste of time, just use Ant.

    ReplyDelete
  60. My impression of Maven is that it was designed with a ton of defaults to hopefully not require a lot of configuration to get a build working.

    Which seems to work for smaller projects, but then again, maven is overkill for a smaller project, which can get a basic ant build up faster than learning "The Maven Way" and writing out the dependencies.

    The operative problem with maven is that it doesn't seem fundamentally designed and defaulted to a host of large-scale project problems, and the resulting configuration to make maven do what you want it to do then makes it seem like you might as well do an ant build anyway, since the configuration is equivalent in xml size, is more explicit, and you're not constantly wrestling the unknown defaults.

    The only real good I see out of maven is encouraging all the projects to standardize jar naming conventions, and get them in a central repositories. A lot of that infrastructure is nice.

    But maven the actual tool is not a good tool. Even if you fix it, you are suffering the problems of multiple conflicting documentation versions on google for someone looking for how to do something.

    Hopefully a new project comes along that will do this better.

    ReplyDelete
  61. Another thing. In year 2011, Maven doesn't support concurrent instances on single machine. So you could end up with race condition when downloading & using artifact at the same time. It may not be problem for you sitting at your desktop, but for continuous integration it's a big problem. Yeah I could set up local repository for each instance. But why?

    Maven sucks hard! Maven designs is poor.

    ReplyDelete
  62. excellent example of how maven simplifies your life :

    http://stackoverflow.com/questions/6352208/how-to-solve-plugin-execution-not-covered-by-lifecycle-configuration-for-sprin/6475103#6475103

    ReplyDelete
  63. Hello all,

    I have been working as a developer for quite some time now so I have used ant and maven.

    I dismissed maven when I typed 'mvn clean' and it connected to the network to download some dependencies.

    I fixed this by typing:

    cd /opt
    rm -rf maven

    ReplyDelete
  64. Yep yep. And all you wanted was to delete the build dir. Principle of least astonishment goes straight out the window with maven.

    Also there should be a competition of "How big is your .m2" directory?

    ReplyDelete
  65. Maven is not transparent, their error message most of the time is not accurate, many developers do overly unnecessary complex things to it. Its almost impossible to explain to managers who and what causes errors in Maven.

    ReplyDelete