Discover our knowledge. Read our blogs!

Learn more

We build all our solutions with WSO2 and we are proud that we are WSO2 Premier Certified Integration Partner and Value-Added Reseller.

Learn more

WSO2TORIAL - Get ready to rumble: Maven vs Gradle

14 min read

Ready to rumble - wso2 tutorial.jpgIn general, you can say that choice is good. Having alternatives to choose from gives you the opportunity to make merit based selections.

In case of building JAR files or Bundles, most users of WSO2 will use Maven since this is the default setting for instance in Eclipse, it is the tool that WSO2 uses themselves when building products.

Maven

Maven is the build tool that we use most of the time within Yenlo for WSO2 projects. It is used for creating all kinds of jars and bundles, like a custom mediator, custom connector and so on.

Maven can be downloaded from the Maven Website. Installation is easy and instructions can be found here.

Maven uses a POM (Project Object Model) file which is an XML file as you can see here:

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>com.yenlo</groupId>

    <artifactId>DummyHandler</artifactId>

    <version>1.0.0</version>

    <packaging>bundle</packaging>

In the POM file we also find <dependencies>, <repositories> and <plugins> that will describe what is needed to build the sourcecode.

Repositories or a repository point to a local or online collection of libraries that the user wants or needs to include in the build. Dependencies are library references needed for the compilation or execution of the tasks during or after the build. Plugins will perform certain tasks like compiling, testing or packaging the result of the build.

Together these definitions will execute and include all the required files to build the binary artifact.

Starting a maven build is possible using the commandline : mvn clean install . In this case maven will clean the previous build and create a new binary file. The ‘install’ phase will also install the artifact into the local repository for later reference if needed. 

Gradle

But there are alternatives, for instance Gradle. Gradle can be downloaded from the Gradle website and the zip easily installs for instance on Windows.

We have put gradle in the program files directory and set the path to the gradle/bin directory. When we start Gradle with the -v (version) parameter we get this response:

C:\Users\rob>gradle -v
---------------------------------------------------------
Gradle 4.3
---------------------------------------------------------
Build time:   2017-10-30 15:43:29 UTC
Revision:     c684c202534c4138b51033b52d871939b8d38d72
Groovy:       2.4.12
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_121 (Oracle Corporation 25.121-b13)
OS:           Windows 10 10.0 amd64

So we have a working setup of Gradle, let’s see what we can do.

As said, Gradle, like Maven, is a build tool. One of the most visible differences is the fact that Gradle uses a Groovy based script to define the build process, dependencies et cetera.

Since I do not have a java product ready for gradle  I will use the gradle init command on an existing POM file for a customhandler in the WSO2 API Manager.

Ready to rumble - mac morrison.pngmac morrison

Boxing ring stage

https://gradle.org/maven-vs-gradle/

Faster builds

Gradle brags that is allows organizations ship better software, faster. A developer can do more development when not waiting for a software build.

Faster builds is one of the most direct ways of achieving this; an engineer has more opportunity to deliver software when not waiting for a software build.

But according to Gradle there are other, in my opinion far-fetched benefits.

“A faster build have less obvious benefits as well. In a primer on Speed, Performance, and Human Perception, Ilya Grigorik posits that mental context switches likely occur after just a few seconds — engineers using extremely fast build tooling are more likely to remain in a state of “flow” to overall be much more productive”

Taking that a bit further, a more productive developer due to faster builds will make the developer a more happy person who will go home and spend more time with their kids who happens to have a presentation the next day in school. All this positive vibe will make them give a brilliant presentation which will result in a higher grade which will allow him or her to attend university, do a PhD and in the end win a Noble prize. So, using gradle will make your kid a Noble prize winner.

Joking aside, since the use of Gradle in a setting with WSO2 is somewhat less relevant (our environment is already built, the only things to build are CAR files and possible java based extensions) we do not expect large improvements in building times.  

Automated conversion

But we should actually test the difference, Maven of course uses the POM file for building files, gradle has its own settings.

We can ‘convert’ the POM to a skeleton gradle project including build.gradle file. Just type in

$ gradle init

from the root project directory and let Gradle do its thing. That basically consists of parsing the existing POMs and generating corresponding Gradle build files plus a settings.gradle file if it’s a multi-project build.

