Why does Maven have such a bad rep

Question

There is a lot of talk on the internet about how Maven is bad  I have been using some features of Maven for a few years now and the most important benefit in my view is the dependency management    Maven documentation is less than adequate  but generally when I need to accomplish something I figure it out once and then it works  for example when I implemented signing the jars   I don t think that Maven is great  but it does solve some problems that without it would be a genuine pain   So  why does Maven have such a bad rep and what problems with Maven can I expect in the future  Maybe there are much better alternatives that I don t know about   For example  I never looked at Ivy in detail    NOTE   This is not an attempt to cause an argument   It is an attempt to clear the FUD

User · Answer

The biggest reason Maven has a bad rap is IDE integration. Yes, I know about m2eclipse. I like m2eclipse. I like Netbeans' integration even more.

Here's the problem. Some larger shops built tools to force Maven to work with things like RAD 7.0. It doesn't work well. These hackarounds exist to try to get Maven to behave inside of a tool they are not allowed to change (RAD 7.0). In my case the hackarounded maven builds only work inside Netbeans. Eclipse 3.5 with m2eclipse chokes something horrible.

Most of the devs here hate Maven. They don't hate Maven. They've never really used Maven.

It's disappointing, but it's not really Maven's fault. Maven worked more than fine for me in another life. Here, it's debilitating because of the IDE and the tools meant to make it usable fail to do so.

User · Answer

I ve certainly bitched  amp  moaned about maven in the past   But now  I wouldn t be without it   I feel that the benefits far outweigh any problems   Chiefly    Standardized project structure    Given a new developer joining a project    When you say it s a Maven project  then developer knows the project layout and how to build and package the project When you say it s an Ant project  then developer will have to wait for you to explain more or will have to go through the build xml to figure things out   Of course  it s always possible to impose on company-wide standard with Ant but I think more often than not  you will be re-inventing the proverbial wheel   Dependency management    Not just with external libraries but also with internal libraries modules  Be sure to use a Maven repository proxy server such as Nexus or Artifactory  It s possible to do some of this with Ivy  In fact  if all you need is a dependency management  you re probably better off using Ivy   Particularly within a project   I ve found it quite useful to break out little subprojects  and maven handles this well   It s much more difficult with ant  Standardized artifact management  especially in conjunction with nexus or artifactory  The release-plugin is wonderful  The Eclipse  amp  NetBeans integration is quite good  Integration with hudson is superb   Particularly the trend graphs for things like findbugs  It s a minor point  but the fact that maven embeds details like the version number inside the jar or war  not just in the filename  by default is tremendously helpful    The downsides for me are chiefly    The command line is quite unhelpful   This put me off a lot to begin with  The XML format is very verbose   I can see why it was done that way  but it s still a pain to read    That said  it s got an XSD for easy editing in an IDE   It s difficult to get your head round it in the beginning   Things like the lifecycle  for example    The definitive guide to maven is a good introduction however     I truly believe that it s worth spending a little bit of time getting to know maven

User · Answer

Because Maven is a device for reducing grown men to sobbing masses of absolute terror

User · Answer

My answer  most users complains about maven because they were looking for its pros  but don t have time  or they don t want endure  in setting up their  company environment   That s a personal choice  it can depend from personal patience  the job environment bosses never understand that a well done thing waste less time than an eternal bugfix cycle   etc    However  In the following cases you can have only maven on your workstation without getting mad    a simple library with some beans    a simple  all-in-one  war    even a multi-module project  that has the  standard  dependencies  spring  hibernate apache stuffs and whatever you can find in the central repository  but DOESN T HAVE any dependencies on YOUR libraries    The problems starts to come when you want more  like create your wrappers to standard frameworks classes  or reusable component libraries  you always want to use a set of plugins you like  etc    In that case you have to invest your time in learning  I read in previous posts that someone talk about wasting half day or 2 days   that is not enough  at all  we are talking about modify your poms continuously for at least 1 month   If you wanna use maven in complex projects  you should in order    have your internal repository  it s not an option  it s mandatory  I tried Artifactory and Nexus  they can create troubles at the beginning but when you setup them once  you forget them  create a  master pom  containing all the plugins  with relative version specified  you need  but you must avoid to put there your standard dependencies if you don t wanna get in trouble  for that  see the scope import in dependenciesManagement    this is the hardest part  but you can start copying a master pom of a famous project  spring  tapestry  ecc     and strip what you don t need  if you have a complex project  you must think at what you want before you start to create the artifacts  For example  in a project that has a  war   WebServices Client     Webservice Server   spring   hibernate   Jbpm   whateverelse      it s a good idea to create an  api  module that is referred by both the client and the server  but that contains only model interfaces and does t bring the  server side  dependencies in the client side and the opposite  Fail in that  and maven will become a living hell on earth  if you use Eclipse  m2e plugin is essential  ok  it can be slow  sometimes you should refresh the project and update the project configuration  etc    but finding the  project build path  already setted up is worth of everything  And in the worst case  the command line will always works  While a Continuous Integration server is optional  it s strongly recomended at least for your common libraries  Putting a web application on CI can be too much you don t reuse a webapp on several projects   but putting on CI your standard base classes  your  always used  entity beans  etc   is priceless  Remember that these components are not used only by you  but they can be used even by your team mates while you are busy on other parts of code and that you can forget  i often do  to deploy manually in the company repository to make them available to the team members    To have all these setted up    well  you can even spend months at the beginning  but once you get used to that  you will speed up a lot your development   Personally I didn t use Gradle yet  I don t know if it s better or worst than Maven

