Build Tool
Gradle vs Maven (or Both)
The world of build tools evolved from simple compilation (gcc) to make files, then evolution of ant(+ivy) and Maven, now the latest build tool is Gradle.
It’s always a puzzle which build tool to choose – Maven, Gradle or both. Sometime it’s first time project setup or it could be migration from existing tool, but it’s always a debate to choose one or the other.
There have been lot of talks and discussions on Gradle, Maven (and/or Gradle vs maven). There is buzz around that Android/Google adopted Gradle as its standard build tool.
Here, I would like to explore the possibilities of adopting Gradle or Maven (Or both), Intentionally i am keeping ant+ivy out of this talk.
Lets take a look at the details on why Android may have adopted Gradle
Key points for Google to go ahead with Gradle for their android development are:
- Create multiple APKs for your app with different features using the same project.(create several variants of an application)
- Reuse code and resources.
- Customize, configure, and extend the build process.
- Customized integration with their own IDE Android Studio.
- Single build tools to support multiple languages.
They had some special requirements for their diverse eco system, they worked with gradleware development team to include customized feature for the android application. They even have customized IDE for android developers build around Gradle.
What we may be looking from build tools
- How easy is the learning curve?
- How fast are different builds with each tool?
- How complex is it to create and maintain the build script?
- How many plugins exist and how simple is it to customize your own plugins?
- How good is the community and documentation for each tool?
- How well does each tool integrate with developer tools? (IDE, App Server, CI server).
Lets take a look at Maven and Gradle build tools on basis of above points and give them score as per our use case.
Here is the Tabular comparison for each point between Maven and Gradle.
| Points | Maven | Gradle | Score | ||||||
| How easy is the initial learning curve | 1) Maven is XML based tool, XML is very commonly used/known.2) If existing project are using maven then developers are comfortable with the system. | 1) Gradle is DSL based system and need to learn explicitly.2) Developers need to learn new system from beginning if they are not familier | Maven – 8/10Gradle – 5/10 | ||||||
| How fast are different builds with each tool | Taken a report from zeroturnaround, they have done detail analysis of the speed of builds with both built tools and found maven and gradle are close enough on build timings. | Maven – 8/10Gradle – 9/10 | |||||||
| How complex is it to create and maintain the build script? | Maven build scripts are xml based, which has predefined structure and only one way to write.So it makes it more standard and less flexible. | Gradle has its own DSL which is introduced by Gradleitself and tightly connected to Gradle internals But its flexible and simple and short | Maven – 5/10Gradle – 7/10 | ||||||
| How many plugins exist and how simple is it to customize your own plugins? | Maven is called “plugin execution framework” Hundreds of plugins exist for Maven and you can create your own plugin is simple. | Gradle’s architecture is also plugin-based, It’s easy to write plugins But availability of plugin in community may not be ease. | Maven – 8/10Gradle – 6/10 | ||||||
| How good is the community and documentation for each tool? | Maven is in the market for very long time, Documentation is good, Lots of resources and help available in open community and forum. | Gradle is very recent. It is open source but still under control of gradleware. They have option for commercial support. | Maven – 9/10Gradle – 8/10 | ||||||
| How well does each tool integrate with developer tools? (IDE, App Server, CI server). | With many years of background Maven has full support to almost each tool and every category (IDE, App Server, CI). | Lacking in the App Server and CI ServerCategories, mainly due to newness. | Maven – 9/10Gradle – 5/10 | ||||||
(Note – I haven’t given any tool 10/10 because there is always room for improvement).
My scoring is based on following fact.
- One is already using maven for all their projects.
Total Score
Maven – 47/60
Gradle – 40/60
One can decide the score on the basis of their user case and requirement.
Choices
Gradle
You may not be using other features which are used by Google for android development as those features may or may not match with your needs, however Gradle is essentially emerging as a popular tool and you may definitely want to have a look at it.
Maven
Maven is widely used and has robust defined workflow around it. Developers are very familiar with the system. However this may not be a viable option as android development needs to use Gradle.
Maven and Gradle (both)
This would be the one option for a company with a wide range of development options. It may give developers flexibility to adopt tools as per their choice with a given workflow.
The content of this article may be good, but I can’t even finish reading it because this web page is so poorly designed. Ads and images are overlaying text, the table is not formatted correctly, etc. It gives the overall impression of a very amatuerish site, I am afraid.
HI, thought it appears fine on my machine, it could be the table tags the author used. We have the team looking into this and will correct. thanks for pointing out
FWIW, it seems like it looks ok on a very large screen, but it does not scale well to smaller screens. I was on Chrome, btw.
thanks, yes I use chrome too but on a high rez. I think the author did the tables in another program and then cut and paste into the editor. I have one of our people looking at it now to fix
Your scoring is biased. As an example: Maven has at least the same learning curve as Gradle if a user is unfamiliar with both. Saying that XML is used implies I can just write without needing to learn the XML based DSL that drives Maven.
This scoring is based on some assumption and use case which was already mentioned after the scoring part in article.
This is just an example guideline to help users to decide own score.
Please use your own logic and judgement according to use case and come up with your score.
This scoring is based on some assumption and use case which was already mentioned after the scoring part in article.
This is just an example guideline to help users to decide own score.
Please use your own logic and judgement according to use case and come up with your score.
Maven XML has a very simple structure compared to Ant, which was the original target audience.
Thoughtworks: “Maven has long been a staple of build automation in the Java space. However, given its lack of flexibility and support for automation best practices, especially in the Continuous Delivery domain, the use of alternatives such as Gradle should be considered.”
Promoting your business ? Or just employed for promotional comments ?
Neither. But if you’re aware of a software development company who provides a better comprehensive overview of technologies than Thoughtworks’ Technology Radar, please share. If you’re not familiar with their technology radar I highly recommend it.
Interesting article. For now it sounds like Maven has better support and community, without a steep learning curve, so is probably the best option until Gradle is more mature.
That’s not what Thoughtworks thinks: “Language-based build tools like Gradle and Rake continue to offer finer-grained abstractions and more flexibility long term than XML and plug-in based tools like Ant and Maven. This allows them to grow gracefully as projects become more complex.”
In Java land, if a project becomes becomes “that” complex, then its time to break it apart in smaller more maintainable parts. Microservices is here for a reason!
I have a suspicion you don’t really know who Thoughtworks is. Martin Fowler works for them… They’ve probably built more microservices than anyone.
Chuck,
Yes, I know Martin Fowler and Thoughtworks and I also follow their radar for many years. I’ve seen technologies going in the Radar one year and disappear in the next year. This means that sometimes technologies try to bite off more than what they can chew.
Gradle is no different! Don’t take me wrong, Gradle is innovative since it brings scripting to the build environment. But, and for example, it suffers from the exact same issue as any other Ant project… too many random tasks that make hard from people to move from one project to the other and easily follow the build process. In such cases, the learning curve is long and painful.
Another painful issue is that Gradle uses Groovy!!! Here’s what the creator of Groovy said about it…
“Though my tip though for the long term replacement of javac is Scala. I’m very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I’d probably have never created Groovy.”
And why was Groovy the selected language for Gradle? It’s not even type safe to begin with (although they now have a hack on the top to make it @CompileStatic).
The conclusion from the following paper:
http://pleiad.dcc.uchile.cl/papers/2012/kleinschmagerAl-icpc2012.pdf
“Static type systems help humans use a new set of classes: For four of the five programming tasks that required using new classes, the experiment revealed a
positive impact of the static type system with respect to development time. For one task, we did not observe any statistically significant difference (possibly due to learning effects).
Static type systems make it easier for humans to fix type errors: For both programming tasks that required fixing a type error, the use of the static type system statistically significantly reduced development time.”
In addition, IDE support for Gradle/Groovy is really poor. Even IDEA has some issues with auto-completion support (again, because the language is not type safe).
When I look at a build.gradle file, quite often what I see is “spaghetti” code full of workarounds to be able to get something working.
Now, you can also say that Pivotal is behind Gradle, and that’s the same company that bring us the amazing Spring Framework… but they were also the one’s who brought us Spring Roo! So no, not everything that shines is made of pure carbon.
If you like Gradle, you will love Kobalt, built on the top of Kotlin, a well designed engineering language by the same folks that bring us Intellij IDEA. Still, the issue with Kobalt is that it is an almost exact replica of Gradle… another Ant like project builder.
I have built plugins for Gradle, Maven and more recently for Kobalt. Maybe because I have used maven for many years and ant before that for even more years, I must say that switching from ant to maven was a complete reset on how to think about building projects. Going back to ant like projects is something scary, more so if non-tested code is being produced on the fly just to have a “task” work (Gradle scripts do not have tests – but I’ll assume that Gradle plugins do). I can’t avoid but seeing danger in this.
Having said all this, I must state that this is my current opinion and, who knows, maybe it will change one day. for the moment, I’ll go with maven whenever possible. If not possible (e.g. Android projects), I’ll use either Gradle or Kobalt.
Well said.
Of course, the Ruby and Javascript popularity proves that static typing isn’t automatically a winner.
For me Gradle wins simply because it’s not XML. The idea of programmers writing in something designed for machines to easily process is a bit absurd.
True,
XML is a bit of a pain in the but. But we do it all the time! After all XML is a subset of SGML and HTML is an application of SGML. We write HTML pages in painful HTML. But why not build a better representation of it? As far as I am concerned, one could easily replace it with markdown. How cool would that be?
# plugin – exec
“`scala
def greet() = println(“Hello, world!”)
greet()
“`
So, yeah, XML might be outdated and “heavy”, etc… but it does offer some great pluses. For example, structure can be validated, its expressive (specially good for newbies), and other.
I can live with that! 🙂
Some friends that studied Automotive Engineering told me one day that the real reason why the Brits decided to build Morris Mini was because they wanted to show the Germans that the Beetle was, well, not so economic or reliable as Queensland made car. We now know how that went!
In the same way, I have this feeling that, despite many voices in the contraire, keeps telling me that Gradle is to Maven what Morris is to Beetle!
So, I’ve spent the past month with Gradle. It’s 2017. As of today, AFAICT, there’s no reason to switch from maven and there are plenty of reasons not to. (Caveats: if you’re doing Android dev and/or if you want to write custom build logic in Groovy, then go gradle.) I wanted to like gradle more. It’s simplified formats were appealing. But, after a month, I find I’m mostly just wrestling with it whereas maven, though crufty in many, many ways, just does the reasonable thing.
Particular points:
+ Maven profiles are useful. While writing the conditional logic for gradle ain’t hard, you end up with this logic sprinkled in all sorts of sections of the build file. Yuck.
+ Integration tests – maven knows how to do this out of the box. Gradle… well, it’s complicated. You usually have to restructure your code.
+ Parent pom and externalized definitions. Maven… baked in. Gradle… roll your own. Oh, and, those shared, common version numbers… good luck in gradle if you’re using that for a plugin because plugin specifier MUST come first therefore you must hard-code those things. Why?
+ Gradle’s uber funky way of storing dependencies in its local folder. Why?
There are 3 or 4 more, but already I’m disappointed. I want an experience that matches the vista of those initially skinny build files: a place where things just work and most things you do as a java dev are thought of beforehand. Gradle gets props for being more general-purpose than maven. But…. not worth the effort on its own at this point. I’d rather a tool that just moved maven forward. Maven is a good conceptualization of java development. It would benefit from a serious evolution. Not sure the gradle revolution takes me to a better place, however. Wished it did. Maybe someone else can shed some light on what I’ve missed.
Correct oogledy, I agree with most of point mentioned by you. specially parent pom.