Maven Does Not Suck . . . but the Maven Docs Do

Discussions

News: Maven Does Not Suck . . . but the Maven Docs Do

  1. I'm not going to go into the whole Maven debate, but suffice it to say that I'm a strong proponent of everything best practice, and, to me, Maven is an embodiment of best practice. By this I mean that Maven is built around a specific best practice build methodology. Note, I said a specific best practice build methodology. In the real world, there are more than a handful of build methodologies that could qualify for the best practice accolade, but Maven assumes a single one of them. This does not mean that the others are not good, it just means that if you use Maven, you going to need to buy-in to the conventions it assumes . . . or suffer. This is true for any Convention Over Configuration ( CoC ) tool, and Maven is pretty darn  CoC. 

    Maven, like all design patterns, is a reuseable solution to the process of building software 

    I think the occasionally discussed notion of Maven as a design pattern for builds is a powerful metaphor.  It's useful because it emphasises that Maven, like all design patterns, is a reuseable solution to the process of building software.  It's a best practice solution that has been refined by a community of smart people over years of heavy use.  The most obvious benefits of leveraging a design pattern for building software are the same as those for writing software.  Namely:

    • You get a bunch of functionality with out having to write it yourself
    • An engineer that understands the pattern as applied to one project, can instantly understand the pattern as applied to another project.

    Nominally, the first bullet is about productivity and and the second is about simplicity. Obviously, everybody wants to be more productive, i.e. accomplishing more with less lines of code. But, I actually think the second point -- simplicity -- is far more important. In my opinion, the entire field of engineering boils down, most elegantly, to the concept of "managing complexity". By complexity, I refer directly to that headache you get when bombarded with piles of spaghetti code.  Design patterns help eliminate this intellectual discord by sealing off a big chunk of complexity in a higher level notation.  In case you've forgotten, this is what frees our minds up for the bigger and cooler tasks that inevitably reside on the next level. 

    It is this point of view that makes me rank learning a new project's ad hoc build to be one of the most annoying aspects of my profession. Even if an ant or make build is very cleanly implemented, follows a localized best practice, and automates a broad scope of the software lifecycle, it still punishes  new developers with a mountain of raw data, i.e. lines of scriptcode. Note, it's only the ad hoc-ness that is a problem here. This is certainly not a knock on these tools. ant in particular is very good at automating your tasks and providing a reusable set of build widgets. But it does nothing to provide a reusable solution to the entire process of building software, and, accordingly, it does nothing to ease a new developers on their road to comprehending the build.  

    it's the conventions that matter most with a CoC tool like Maven 

    So, as I see it, it's the conventions that matter most with a CoC tool like Maven.  You have to know and follow the assumed conventions in order to be successful with Maven. Projects that don't follow the conventions quickly run afoul of Maven. First, they struggle to implement their own build process with a tool that assumes a build process of it's own. It's easy to fall into being upset that you can't easily do what you've been doing, but the preceding paragraphs are meant to suggest that it's actually you who needs to change, at least if you plan to continue on with Maven. When you choose Maven, you need to accept the conventions. I you can't, I suggest you stick with Ant, which is flexible enough to meet you on your terms. Just remember that you are losing the ability to leverage the design pattern aspect of Maven to manage the complexity of your build. And if you think your build doesn't have complexity issues, ask your self these questions:

    • Can every engineer on our team easily build all the components of our software system?
    • Do our engineers have the confidence to modify build scripts without angst?
    • Do our engineers flee the room when someone is needed to address a build problem?

    So, if you're with me so far, you'd probably agree that following the conventions assumed by Maven is a critical prerequisite for entering Maven nirvana. And this is what leads me to the conclude that the Maven docs suck.  They are not only inadequate, but perhaps detrimental; they mostly document the configuration while utterly failing on the critical topic of conventions.  The emphasis on configuration, which I assume is largely by accident, leads newbies into thinking it's okay, and perhaps even  normal, to configure Maven. 

    Read the rest of the article at the following URL:

    Maven Does Not Suck . . . but the Maven Docs Do

    Threaded Messages (32)

  2. If Maven didn't suck we wouldn't have alternatives likeGradle and SBT.  The first time you use Maven it's clear that it sucks:  It uses XML.  Ant made it painfully clear that XML isa terrible way to do builds.  A scripting language isan obvious choice for doing builds.  Scripting languages for the JVM weren't available when Ant andMaven were created, but we all would have been much betteroff if the build language was Java itself.


    Maven's learning curve is huge, and I'm not talking about configuration.  I'm talking about learning the "Maven" wayof doing things.  The XML syntax that it uses is not intuitive.  If I have a dependency on a -jar-with-dependencies how do Iget that -jar-with-dependencies instead of the normal .jar?  By specifying that in the <classifier>.  How non-intuitivecan you get.


    Take a look at Shaun Abram's experience using the Maven JNLPLplugin and tell me again that Maven doesn't suck:


      http://www.shaunabram.com/swing-webstart-maven/


    Maven is terrible if you get off of the well-worn path.  You can pontificate all you want about the importance of following the conventions, but the Maven conventions didn't anticipate every problem encountered in building software.  There are lots of CoC tools and frameworks out there that accomodate other ways ofdoing things, but Maven punishes you if you stray from its conventions.


    One use case that new Maven users run into frequently is the need to create two artifaces from one build (i.e. a .jar and a .war).  Maven makes this difficult.  The Maven way is to create one module (project in Eclipse parlance) for the .jar and another one for the .war with the .jar as a dependency.  If you don't understandthis limitation of Maven when you start your project you end up having to split your project into two.


    I could go on, but I have better things to do.

    Yes, the Maven docs suck, but they reflect the fact that Maven itself sucks.

  3. Mven does suck[ Go to top ]

    If Maven didn't suck we wouldn't have alternatives likeGradle and SBT.  The first time you use Maven it's clear that it sucks:  It uses XML.  Ant made it painfully clear that XML isa terrible way to do builds.  A scripting language isan obvious choice for doing builds.  Scripting languages for the JVM weren't available when Ant andMaven were created, but we all would have been much betteroff if the build language was Java itself.


    Maven's learning curve is huge, and I'm not talking about configuration.  I'm talking about learning the "Maven" wayof doing things.  The XML syntax that it uses is not intuitive.  If I have a dependency on a -jar-with-dependencies how do Iget that -jar-with-dependencies instead of the normal .jar?  By specifying that in the <classifier>.  How non-intuitivecan you get.


    Take a look at Shaun Abram's experience using the Maven JNLPLplugin and tell me again that Maven doesn't suck:


      http://www.shaunabram.com/swing-webstart-maven/


    Maven is terrible if you get off of the well-worn path.  You can pontificate all you want about the importance of following the conventions, but the Maven conventions didn't anticipate every problem encountered in building software.  There are lots of CoC tools and frameworks out there that accomodate other ways ofdoing things, but Maven punishes you if you stray from its conventions.


    One use case that new Maven users run into frequently is the need to create two artifaces from one build (i.e. a .jar and a .war).  Maven makes this difficult.  The Maven way is to create one module (project in Eclipse parlance) for the .jar and another one for the .war with the .jar as a dependency.  If you don't understandthis limitation of Maven when you start your project you end up having to split your project into two.


    I could go on, but I have better things to do.

    Yes, the Maven docs suck, but they reflect the fact that Maven itself sucks.

    I agree 1000%. Having suffered with Maven at multiple jobs, maven sucks big time. I've yet to see a moderately complex application work well with Maven. You can get it to work, but it's like stabbing yourself with a hammer, pouring salt and vinegar into the wound, and then pouring acid on it. It won't kill you, but you will be scarred for life and wish you never saw it.

    The worst part is m2e plugin blows. No I haven't tried the latest version because the older versions were so horrendously bad it would be like asking a doctor to amputate my arm so I don't have to cut my nails. maven repositories also blows chunks, even if you pay sonatype for their crappy repository.

    If I had a time machine, the first thing I would do is abort maven before it was born.

  4. I've never had a dependency on a jar-with-dependencies, maven supports plugins to work on situations not anticipated. The maven way of modules is how it works, it's not a limitation.

  5. Having to write a maven plugin in order to deal with a build case that is off of maven's happy path is one of the problems with maven.  Before I can get my build to work I have to learn how to write a maven plugin.  I'd rather write some Groovy Script or Scala.

    Maven makes simple things hard.

  6. At the moment Maven is still the best I can find for build system. Gradle with Groovy or SBT with Scala have their own problems. Just take a look at the editors you can get:

    -> Java and XML editor within Eclipse are very mature. Groovy? Hmm... not really. All those other languages different than Java have their problems in the tooling.

    -> m2e is getting better every day!

    Cheers,

    http://lofidewanto.blogspot.com

  7. There is a good article on the problems with Java build systems here:

    http://grokcode.com/538/java-build-systems-a-sad-state-of-affairs/

     

    The comments (which don't seem to be available any longer) went into even more detail.

    Gradle adopted some of Maven's weaknesses (like hiding things) while replacing XML with Gradle.  I'm looking forward to using SBT once it reaches the beta stage.

    What alternative build systems have others found?

     

     

  8. Before Sonatype got venture funding I wasted lots of time Googling for Maven answers. After they got funding, Sonatype wrote books. I follow Maven by Example for my projects and they work fine. Like Convention over Configuration is supposed to.

  9. The all suck[ Go to top ]

    In 20+ years development in multiple languages, I've found all build systems suck and more importantly, all engineers do is whine and complain about them.

    What I like about maven is

    a) the repository

    b) The fact that my Intellij IDEA can just suck it in and just work...

    Whether or not Gradle does it better...I really just don't care at the moment, because I know it will just suck in different ways than Maven.

  10. agree[ Go to top ]

    The vast majority of people who have issue with Maven just do not understand how it works. We have been using Maven for years with few if any problems. Well, back when we were using JEE we had tons of problems with building EARs and all the complexity of J2EE. But since we use Spring with simple WARs, i could not imagine using something else for builds. Maven has it warts, like all build systems do, but if you are having a lot of issues, it probably is because you are doing it wrong. Like having one monster project which attempts to do everything rather than creating sub projects for various components.
  11. agree[ Go to top ]

    The vast majority of people who have issue with Maven just do not understand how it works. We have been using Maven for years with few if any problems. Well, back when we were using JEE we had tons of problems with building EARs and all the complexity of J2EE. But since we use Spring with simple WARs, i could not imagine using something else for builds. Maven has it warts, like all build systems do, but if you are having a lot of issues, it probably is because you are doing it wrong. Like having one monster project which attempts to do everything rather than creating sub projects for various components.

    Classic maven defense. Not all projects are simple war files. Often times, a project integrates between a dozen systems including mainframes, windows and various unix flavors. Sometimes an application actually needs EJB. Not everything fits in the "spring model". I've worked on a few small simple projects, and even then maven is either over kill or insufficient. I've yet to see maven hit the sweet spot, that ANT build couldn't solve with less work and less maintenance.

    I understand there are people that love maven and that's great for you. I'm just not one of those and I have the battle scars from using maven.

  12. Just ran into another maven screwup today.  I added an tag in the maven-resources-plugin.  It builds find on maven 3, but not on maven 2.0.2.  So it works with the m2e Eclipse plugin, but not on our CI server which is on maven 2.0.2.  Upgrading maven on the CI server is not an option right now.

    Maven 3 is supposed to be a drop in replacement for maven 2, but like all things maven the reality is far from what is advertised.  

    Here is good description of the problems with the maven-resources-plugin and the problems using it on maven 2.0.2:

    http://stackoverflow.com/questions/9773814/maven-resources-plugin-exclude-not-working

     

  13. huh?[ Go to top ]

    you are complaining Maven 3 does not work on Maven 2.0.2? Really? LOL. I think i see your problem.
  14. huh?[ Go to top ]

    You don't know anything about maven, do you.  From the maven docs:

    "Maven 3 aims to ensure backward compatibility with Maven 2, improve usability, increase performance, allow safe embedding, and pave the way to implement many highly demanded features."

    http://maven.apache.org/docs/3.0.3/release-notes.html

     

    Maven 3 isn't even close to having backwards compatibility with maven 2.

     

  15. huh?[ Go to top ]

    You don't know anything about maven, do you.  From the maven docs:

    "Maven 3 aims to ensure backward compatibility with Maven 2, improve usability, increase performance, allow safe embedding, and pave the way to implement many highly demanded features."

    http://maven.apache.org/docs/3.0.3/release-notes.html

     

    Maven 3 isn't even close to having backwards compatibility with maven 2.

    Come on, this statement is too strong. I mean I have no doubt that the issue you faced is a very real one; it is just not sufficient to back up that sort of claim.

    You realize how aim to ensure backward compatibility is different from commitment to being a drop-in replacement.

    Then, maven 2 may refer to 2.0.x and 2.2.x. My project builds on both 3.0.3 and 2.2.1, and this is ~100 modules. So there is a good reason to believe that maven is more backward-compatible that not.

    Also, using different major versions of build software locally and on CI server is an opportunity for troubles, no matter who says what. If I did that I would know I'm on my own.

     

    That said, I have no intent of claiming that maven is just-perfect-period. It violates [at least my] [perhaps naive] expectations that building multi-module system will be easy and require very little to know to get right.

  16. fw[ Go to top ]

    you are complaining Maven 3 will not run on Maven 2. Like I said, if you are expecting that to work, there is not much anyone can do for you.
  17. Maven 3 isn't even close to having backwards compatibility with maven 2.

     

    Hi Dean,

     

    Please google "what does backwards compatible mean", I do hope that you wrote this post in haste because, if you didn't, I hope you are not a software developper.

     

    Regards,

     

    Cédric

  18. A reasonable goal for maven developers would be: projects originally built with maven 2 would build and have the same content when built with maven 3.

    You seem to expect the reverse: a maven 3 project builds in maven 2 with the same output result.  Is that right?

  19. Just ran into another maven screwup today.  I added an tag in the maven-resources-plugin.  It builds find on maven 3, but not on maven 2.0.2.  So it works with the m2e Eclipse plugin, but not on our CI server which is on maven 2.0.2.  Upgrading maven on the CI server is not an option right now.

    Maven 3 is supposed to be a drop in replacement for maven 2, but like all things maven the reality is far from what is advertised.  

    Here is good description of the problems with the maven-resources-plugin and the problems using it on maven 2.0.2:

    http://stackoverflow.com/questions/9773814/maven-resources-plugin-exclude-not-working

    Oh, c'mon.  You don't need to *upgrade* Maven on your build server - just add another version.  Our primary build server has 2.0.9, 2.2.1, and 3.0.x available for builds that strictly requier one or the other - which, although it is extremely unusual, is also very easy to deal with.  Quit complaining about Maven and do your damn job.

  20. most open source docs are out of synch or not there at all.  that's why  commercial guys are still having fun & $$. for example - Spring Tomcat or redHat JBOSS.

    On a similar note i would like to say that JavaDocs suck too. Seriously - will one simple example or some notes be too much to ask. This is one thing they can learn from microsoft MSDN.

    And please its not being lazy , just asking for a good reference. whats the point of making every developer go thru same problem and "learning from mistake" ...isnt the point not to reinvent the wheel :).

  21. Apache Buildr as an alternative.[ Go to top ]

    Rather than bash Maven, as its a bit like shooting fish in a barrel, we use Apache Buildr to build our enterprise java apps and it does 99% of what we wanted out of the box and anything else we needed we can do quite easily because its basically a Ruby script.

    The key feature for us it that it uses artefacts which I think was Mavens one and only decent contribution to the world..

    I have always hated the whole "If your not thinking like a Maven developer" then there is something wrong with you attitude.. Frankly "If your not thinking like a Maven developer then your are probably an engineer capable of independent thought.."

    Cheers

  22. Apache Buildr as an alternative.[ Go to top ]

    Rather than bash Maven, as its a bit like shooting fish in a barrel, we use Apache Buildr to build our enterprise java apps and it does 99% of what we wanted out of the box and anything else we needed we can do quite easily because its basically a Ruby script.

    The key feature for us it that it uses artefacts which I think was Mavens one and only decent contribution to the world..

    I have always hated the whole "If your not thinking like a Maven developer" then there is something wrong with you attitude.. Frankly "If your not thinking like a Maven developer then your are probably an engineer capable of independent thought.."

    Cheers

    On more than one occassion, I've seen maven developers blame users for real issues in maven. It's in the mailing list archives. Joking aside, if a project is a simple webapp with just 1 module, then maven will probably work fine. I don't work on those types of apps. Every complex integration project I've seen first hand that uses maven fails miserably. More than one time I asked the development lead, "have you done a maven build lately?" and got the answer "no, not in months, it's too painful. I get a build from x person."

    Convention over configuration is a noble idea, only if it was implemented well and not like a pile of junk. Sadly, maven never lived up to the promise and still doesn't. Even worse is when maven developer force themselves on open source projects, when existing build system works perfectly fine.

  23. Apache Buildr as an alternative.[ Go to top ]

    I could not imagine using maven on an integration project.  

    I've used maven when it was added to legacy code (a complete disaster) and on new development.  On the new development projects as long as you are willing to devote a lot of time to googling you'll get it to work.  Trying to add maven to a legacy project is a fools errand.  And an integration project - gawwwwd.

     

  24. Apache Buildr as an alternative.[ Go to top ]

    I could not imagine using maven on an integration project.  

    I've used maven when it was added to legacy code (a complete disaster) and on new development.  On the new development projects as long as you are willing to devote a lot of time to googling you'll get it to work.  Trying to add maven to a legacy project is a fools errand.  And an integration project - gawwwwd.

    As a consultant, I don't have the luxury of saying what build system they use. Most of the time, it's already there, I have to just suck it up and deal with it. For those curious, Yes, these projects followed the official maven guidelines. What I see first hand, is that it starts out ok with 1 project. Once it reaches a dozen projects that depend on each other, it quickly breaks down. As a project grows and reaches 2 dozen projects/modules, it fails horribly. Usually, some one ends up being the fulltime maven build maintenance guy.

    At a previous job, the maven build was so bad the nightly build/test hadn't run in over a month. To make life easier on the rest of the team, I volunteered to get it working and keep it working. Rather than have 5 guys waste 20 hours a week on maven, I got it to work consistently doing nightly build/deploy/test on a complex set of app servers, os and databases.

    Can maven work? Yes, if you're willing to eat crap and deal with maven idiots who claim it's "it's easy". Is it worth it? No, maven dependency management is flawed and poorly designed. I've seen this happen at 4 different companies. For me, ANT does exactly what I need with 5x less effort and less maintenance overhead.

  25. Apache Buildr as an alternative.[ Go to top ]

    On large projects like you describe the build software is another, parallel programming project in itself.  It requires a true programming language, not XML.

    I've done more than my share of Ant scripting, and I can't believe that they didn't just create a Java API for the Ant libraries.  The Java build tool sub-industry took a wrong turn when Ant made XML its language.  Instead of build.xml they should have used Build.java and the whole build tool world would have been better off.

    That's why other build tools like Buildr, Gradle, SCons, and SBT use a real scripting language.

    Maven has poor dependency management as you've said, and on the build side it suffers from xml.

  26. In my previous post about using the maven-resource-plugin I was talking about the include tag.  The software omitted it apparently because it is xml.

    I also cannot edit my posts which is another problem.

  27. Why is Maven 3 still generating the .m2 directory? This is again one of the short sightedness we sometimes face with engineers in our industry. Why don't they correct it now by making .maven or something? I know there is a way around it but it looks bad.

    Jan

  28. Why is Maven 3 still generating the .m2 directory? This is again one of the short sightedness we sometimes face with engineers in our industry. Why don't they correct it now by making .maven or something? I know there is a way around it but it looks bad.

    Jan

    Because .maven is used by maven 1 if I'm not mistaken.

     

  29. Why is Maven 3 still generating the .m2 directory? This is again one of the short sightedness we sometimes face with engineers in our industry. Why don't they correct it now by making .maven or something? I know there is a way around it but it looks bad.

    Jan

    Because .maven is used by maven 1 if I'm not mistaken.

    Then they should try something like .mvn that would remain the same for all future versions.

     

     

     

     

  30. M2_HOME=~/.mvn

     

  31. They already did that. They called it .m2 and it's the 2nd version of the .maven directory. We don't have to have the third version of the directory just because we have the 3rd version of the application.

  32. I have used Maven on many projects both simple and complex and I find that it works very well:

    * It integrates well with the Eclipse IDE with the m2e plugin

    * It has first class support in Jenkins (CI Server)

    * Dependency management is great, we use Archiva as an internal repo which proxies external repos

    * Has plugins which support code coverage, junit, checkstyle, findbugs etc.

    * Enforces good governance and has a great releease mechanism

    I can understand how it would be difficult to use without the aid of an IDE but man...once you get it, it really can become a wok horse! I use to think the XML was hell, but I gotta say that once you get familar with the POM schema it is quite easy. The thing about convention is that everyone follows a predicatble path meaning you don't reinvent the wheel each time you setup a new project and it is easy to hand over knowledge of the build because it isn't bespoke.

    I especially like the POM inheritance model. We use this festure to define a global standard for all our porjects. The parent pom mechanism is useful in defining all the standard settings (i.e. plugins) so the new projects can simply inherit these changes.

    Reading the thread I feel that the complaints don't provide enough detail about the crux of the issues people are facing. If you can clearly articulate the issues maybe one we can provide some help/direction. Maven has its good parts and its not so good parts but as you get to know it the "not so good parts" fade into insignificance (at least in my experience :))

  33. Others software[ Go to top ]

    Hello,

    I actually need help because i need to work with different languages like C#, Java script and PHP. Does someone would  know some "maven like" software supporting those languages? 

    Thanks all for your help in advance.