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_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:Usersrob>gradle -v---------------------------------------------------------Gradle 4.3---------------------------------------------------------Build time: 2017-10-30 15:43:29 UTCRevision: c684c202534c4138b51033b52d871939b8d38d72Groovy: 2.4.12Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015JVM: 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.
Boxing ring stage by Mac Morrison
Faster builds
Gradle says that it allows its organizations to 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.
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 Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.