User · Answer

Maven is cool     Stop listening to the alternatives  because right now  there aren t any - which aren t just toys   Apart from the Microsoft development toolchain - it s best technology that money can t buy   All these groups who are trying to push  toolchain du jour  -  it s just a cheap attempt to sow confusion and grab market-share     Haters be hating    SBT   Greatest misnomer in history of the earth  Can your Build pass a Turing test  Fucking ridiculous  a step 10 years back in time with it s ridiculous DSL  Uses IVY dependency management  Maven s middle sibling    ANT   Great for that first project after you graduate from Shockwave development   You understand XML  and are enthusiastic  but don t really understand build phases  restarting a project 6 months later  why Version Controlling binary artifacts is a false panacea or that someone other than oneself will one day try to work with your project    MAKE   If the whole world runs in the same UNIX terminal  and speaks fluent Bash  then yeah  But why not just become a C C   programmer  it s much more fun than Java anyhow    Ruby  Various    Whatever  Niche  slow  Just develop Ruby then  stay away from Java development    Python   People use Java where they don t trust Python  anywhere there s money involved   If your system is running Python anyway  you wont even be reading this  unless of course you want the Java money - but are stuck developing Python in some web shop    Clojure  Various    In honour of Stallman  I ll learn Lisp - but for Emacs  not so that I run it upon my VM  I feel that it cheapens the experience

User · Answer

Maven is a software management tool that can boost your productivity  I believe that such a tool is essential for software development in a new era   However  Maven isn t appropriate for all code bases  If you need to support a large legacy code page  or you import code from a third party  then it would be better to avoid using  Maven expects things to be in a certain way  convention over configuration   If you are starting a new project  then this is more than fine  If  however  you have a full system you need to support  the lack of flexibility is a nightmare   Another reason that people usually complain about maven is the steep learning curve  Also IDE integration is still not very mature  Apache is offering two plug-ins for Eclipse  The one is  mature   the other one offers a new approach  I suppose the new wouldn t be needed if the first one was adequate   Another  more serious complain about Maven  is the use of XML for doing programming job  Perhaps tools like Buildr are the way to go

User · Answer

My take here  based on the pitfalls of convention over configuration   http   chriswongdevblog blogspot com 2011 01 trouble-with-being-conventional html  My issue with Maven is the difficulty in discovery and limitless complexity  That  and watching colleagues waste half a work day day fighting Maven build issues  Also IMHO  the Maven integration with Eclipse makes things worse  because you have multiplied the number of places where things go wrong

User · Answer

I ve struggled my way through most all the negatives mentioned here  and similar objections from teammates  and agree with them all  But I ve stuck it out and will continue to do so by holding firm to the one objective that only maven  or gradle perhaps  really delivers on   If you re optimizing for peers  open source developers   ant make whatever will do  If you re delivering functionality to non-peers  users   only maven gradle etc will do    Only maven lets you release a small bundle of source code   poms  no embedded lib binary dependency jars with cryptic names and no dependency info  with a well documented standard project layout that can be loaded by any IDE by someone that hasn t absorbed the developers  idiosyncratic layout conventions  And there s a one-button install procedure  mvn install  that builds everything while acquiring any missing dependencies    The result is an easy on-ramp those users can follow to find their way into the code  where the poms can point them  to relevant documentation    Apart from that  indispensible  requirement  I dislike maven as much as anyone

User · Answer

It s more complicated than the language you used to write your project   Getting it configured right is harder than actual programming

User · Answer

Pros    Dependency management  For several years already  my coworkers and I are not downloading and managing dependencies manually  This is a huge time saver  IDE-independence  It turns out  all major IDEs  Eclipse  IDEA and NetBeans how have decent support of Maven projects so our developers are not locked into one particular IDE   Command-line  With Maven  supporting simultaneous IDE and command-line configurations is straightforward which is good for continuous integration    Cons    Have to invest into learning Maven  Well  have to do it  Good news  not everyone on the team has to learn  Documentation  Used to be a problem  now thanks to Sonatype and their book  http   www sonatype com products maven documentation book-defguide   the situation is much better  Rigidness  It is sometimes challenging and frustrating to do things the way you want  My advice would be not to fight and make Maven do things it does best  straightforward builds  or when there is a stable mojo available  In other cases  we drop out and do stuff either with Ant tasks  http   maven apache org plugins maven-antrun-plugin   orexternal programs  My personal favorite is Groovy plugun  http   groovy codehaus org GMaven      Competition    Ant  doesn t have dependency management  Period  Ivy  still less mature than Maven  not that the latter doesn t have it s quirks  too   Almost the same feature set  so no compelling reason to move  I did several attempts to try it  all unsuccessful    Bottom line  all of our projects are done with Maven for several years already

User · Answer

I love Maven - it boosts productivity  and I am very happy that I am no longer using Ant  phew    But if I could change things it would be    Make pom xml file less verbose Make it easier to include  jars not from the repository

User · Answer

I believe that Maven has a bad rep because most detractors have not observed the combination of Maven   Hudson   Sonar   If they had  they would be asking  how do I get started

User · Answer