This will create a structure that we can build with the command:

$ gradle build  

You’d hope that the new Gradle build includes any (custom) repositories specified in the POM, your external and inter-project dependencies, the appropriate plugins (any of maven, java, and war), and more.

However, the jar does not build. The reason is that Gradle does not make 3rd party libraries available by default. The custom handler POM (a copy from other projects) was built for compilations of multiple types of WSO2 extensions and therefore has many dependencies. Junit being one of them.

Adding Junit as a dependency (see also the Gradle User manual) is required.

Gradle Build Tool 4.3.1.png

Dude, where is my jar!

Whereas Maven puts a jar in the target directory. Gradle puts the file in the build/libs directory.

The JAR produced with Gradle is 1.24 KB (1,277 bytes) and the JAR produced with Maven is 1.83 MB (1,927,459 bytes). The size difference is due to the fact that little 3rd party libraries have been included by Gradle in the produced JAR. It is not that there are none, but the conversion of the POM to gradle left out most dependency definitions in the build file.

So, it is hard to compare since there are more dependencies in our Maven POM that will be included.

Hello World

Let’s create a simple java webservice, in fact let us generate the helloworld app from the maven-archetype-quickstart. As we’re just interested in how Maven and Gradle work we don’t bother about the implementation of the webservice. We just want to compare the output coming from both tools.

mvn archetype:generate -DgroupId=com.yenlo.wso2 -DartifactId=HelloWorld -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

The default web application has no dependencies nor does it implement anything sensible. To make things a bit more challenging lets add a dependency which we want to appear inside the WAR-file.

In the Maven pom we add the following:

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>21.0</version>
</dependency> 

Then we generate the gradle project by invoking ‘gradle init’. We get a, converted from maven, build.gradle file which we need to change a bit so that we get the same WAR-output from both Maven as well as Gradle.

We add the following in the build.gradle file:

apply plugin: 'war'

Now we run both the Maven build as well as the gradle build. We’ve done this multiple times so we can remove the dependency download-time influences.

Tool

Tool instruction

Filename

File size (bytes)

Build time

Maven

clean package

target/HelloWorld.war

2.240.779

7.341s

Gradle

build

build/libs/HelloWorld-1.0-SNAPSHOT.war

2.239.355

2.008s


Looking inside the Maven jar there are some maven related metadata files amongst which a copy of the POM in the JAR. This is the reason the maven –produced WAR file is slightly bigger.

Strikingly, Gradle is more then twice as fast than Maven. Ofcourse this is just a simple example but it does show that the claims the Gradle team makes about its performance do measure up.

Conclusion

It is good to see that gradle is an alternative for maven. It appears to be faster than maven, however it depends on the size of the build. In general, I did not build large jars or wars and as soon as I’ve done the first build the subsequent process for both tools is faster. I do not believe that true happiness is a faster build as gradle suggests, but it was nice to experience such a fast build.

There is the issue of course of creating new POM files or BUILD files depending on from which version you are coming. This will take some time and both tools have their own definitions and peculiarities.

Maven was build with a convention-over-configuration principle in its roots. Thus when you stip to the defaults then maven is relatively easy to use.

Gradle offers more speed and flexibility. This could however also be a negative aspect as the learning curve is more slant and thus it takes a longer time to understand Gradle.

But, most importantly, what are your colleagues, partners and suppliers using? WSO2 is heavily on Maven and it would make it more work if we would migrate to maven without other ecosystem partners doing the same.

Both Maven and Gradle build well, so it is a matter of preference.

Thanks to Thijs Volders for his contribution to this blog.

If you have any questions about this blogpost contact us via the comments section of this blog. View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product SupportWSO2 Development SupportWSO2 Operational Support and WSO2 Training Programs.

New Call-to-action

Care to share?
   
Picture of Rob Blaauboer
Published November 23, 2017

Rob Blaauboer

Rob is a Senior Business Consultant and Solution Architect with more than twenty years experience. In addition to his work he is an active blogger working on a number of articles on the ‘Internet of Things’ and a WSO2 ‘Getting Started with …’ series (WSO2 tutorial) in which he talks about WSO2 components and their purpose especially aimed at non technical readers. Rob is a WSO2 expert and official WSO2 trainer.

Responses

Stay up to date with the latest articles