This week I spent some time focusing on Build Automation tools including Ant, Maven and Gradle.  In the past, I would consult with clients on best practices for writing Ant scripts to build Java applications for deployment to IBM WebSphere Application Server.  

To get the end result of an application, the code must go through a build process.  In a nutshell, a build is the process of gathering the source code files, compiling them and creating an artifact such as a JAR, WAR, etc. to deploy to a server/instance for users to access.

The basic steps to the build process include gathering the code from a SCM such as GitHub/GitLab, compiling the code, checking the dependencies and running automated tests (can be Unit, Integration, etc.). When these hurdles are cleared, an artifact (JAR, WAR, etc) is created and stored in an artifact repository such as AWS CodeArtifact or JFrog ArtiFactory. They provide notifications as feedback along the way.   

Automating the build provides Enterprises with improved product quality, a precursor to continuous integration. The increased productivity across the SDLC ultimately leads to saving time and money.    

The table below provides a comparison of Ant, Maven and Gradle.

This leads me back to my title - Configuration vs Convention…or a little bit of both.  Ant is all about configuration.  Using XML the software engineer focused on defining each phase in the build process manually. Ant doesn’t impose any conventions or project structures.  Its main benefit is flexibility.  It was a step up from the Make tool.  Ant uses Apache Ivy since it doesn’t have built-in dependency management.  Ultimately this configuration approach became cumbersome and frustrating dealing with unmanageable XML build files.  Now the industry called for convention and Maven was born.  

Maven’s focus is project management of the build project.  While it still uses XML, it relies on conventions for project structure (pom.xml).  Software engineers no longer have to manually define the build process because Maven provides built-in commands.  It has built-in support for dependency management.  Maven’s functionality is driven by plugins, of which it has several built-in. The Maven community has also created plugins to extend Maven’s functionality.  With convention came less flexibility.  The industry needed a tool that was a little bit of both.  Now enters Gradle.  

Gradle was built upon the concepts of Ant and Maven. Gradle moves away from using XML for build scripts to using domain-specific language (DSL) or Groovy for creating its build scripts.  Like Maven, it relies on plugins for its functionality.  It supports declarative builds as well as conventional builds and provides a structured build for projects.   

The good news is that there is a tool for that! If your Enterprise leans heavily on configuration - Ant is the tool for that.  If your Enterprise leans towards convention - Maven is the tool for that.  If your Enterprise is a little bit of both - Gradle is the tool for that!  

Remember SHARING KNOWLEDGE IS POWER and KEEP LEARNING!