It deserves the reputation it has got  Not everyone needs the rigid structure that Maven s developers thought is appropriate for every single project  It is so inflexible  And what is  Pro  for many people  the dependency management  is IMHO its biggest  con   I am absolutely not comfortable with maven downloading the jars from the network and lose my sleep over incompatibilities  yea  the offline mode exists  but then why should I have all those hundreds of xml files and checksums   I decide which libraries I use and many projects have serious concerns about builds dependant on network connection   Further worse  when things do not work  you are absolutely lost  The documentation sucks  the community is clueless

User · Answer

It s common for Maven defenders to say  well  you just don t understand it    This  they think  is a real snappy rejoinder    It goes like this   Super Programmer   hey  I need to keep this door open  does anyone have a doorstop  Maven Programmer   why yes  here s one   shows him a complex collection of popsicle sticks  Super Programmer   these sticks aren t holding the door open   Maven Programmer  smug  chuckling    You just don t understand it   I suggest you read the manual  and really study the thing for about 1 year

User · Answer

The single most important issue to me is that Maven  when not configured properly  may not produce repeatable builds  due to    unreliable remote repositories  dependencies on plugins and libraries with either SNAPSHOT versions or no versions    Contrast this with an ant build which - although verbose and tiresome IMO - works since all jars are checked in locally   The good part is that the problems are addressable    use your own maven repository  which has become dead simple  I m using Archiva with good results  always properly version your dependencies  Maven has started locking down plugin versions in the super-POM starting with 2 0 8 or 2 0 9 and all your dependencies should be on released versions

User · Answer

I d like to counter a few of the complaints made in this forum      Maven is all-or-nothing  Or at least as far as I could tell from the documentation  You can t easily use maven as a drop-in replacement for ant  and gradually adopt more advanced features    This isn t true   Maven s big win is using it to manage your dependencies in a rational way and if you want to do that in maven and do everything else in ant  you can   Here s how    lt  xml version  1 0  encoding  UTF-8   gt   lt project name  foo  basedir     xmlns maven  antlib org apache maven artifact ant   gt     lt maven dependencies verbose  true  pathId  maven classpath  gt       lt maven pom id  maven pom  file  pom xml    gt     lt  maven dependencies gt   lt  project gt    You now have a classpath object named  maven classpath  which contains all the maven dependencies defined in the pom file   All you need is to put the maven ant tasks jar in your ant s lib directory      Maven makes your build process dependent on your network connection    The default dependency and plugin fetching process depends on a network connection  yes  but only for the initial build  or if you change the dependencies or plugins in use    After that all the jars are locally cached   And if you want to force no-network connection  you can tell maven to use offline mode        It imposes rigid structure on you from the start    Its not clear if this is referring to the file format or the  convention versus configuration  issue   For the latter  there are a lot of invisible defaults like the expected location of java source files and resources  or the compatibility of the source   But this isn t rigidity  its putting in sensible defaults for you so you don t have to define them explicitly   All the settings can be overridden pretty easily  though for a beginner it can be hard to find in the documentation how to change certain things    If you re talking about the file format  well that s covered in the response to the next part        It s XML-based so it s as hard to read as ANT was     First off  I don t see how you can complain that some aspect of something  Isn t better than ant  as a justification for it having a bad rep   Second  while it still XML  the format of the XML is much more defined   Further  because its so defined  its a lot easier to make a sensible thick client editor for a POM   I ve seen pages long ant build scripts that jump all over the place   Any ant build script editor isn t going to make that any more palatable  just another long list of interconnected tasks presented in a slightly different way   Having said that there are a few complaints that I ve seen here that have or had some vailidity  the biggest being   Documentation is poor missing Reproducible builds  Eclipse integration is bad Bugs   To which my response is twofold   First  Maven is a much younger tool than Ant or Make  so you have to expect that its going to take time to get to the maturity level of those applications   Second is  well if you don t like it  fix it   Its an open source project and using it and then complaining about something that anyone can have a hand in solving seems fairly asinine to me   Don t like the documentation   Contribute to it to make it clearer  more complete or more accessible to a beginner     Reproducible builds problem breaks down into two issues  version ranges and automatic maven plugin updates   For the plugin upates  well unless you re making sure when you rebuild a project a year later that you re using the exact same JDK and exact same Ant version  well this is just the same problem with a different name   For version ranges  I recommend working on a plugin that will produce a temporary pom with locked versions for all direct and transitive dependencies and make it part of the maven release lifecycle   That way your release build poms are always exact descriptions of all the dependencies

User · Answer

It imposes rigid structure on you from the start  It s XML-based so it s as hard to read as ANT was  Its error reporting is obscure and leaves you stranded when things go wrong  The documentation is poor  It makes hard things easy  and simple things hard  It takes too much time to maintain a Maven build environment  which defeats the point of having an all-singing build system  It takes a long time to figure out that you ve found a bug in maven and not configured something wrong  And the bugs do exist  and in surprising places  It promises much but betrays you like a beautiful and seductive but emotionally cold and manipulative lover

User · Answer

The already mentioned  all-or-nothing  approach was the reason I m usually using Ant instead     Far more often you get to work on a  legacy  project  that already has a defined structure that you can t change just because Maven wants things otherwise    Ant on the other hand can be used anytime  no matter the projects disorganization   Regarding the alternatives  I ve read good things about rake     Btw  I m talking about Maven 1  haven t yet looked into Maven 2

User · Answer

