Build automation #
Building a piece of software means converting source code into a program that can be executed.
Building a program may consists of many subtasks:
- generating code,
- compilation,
- linking,
- unit tests,
- file compression,
- generating documentation,
- creating an executable or an installer,
- integration tests,
- deployment,
- etc.
Each of these subtasks may be performed numerous times during the development of a program. So it is natural to automate the build.
A build automation tool is meant to facilitate the configuration of these tasks, and execute them automatically, typically as (one or several) “pipeline(s)”.
For instance, Maven is a build automation tool for Java. A Maven project is often build with a single command:
mvn package
Other popular build automation tools include:
- Make, CMake or Ninja for C/C++,
- MSBuild for C#,
- Grunt or Gulp for Javascript,
- Gradle (multi-language),
- sbt for scala
- etc.
Note. Some subtasks of a build may be performed on a server (e.g. each time a developer pushes a git branch), as part of a process called continuous integration (CI). Popular frameworks to set up a CI server include Jenkins and Travis CI. CI is beyond the scope of this course.
in Java: Maven vs Gradle #
The two most popular build automation tools for Java are Maven and Gradle.
Both also act as package managers for Java libraries.
Maven is slightly older (2004 vs 2008), and influenced the design of Gradle.
Maven #
Maven is (still?) more widely used than Gradle. It also has a gentler learning curve.
In particular, Maven relies on a number of implicit conventions (e.g. for directory layout). For a simple project, this often results in a quicker set up than with Gradle (but makes advanced customization more involved).
Due to the popularity of Maven, some of these conventions (e.g. directory layout and artifact naming) have also been adopted in other contexts.
Additional strengths of Maven are:
- excellent integration with IDEs,
- a vast ecosystem of plugins.
A common criticism of Maven is the use of XML files to specify a project’s build, which can be verbose and difficult to parse (for a human being).
In this course. For simplicity, this chapter (mostly) focuses on Maven. In addition, the content is restricted to the bare minimum (i.e. what you are likely to need for your project).
For a more thorough introduction to Maven, a good entry point is the official getting started guide.
Gradle #
Gradle is a multi-language build automation tool. Among others, it offers support for project written in Java and its main derivatives (Groovy, Kotlin and Scala), C/C++ and Javascript. Gradle has been selected by Google as the official build automation tool for Android applications.
Gradle has a more concise syntax than Maven (precisely two: one is a Groovy Domain Specific Language (DSL), the other is a Kotlin DSL). Re-building a project can also be faster with Gradle than than with Maven, thanks to more advanced caching strategies. Another strength of Gradle is its flexibility : a build can be easily customized, whereas Maven relies on conventions that can be hard to bypass.
Gradle is often considered more difficult to learn than Maven, especially for new programmers. Its syntax is also less stable (older project configurations need to be updated to comply with more recent releases).
Note. If you chose the board game as your project, then you will use Gradle (at least by default).
The build is already configured. By default, you do not need to modify it, except maybe to declare dependencies.