Build Tools

What is a build tool? #

A build tool is a programming utility that automates a software build task, such as compiling source code, cleaning temporary files, and so on. A popular open source build tool is Make, another popular build tool is Maven

GNU Make #

Make is a build tool released by GNU. Make was original designed to work with C source code. Make configurations are specified by a text file named Makefile.

Makefile #

A programmer specifies how to build program from a file called a makefile, which lists a bunch of rules, each of which specifies the target, dependencies and commands.

Once you create a makefile, you don’t have to meticulously track details of how to build the file again, because the details are recorded in the makefiles you prepared. You can use make with any language.

An example of a make file:


To run the make file, you can run make in a terminal.

Alternatively you can name your makefile with any name an run it with the -f flag option like so make -f myFile.mak

Apache Maven #

Maven is a build tool released by The Apache Software Foundation, which is a non-profit organization that maintains many open source software. Maven is a build tool and also a project management tool.

Maven Project #

The workspace concept with Maven is at the unit of a project. A Maven project must have a pom.xml file at the root directory as a way to configure the project specific information. It works like a recipe in specifying the dependencies required for the project (i.e. any open source libraries used) and also specifying the way the project should be built.

Maven Commands #

The syntax for running Maven in a terminal is a pattern as follows:

mvn [options] [<goal(s)>] [<phase(s)>]

mvn is the program and the following are parameters provided to the program.

Available options for each of the parameters can be found by checking the manual page using man mvn

Creating a Maven project from Scratch #

The instructions for getting started are on Maven’s website, under the page Maven in 5 minutes. This would be a good starting point to see the whole process however take your time to read through the docs to figure out specific configuration settings.

Basically, from the root directory of your project, run this in a terminal:

mvn -B archetype:generate -DgroupId=myApp -DartifactId=maven-example

This would create a pom.xml file in the folder maven-example with maven’s project structure within it. The flag -DgroupId is how you name your project and here the name myApp is given.

Explaining the pom.xml configiguration file #

There are a few things to configure for a maven build project. Keep in mind that this is an XML file so it means you should know generally how an XML file is structured. XML files use tags, arranged in nested order like tree nodes. It can be thought of as a text-based database. It uses the file extension .XML

  • Java Version

    To use Java 8, you can specify it for your project like so:

  • Project Libraries to include (dependencies)

    In order to include dependencies you would include each dependency under the dependencies block.


    More dependencies can be found within the Maven repository.

  • Build Plugins

    Plugins can be helpful. If there is any that you would like to add, it would be under a block like so.


Project File structure #

The code you’re working with can be found under the root directory under the path src/main/java/package/

In your file under this path, such as, that’s where you can import libraries at the top of the file.

Maven figures out for you how to install and connect everything so you don’t have to worry about manually maintaining where files should go.

Compile and Run #

Once the configuration file is set up, all you have to worry about during and after development is to compile your project with ease.

When successfully built, Maven will produce an executable file under a target directory under root.

Collaborating on a Maven project #

A software team can collaborate on a Maven project. In order to answer how a software team can collaborate we assume for specific description here that the version control system (VCS) used by the team is Git (there are many other VCS).

Let’s first describe the VCS workflow and assume team hosted the project on a github as the central remote repository.. Every member of the team can clone the repository. This means each member now has a copy of the project on their local machine. Git is designed where any clone can access the full history and has full read/write permissions on all the files. Any changes that any single person makes… this person adds changes, commits it (to produce a revision or snapshot on the commit log), then pushes to the central area (github).

Next, let’s say the team is working on a Java project and uses Maven to configure the Java dependencies and build/packaging concerns. Since every Maven project has a pom.xml configuration file in the root directory of the project, every single team member with the same pom.xml and same source code should theoretically have the same project. The pom.xml configuration file is like a recipe. If Member A changes the project to Java 11, then the pom.xml is updated, he/she/they tests that it won’t break. Once test passes commits changes and pushes up. Other team members can then pull changes (i.e. download updates from that github link) and then see an updated pom.xml. Hmm maybe that was not a good example to demonstrate the advantages of Maven, because now everyone else has to have Java 11 on their machine for the project to build.

Another example.. if a team member adds a new dependency and says so in the pom.xml - Maven checks against its own repository (it’s like an app store for maven and if a new team member doesn’t have dependencies maven will know to download and link it. This is an example of why developers often write a short list of dependencies in their README files… because if they work on a team, and they onboard someone new it’s easier to say, here’s all the stuff you need before you begin. Developers also often include brief instructions on how to build and run the program they produced also.

Choosing a Build tool #

Picking a build tool boils down to what you like, which supports your needs.

If you’re on linux, GNU Make is a great choice.

If you’re solely working on Java programming projects (for desktop GUI, other programs, android apps, etc) Apache Maven is a good choice. There are other similar build tools available for Java development such as gradle, ant, etc.