A year later I wanted to update this  I no longer have this opinion about the Maven community   I would not write this answer if the question were asked today   I m going to add my current opinion as a separate answer     This is a very subjective answer  but the question is about opinions  so      I like Maven  and am liking it better the more I get to know it   One thing affecting my feelings about it  however  the maven community is largely centered around Sonatype   the maven company   it s where many of the Maven honchos are working   and Sonatype is pushing its corporate products pretty aggressively on the community   An example  The  Maven Book  twitter stream links to a supposed introduction to repository management     Sorry  but that  intro  is half-information  half sales pitch for Nexus   Pop quiz  are there any other repo managers besides Nexus and Nexus Pro   Also  what does that have to do with the supposedly open-sourced Maven Book   Oh  right  the chapter on repository management has been spun off into a separate book     about Nexus   Huh   If I contribute to the Maven book  do I get a referral fee if I cause an increase in Nexus sales   Imagine if you were participating in a Java development forum and it was clear that the Sun employees discussing Java were going to seize every possible opportunity to talk about NetBeans and  NetBeans Pro    After a while  it loses some of its community feeling   I never had an experience like that with Ant   Having said all of that  I do think that Maven is a very interesting and useful system  I m not calling it a tool  like Ant is  Maven is broader than that  for software development configuration and build management   The dependency management is a blessing and a curse at times  but it s refreshing -- and certainly not the only advantage Maven offers   I m probably reacting a bit too strongly to the Sonatype shilling  but it hurts Maven by association  in my opinion   I don t know if this opinion is shared by anyone else

User · Answer

Good question  I ve just started a large project at work and part of previous projects was to introduce modularity to our code-base    I ve heard bad things about maven  In fact  it s all I ve ever heard about it  I looked at introducing it to solve the dependency nightmare we re currently experiencing  The problem I ve seen with Maven is that it is quite rigid in its structure  i e  you need to conform to its project layout for it to work for you   I know what most people will say - you don t have to conform to the structure  Indeed that s true but you won t know this until you re over the initial learning curve at which point you ve invested too much time to go and throw it all away   Ant is used a lot these days  and I love it  Taking that into account I stumbled across a little known dependency manager called Apache Ivy  Ivy integrates into Ant very well and it s quick and easy to get basic JAR retrieval setup and working  Another benefit of Ivy is that it s very powerful yet quite transparent  you can transfer builds using mechanisms such as scp or ssh quite easily   chain  dependency retrieval over filesystems or remote repositories  Maven repo compatibility is one of its popular features    That all said  I found it very frustrating to use in the end - the documentation is aplenty  but it s written in bad English which can add to frustration when debugging or attempting to work out what s gone wrong   I m going to revisit Apache Ivy at some point during this project and I hope to get it working properly  One thing it did do was allow us as a team to work out what libraries we re dependent on and get a documented list   Ultimately I think it all comes down to how you work as an individual team and what you need to resolve your dependency issues   You might find the following resources relating to Ivy useful    Apache Ivy vs Maven 2 comparison Apache Ivy FAQ Apache Ivy feature list

User · Answer

My practical experience from two large projects is that we have spent 1000 - 1500 hours for each project on maven related problems  excluding a 500 hour effort of moving from maven 1 to maven 2   Since then  I must say that I absolutely hate maven  I am getting frustrated when thinking about it    The Eclipse integration is awful   We had endless troubles with code generation for instance  where eclipse got out sync with the generated code  and required a complete rebuild  quite often  The blame is both maven and eclipse  but eclipse is more useful than maven and say emacs  so eclipse stays and maven have to go    We had a lot of dependencies  and as we discovered  syntax errors are actually commited to public maven repositories quite often  wich can ruin hours of your valuable time  Each week   The workaround is to have a proxy or locally governed repository and that took quite some time to get right  too   Mavens project structure is not really suitable for development with Eclipse  and the build time in eclipse increases   An effect of the code generation and sync problem  we had to rebuild from scrach rather often  reducing your code compile test cycle to an endless compile websurf sleep die code-cycle  sending you right back to the 90s and 40 minute compile times    The only excuse for maven is the dependency resolution  but i would like to do that once in a while  not in every build    To sum up  maven is as far from KISS as it can be  And also  advocaters tend to be the type of people that celebrates extra  on their birthday when their age is a prime-numer   Feel free to vote me down  -

User · Answer

Any Java developer can easily become an expert ANT user  but not even an expert Java developer can t become a beginner level MAVEN user   Maven will make your developers scared s   less for doing anything related to Build and Deployment    They will start respecting Maven more than the War file or Ear file   which is bad bad bad    Then you will be left at the mercy of online forums  where fan-boys will berate you for not doing things the  Maven way

User · Answer

Well I ve been wasting 2 days now with maven  Using m2eclipse  I found that the dependencies reported in eclipse are missing from the repositories  just like that  When I tried IAM and wanted to generate a simple blank project for struts 2  I found that v2 0 9 had also been deleted from the repository  When I finally manually added the artifacts and stuff  the project created itself only to find out that whatever I ask IAM to do  it responds with  no maven 2 projects found      Hey  didn t I just use the Maven 2 project wizard     Maven has been a pain in my ass since day one  THe idea behind it is very nice  In practical terms however  it lacks discipline from all parties involved  And that makes it virtually worthless  BEcause today your project might build  ANd tomorrow  when some dumbass deleted some pom from some repo  you are screwed  As simple as that  It is NOT usable for professional enterprise develoment  Not at all  Maybe in a year or 5

