Published: Jul 16 2013 / 08:28
I've posted another link do DZone about Maven 3.1.0 release and also have hard time to write the announcement - there really isn't anything new. I think Maven is mature enough to be tagged forever and to have it's trunk/master deleted :) Gradle is great - I (try to) use it but there's single difference - build time. Even with all these daemons and everything. Building Spring with Maven/And/Spring-build was fast. With Gradle is slow. I only hope it will be better.
I agree with the article. Maven developers are not fixing the fundamental problems that make Maven hard for the average developer to use. Maven brought a standardized build process and conventions to the Java world (awesome!). But Maven is overly complicated, not intuitive, and generally hard to use for anything out the ordinary. Shops using Maven successfully, are big corporations or companies that can afford top talent, who can customize Maven to fit their needs. For everyone else (even most build engineers and devOps staff), Maven is too complicated. That's why even after all these years, Ant is still used widely. With the disappointing Maven 3.1 release, I think we've reached the tipping point for Gradle.
Maven is only too complicated when you are trying to do something too complicated with Maven. If it is too complex to be easily done in Maven, then you might be able to do it easier somewhere else, but you may be better served by addressing your complex requirements which are the actual root of your actual problem. Perhaps Maven is trying to tell you something.
In real world development, you do not always have full control of your build requirements/environment. In those cases, asking something out the ordinary of Maven, can be so difficult to do the right way (using plugin with an execution and configuration), that many people just write custom Ant or Groovy scripts to do the job and by pass Maven's complexity. When you see this pattern over and over at many companies, then you realize that Maven itself is just too difficult to be understood and used by the "average developer/dev ops" person. Personally, with enough research and experiments, I can make Maven do what I want in the "Maven way", but I've seen numerous cases where other developers didn't want to put in that much effort. It may not be ideal, but it's reality. The people behind Maven have been unable to make it easier to use. As a result, Gradle will be given serious consideration for new projects.
I mostly agree with everything you said except that I would point out that the ideal Ant project would look a lot like Maven except without much of the default (non-extreme-config) functionality provided by Maven. But yes, you can do anything in Ant and you can shoot yourself in the foot using Ant or Maven. You can also wrap either one with the other. That would probably suck worse than either one in stand alone though. Wouldn't recommend doing that.
I still would like to : 1- know what so great features Gradle provides that are actually really usefull (I mean, something that fullfill a real requirement not a requirement of somebody trying to be clever but complicating the build maintenability for its future colleagues) 2- understand what real world problem can't be solved simply with Maven. I mean, a build is a build, it's should always be the same (generate some sourcesn compile jars in correct dependencies order...). Please anyone with concrete exemples ?
For me Gradle has one biggest advantage - its "top down" approach in multi-module projects. You specify the "recipes" in one build file (at top level) and "push" them to child projects. Maven's most important role is dependency management and how it provides an order in all Java dependencies (of course when POMs are written by sane programmers). Maven did it well by establishing Maven Central, project coordinates etc. Also the "Maven conventions" in project layout are non-discussable - in the times of Ant we all had to think about where to put libs, intermediate code, reports, sources, resources, test. Now it feels just "wrong" when there's no src/main/java | src/main/resources. For me, Maven's role as "builder" is less relevant than "dependency manager". It builds well unless you want to do something non-standard because you have to rely on plugins. Only recently "buildnumber-maven-plugin" started to work and it also had problems with Git and e.g., checking what branch we're at. It would be one-liner in Makefile, but in Maven we had to skip several buggy releases...
Have you read the article written by the Hibernate developers? I think that article displays a lot of reasons why Maven is insufficient for certain builds. The fact is: Gradle has evolved to a point where it's as much effort to write a build in Gradle as it is in Maven. However, with Gradle, you can do stuff which is either impossible in Maven or takes several plugins to make it work (in which case you'll need to cross your fingers and hope they are compatible with each other). I'll even go further and dare to state that complex, multi-module projects are easier to do in Gradle than in Maven. The one thing that bothers me about Gradle is the size of the gun it provides you with. With Maven, you can lose a toe if you shoot yourself in the foot. Gradle has the potential to blow your entire leg off.
"Gradle has the potential to blow your entire leg off". I really agree. My point of view is that very few people have similar needs to the Spring or Hibernate teams. So choosing Gradle for its flexibility makes me think they should rather standardize their build rather than trying to adapt the tool. It's a question of long term maintenance, which, for a build, is THE keypoint.
By the way, I ordered recently "Gradle in Action" in order to have a clearer look ;)
Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.
Advertising - Terms of Service - Privacy - © 1997-2014, DZone, Inc.