User · Answer

Advantages   Maven is great when you need to be up and running quickly and the dependency management is good   Facilities to avoid jar-hell are not bad either   Some of the underlying theory behind Maven is sound  The default lifecycle phases are well thought out and very instructive for anyone wanting to learn build engineering best practices  Despite the poor documentation the discoverability is excellent  try mvn help help -Ddetail true to see what I mean  If you know how to read an xsd document then constructing a pom is not that hard    Disadvantages  the devil is in the detail    One cannot specify the order of different plugin executions that are bound to the same phase  and any form of non-determinism in computer programming is just plain terrible   Unlike Ant property values i e     my property   Maven properties are resolved at the start of the build  which is OK if you know what the value will be at the start  but if the property s value is determined somewhere in the middle of your build it is too late to access it  its already been interpreted before it s been assigned so the value will be null or the empty string  This is even the case when the execution that needs the property is executed in a phase after the execution that assigns the property -  tearing my hair out over this one   If you stick to the  Maven way  everything runs smoothly  As soon as your build digresses from the  Maven way  all hell breaks loose -  expect to get very good at programming bespoke Maven plugins and archetypes for your project  because doing it from scratch will be more efficient than futzing around Maven s constraints   When working on large projects with many pom files using aggregation  modules in Maven-speak  and inheritance  parents in Maven-speak  there is way too much duplication across builds doing the same or similar things  The Maven xml grammar provides no clear way of distinguishing those members which will be inherited from the parent and those which will not  Expect to be running mvn help effective-pom every two minutes to figure this one out   Complex builds with many plugin configurations become bloated and unintelligible  This is more a problem with xml than Maven itself  There are much clearer and more expressive ways of writing a build -  such as an internal DSL in a dynamic language that supports meta-programming ie Gradle  Buildr  Profiles  with great power comes great responsibility  It s just too easy to stick configuration that belongs in the respective deployment environments inside the build itself  which violates the  one binary  principle  Profiles should be designed to emphasise  roles  rather than environments i e   the act of deploying from CI to staging rather than the holding the configuration of staging itself

User · Answer

Too much magic

User · Answer

There are lot of reasons why people don t like Maven  but let face it they are very subjective  Maven today with some good  and free  books  better documentation  biger set of plugins and lot of referential succesful project builds isn t the same Maven as it was one or two years ago     Using Maven in simple projects is very easy  with bigger complicated ones there is need for more knowledge and deeper understanding of Maven philosophy - maybe in company level a position for Maven guru like network admin  Main source of Maven hates statments are often ignorance   Another niggle for Maven is lack of flexibility like e g  in Ant  But remeber Maven has set of conventions - sticking to them seems to be hard in the begining  but in the end often save as from problems     Current success of Maven proves its value  Of course nobody is perfect and Maven has some cons and its quirks but in my opinion Maven slowly sways his opponents

User · Answer

I d distinguish between Maven 1 and 2  the former has a  deservedly  bad reputation  the latter is an improvement and a rising  standard    My personal opinion is that Maven 2 is more complex and rigid than I like   One man s standard is another s straight jacket   I agree with the  too much magic  comment above   When I compare the simplicity of Ant to the complexity of Maven 2  I know which one I prefer   I ll admit that I know Ant far better   I m in the process of groking Maven 2  but I m not all the way there yet   My poor opinion might say more about me and the state of my knowledge than it does about Maven 2 s true worth

User · Answer

Okay I DON T know much about Maven to go in finer details  but I have tried to make it work more times than I care to admit  For me to use Maven is quite simple provided    You need to  hire  a special Maven guru which you don t for ant  otherwise ask your developers to spend time learning how to  build  their work instead of leaning how to  do  their work  You need to  buy  the Book  they  sell if you want to really understant it    And then    It basically solves only one real problem  dependencies  I wonder how many projects are out there who depend on so many many many other projects that they need a special tool to solve dependencies for them  And ANT can t do it     I personally don t upgrade to newer versions of open source frameworks blindly without seeing the need to do so  If it is working then don t fix it  right   But then this is subjective is right

User · Answer

Like Glenn  I don t think Maven has a bad rep  but a mixed rep  I have been working for 6 month exclusively trying to migrate a rather big project project to Maven and it clearly shows the limits of the tool   In my experience  Maven is good for    external dependency management centralized management of the build  pom inheritance  lots of plugins for lots of things very good integration with continuous integration tools very good reporting capabilities  FindBugs  PMD  Checkstyle  Javadoc         And it has some problems with    all or nothing approach  hard to migrate slowly to Maven  complexe dependencies  intermodules dependencies cyclic dependencies  I know  bad design  but we can t fix 5 years of dev      coherence  version ranges don t work the same everywhere  bugs  again with version ranges  reproducible builds  unless you fix the versions number of all the plugins  you can t be sure you will get the same build in 6 months  lack of documentation  the doc is quite good for the basics  but there aren t a lot of examples of how to handle large projects    To give some context  there are around 30 developers working on this project  and the project has been around for more than 5 years  so  lot of legacy  lots of process already in place  lots of custom proprietary tools already in place  We decided to try migrating to Maven because the cost of maintaining our proprietary tools was getting too high

User · Answer

I looked into maven about six months ago  We were starting a new project  and didn t have any legacy to support  That said    Maven is all-or-nothing  Or at least as far as I could tell from the documentation  You can t easily use maven as a drop-in replacement for ant  and gradually adopt more advanced features  According to the documentation  Maven is transcendental happiness that makes all your wildest dreams come true  You just have to meditate on the manual for 10 years before you become enlightened   Maven makes your build process dependent on your network connection  Maven has useless error messages  Compare ant s  Target x does not exist in the project y  to mvn s  Invalid task  run   you must specify a valid lifecycle phase  or a goal in the format plugin goal or pluginGroupId pluginArtifactId pluginVersion goal  Helpfully  it suggests I run mvn with -e for more information  which means that it will print the same message  then a stack trace for a BuildFailureException    A large part of my dislike for maven can be explained by the following excerpt from Better Builds with Maven      When someone wants to know what Maven is  they will usually ask    What exactly is Maven      and   they expect a short  sound-bite answer     Well it is a build tool or a scripting framework    Maven is more   than three boring  uninspiring words  It is a combination of ideas  standards  and software  and it is   impossible to distill the definition of Maven to simply digested sound-bites  Revolutionary ideas are   often difficult to convey with words     My suggestion  if you can t convey the ideas with words  you should not attempt to write a book on the subject  because I m not going to telepathically absorb the ideas

User · Answer

I think it has a bad reputation with people who have the most simple and the most complicated projects    If you re building a single WAR from a single codebase it forces you to move your project structure around and manually list the two of three jars into the POM file    If you re building one EAR from a set of nine EAR file prototypes with some combination of five WAR files  three EJBs and 17 other tools  dependency jars and configurations that require tweaking MANIFEST MF and XML files in existing resources during final build  then Maven is likely too restricting  Such a project becomes a mess of complicated nested profiles  properties files and misuse of the Maven build goals and Classifier designation   So if you re in the bottom 10  of the complexity curve  its overkill  At the top 10  of that curve  you re in a straitjacket    Maven s growth is because it works well for the middle 80

User · Answer

I think one major reason for the bad reputation is that maven2 solves several complex  problems  build automation  dependencies  managing repositories  as a one shot solution  Therefore you have to face these tough problems while starting to use maven  So it is a kind of  kill the messenger -effect   Other approaches  e g  ant ivy  often do not give you the chance to blame one single tool for all the problems you encounter  It is more like  okay ant not really easy to get started  ivy has some issues  But at least we don t have to wrestle with maven   Saying that one does not recognize that all these problems taken together do not differ too much from the issues you encounter when using maven  It just may be a litte bit easier to tackle one at a time  BTW  I set up a build system based on ant ivy in the past months  And I am really glad I did not have to use maven2  -

User · Answer

Maven does not respect the KISS principle  Try to do anything besides mvn clean install and you are in trouble  With ant you can do whatever you want without any pain

User · Answer

Some of my pet peeves with Maven    The XML definition is super clumsy and verbose  Have they never heard of attributes  In its default configuration  it always scours the  net on every operation  Regardless of whether this is useful for anything  it looks extremely silly to need Internet access for  clean   Again in the default  if I m not careful to specify exact version numbers  it will pull the very latest updates off the  net  regardless of whether these newest versions introduce dependency errors  In other words  you re placed at the mercy of other peoples  dependency management  The solution to all this network access is to turn it off by adding the -o option  But you have to remember to turn it off if you really want to do dependency updating  Another solution is to install your own  source control  server for dependencies  Surprise  Most projects already have source control  only that works with no additional setup  Maven builds are incredibly slow  Fiddling with network updates alleviates this  but Maven builds are still slow  And horribly verbose  The Maven plugin  M2Eclipse  integrates most poorly with Eclipse  Eclipse integrates reasonably smoothly with version control software and with Ant  Maven integration is very clunky and ugly by comparison  Did I mention slow  Maven continues to be buggy  Error messages are unhelpful  Too many developers are suffering from this

User · Answer

I think Maven gets a bad rap because it imposes structure on your project  whereas other tools such as Ant allow you to completely define the structure any way you wish   Agreed also that the documentation is bad  but I think primarily the bad rap that Maven gets is because people are so used to Ant

User · Answer

My experience echos the frustration of many of the posts here  The problem with Maven is that it wraps and hides the details of build management in its quest for ultimate automagical goodness  This makes you nearly helpless if it breaks   My experience is that any problem with maven quickly degenerated into a multi-hour snipe hunt through webs of nested xml files  in an experience similar to root canal   I ve also worked in shops that relied heavily on Maven  the people who liked it  who liked it for the  push a button  get it all done  aspect  didn t understand it  The maven builds had a million automatic targets  which I m sure would be useful if I felt like taking the hours to read through what they did  Better 2 targets that work that you fully understand   caveat   last worked with Maven 2 years ago  it may be better now

User · Answer

Maven does not easily support non-standard operations  The number of useful plugins is though constantly growing  Neither Maven  nor Ant easily intrinsically support the file dependency concept of Make

User · Answer

great idea - poor implementation   I moved a project from Ant to Maven recently  It worked well at the end  but I had to use two different versions of maven-assembly-plugin and maven-jar-plugin in the same pom  got two profiles  because what worked in one version was broken in another   So it was quite a headache  Documentation isn t always great but I must admit that it was relatively easy to google answers   make sure you always specify versions of plugings you use  Don t expect that new version will be backwards compatible   I think controversy comes from the fact that maven still evolves and the process is painful sometimes    regards  v

User · Answer

Very simply  Maven wants to own the world   It wants to define projects  how they re laid out on the file system  where the jars go in its cutesy local cache  how to fetch things  dependency graphs  build plugins  ide plugins  etc etc etc   Some people love that kind of thing  admire it   For me  it s all about the quality  I could care less about your boooooring theories   Just execute  do it flawlessly  and then preferably fade into the background until I decide to mess with you again     My message to Sonatype and Maven adherents apologists is that you do not yet ooze with quality   pom xml format is too verbose  academic  and tedious - fix it   Complex  multiproject builds are maddening to setup with Maven - why so hard   Fine tuning when to fetch and when not to fetch underspecified jars would be an interesting thing - until we get that  the maven strategery of fetching whenever we can think we want to is maddening   SNAPSHOT is always all in caps because it s screaming laughing at me and driving me mad   The minutae and goofy unique ways cruddy open source maven plugins plug into poms is maddening   Classpath issues with no good way to resolve them   Oh yeah  and the legacy apache commons-  groupId s polluting my repository root are maddening in a  the cheese triangles don t go that way   -rage sort of way   m2eclipse is pure concentrated madness  die monster die  kill it with fire it s the only way we can be sure   Maven embarrassed me once to a client - it s inexcusable that a tool so got in the way of my being productive   I want my tools  and their makers  to act like the humble servants they are   When I ask Maven who the king is  I expect the answer to be  DAVE  followed by pleasantries and much bowing and lowing       Inertia is the real story with Maven   If you want to play with open source java  you re pretty much going to be pulling from a Maven repository   So  if you want to play nice there  you had better be able to get your dependencies the Maven way and learn to read poms     Thank goodness for Ivy and IvyDE  that I can set my maven dependencies in both Ant and Eclipse and not be stuck with the Maven toolchain     Maven repository server software I ve used like Nexus and Artifactory are neat  futuristic tools   They are glittering jewels compared to the rest of the maven ecosystem   My Maven experience feels like how Eclipse felt back in the day   Eclipse wanted to own the world too with their dumb ideas  and it took a long time for the platform to mature  years and years  before I really allowed Eclipse to own my world   Perhaps in years and years Maven can reach that level of quality   At this point  I say  never again shall mine eyes witness the horrors   but I was saying that about Eclipse 1 0 too when it came out

User · Answer

Maven does solve working problems  it builds java softwares  and easy dependence management   But it is very different from Ant  and GNU Make  or other Unix-like package management system  This make new-comer have to pay a lot to learn it   There are lots Maven document  but some of them pushing you away  like this from  using m2eclipse       By simply entering a groupId into the query field  m2eclipse queries the repository indexes and even shows a version of the artifact that is currently in my local Maven repository  This option is preferred because it is such a tremendous time saver    I really hate to figure out a long sentence and found it says nothing  I can remember how good feel when reading python official tutorial  and erlang s  Good document will show the author has good senses   Maven appears strange to newcomers  it s command line style is different from Unix command line traditions   If you pay time to go through  maven by examples  or  The Definitive Guide   it pay off  you can find it on http   www sonatype com    But even if you read all those documents  and can use the tool with confidences  you can come across troubles time by time  some caused by software bugs   And expert get ways to live with it and keep productive   After all  Maven is open source software  it contributes knowledges to freelance engineers   And this make it respectful  When people talks more about it s bad reputation  it is doing good job for open source world   So  as how skilled people use any tools  just use it  and don t depend on it  depend on yourself

User · Answer

The short answer  I ve found it very difficult to maintain a Maven build system  and I would like to switch to Gradle as soon as I can    I ve been working with Maven for over four years  I would call myself an expert on build systems because in the last  at least  five companies I ve been in  I ve done major renovations on the build deploy infrastructure   Some of the lessons I ve learned    Most developers tend not to spend a lot of time thinking about build systems  as a result  the build turns into a spaghetti mess of hacks  but they do appreciate it when that mess is cleaned up and rationalized  In dealing with complexity  I would rather have a transparent system that exposes the complexity  like Ant  than one that tries to make complex things simple by imposing rigid restrictions  like Maven  Think of Linux vs  Windows  Maven has a lot of holes in functionality which require byzantine workarounds  This leads to POM files that are incomprehensible and unmaintainable  Ant is super-flexible and understandable  but Ant files can get pretty big too  because it s so low-level  For any significant project  developers have to create their own build deploy structure beyond what the tool provides  the suitability of the structure to the project has a lot to do with how easy it is to maintain  The best tools will support you in creating a structure and not fight you    I ve looked into Gradle a bit and it looks like it has the potential to be the best of both worlds  allowing a mix of declarative and procedural build description

User · Answer

We use maven2 in all our projects and it speeds up development tenfold  combined with a nice continuous integration platform     The only feature of maven2 that has caused us a lot of headaches in the past is the transitive dependency mechanism  In a Utopian world it would be the end-all solution to all dependency issues but in practice it tends to send you straight to dependency hell    Our main problem came from the fact that various components in the default maven2 repository depend on different versions of the same library  i e component1 and component2 both require a logging framework but component1 requires v1 and component2 requires v2    To solve this we simply have our own local repository containing all the libraries we need  This allows us to ensure that all libraries we use that have their own dependencies depend on the same versions of other libraries

User · Answer

Because unsatisfied people do complain while satisfied people don t say they are satisfied  My point is that there are far more satisfied maven users than unsatisfied but the later make more noise  This is a common pattern from real life too actually  ISP  phone carrier  transports  etc  etc

User · Answer

To me  there are as many pros as there are cons to using maven vs ant for in-house projects  For open source projects however  I think Maven has had a great impact in making many projects much easier to build  It wasn t too long ago that it took hours get the average OSS Java  ant based  project to compile  having to set a ton of variables  downloading dependent projects  etc   You can do anything with Maven you can do with Ant  but where Ant doesn t encourage any standards  Maven strongly suggests you to follow it s structure  or it ll be more work  True  some things are a pain to set up with Maven that would be easy to do with Ant  but the end result is almost always something that is easier to build from the perspective of people who just want to check out a project and go

User · Answer

If you re going to bet your business or job on a development project  you want to be in control of the foundations - i e  the build system  With Maven  you are not in control  It is declarative and opaque  The maven-framework developers have no idea how to build a transparent or intuitive system and this is clear from the log output and the documentation    The dependency management is very tempting since it could same you some time at project inception but be warned  it is fundamentally broken and will eventually cause you a lot of headaches  When two dependencies have incompatible transient dependencies you will be blocked by a rat s nest of complexity that will break the build for your entire team and block development for days  The build process with Maven is also notoriously inconsistent for different developers in your team due to inconsistent states of their local repositories  Depending on when a developer created their environment  or what other projects they re working on  they will have different results  You ll find that you re deleting your entire local repository and having Maven re-download jars far more often than the first time setup for a dev branch  I believe OSGI is an initiative that is attempting to fix this fundamental problem  I would say that perhaps if something needs to be so complex  the fundamental premise is wrong    I ve been a maven user victim for over 5 years now and I have to say that it will save you far more time to just check your dependencies into your source repository and write nice and simple ant tasks  With ant  you know EXACTLY what your build system is doing    I ve experienced many  many lost man weeks of time at several different companies due to Maven problems    I ve recently tried to bring an old GWT Maven Eclipse project back to life and 2 weeks of all my spare time later  I still can t get it to build consistently  It s time to cut my losses and develop using ant   eclipse me thinks

User · Answer

I wouldn t say it has a bad rep so much as it has a mixed rep   If your project follows the  convention over configuration  paradigm advocated by Maven then you can get a lot leverage out of it   If your project doesn t fit well into Maven s world view then it can become a burden   To that end  if you have control over the project  then Maven may be the way to go   But if you don t and the layout is determined by someone not a fan of Maven  it may be more trouble than it s worth   The happiest Maven projects are probably the ones that started as Maven projects

User · Answer

Maven is great   The reason for its reputation has got to do with the steep learning curve  in my opinion    which I am finally close to getting over   The documentation is a bit rough to wade through  simply because it feels like there s a lot of text and new things to comprehend before it starts making sense   I say time is all that s needed for Maven to become more widely praised

User · Answer

I like maven  I ve used it since pre 1 0  It s a powerful tool that on balance has saved me considerable amounts of time  and improved my development infrastructure  But I can understand the frustration some people have  I see 3 types of frustration    where the causes are real concerns  e g  verbose POMs  lacking documentation   some is misinformation  e g   you have to have an internet connection to build  - not true - doin t  this can be avoided    some of it is vented at maven but really someone else is culpable   don t shoot the messenger       For the first case  real problems - well  sure  there are problems  POMs are verbose  documentation could be better  Yet despite this  it is possible to get good results with maven in quick time  I cringe every time I get a project built with ant  and try to import this into my IDE  It can take a long time to set up the directory structure  with maven  it s just a case of opening the POM file in the IDE   For the second case  Maven is complex  and misunderstandings are commonplace  If maven 3 can find a way to address this complexity  or even perceived complexity  that would be good  maven does take a considerable investment  but  in my experience  the investment pays for itself quickly   For the last point  I think the gripe about maven s transitive dependencies is probably the best known example    Transitive dependencies are the nature of real software employing reuse  Windows DLLs  Debian packages  java packages  OSGi bundles  even C   header file includes all have dependencies and suffer the dependency problem  If you have two dependences  and each uses a different version of the same thing  then you have to try to resolve that somehow  Maven doesn t try to solve the dependency problem  but rather brings it to the forefront  and provides tools to help manage the problem  such as by reporting conflicts and providing consistent dependencies for a hierarchy of projects  and in fact provides absolute control over a project s dependencies    The approach of manually including dependencies with each project  one poster says he checks all dependencies into source control  is runing the risk of using the wrong dependency  such as overlooked updates when a library is updated without checking in updates for it s dependencies  For a project of any size  managing dependencies manually is surely going to lead to errors  With maven  you can update the library version you use and the correct dependencies are included  For change management  you can compare the old set of dependencies  for your project as a whole  with the new set  and any changes can be carefully scrutinized  tested etc   Maven isn t the cause of the dependency problem  but makes it more visible  In tackling dependency issues  maven makes any dependency  tweaks  explicit  a change to your POM overriding the dependency   rather than implicit  as is the case with manually managed jars in version control  where the jars are simply present  with nothing to support weather they are the correct dependency or not

[java] Why does Maven have such a bad rep?

Examples related to java

Examples related to maven-2

Examples related to build-process

Examples related to build-automation