Why build tools

Written Explanation

What "building" means

Source code is not what runs. Before a project is useful, several steps have to happen:

1. Compile: turn .java files into .class files with javac.
2. Test: run the automated tests (module BEG-045) against the compiled classes.
3. Package: bundle the classes into one file, usually a JAR (Java ARchive, a zip-like file with the extension .jar), that can be shared or deployed.

Together these steps are the build. On top of them sits a fourth chore: getting the libraries your code uses.

Libraries and dependencies

Most programs use code written by others: a library that formats dates, talks to a database, or parses JSON. Such a library is a dependency of your project: your code depends on it. A library normally arrives as a JAR, and javac must be told where it is.

Suppose your project uses one class from Apache Commons Lang, a well-known helper library. Compile the file without telling javac about the JAR and you get this (real output):

src\main\java\com\example\Shout.java:3: error: package org.apache.commons.lang3 does not exist
import org.apache.commons.lang3.StringUtils;
                               ^

The compiler is not wrong: it has no way to know where that code lives. You must pass the JAR's location on the class path (the list of places where Java looks for compiled classes) with -cp. And when you run the program, Java needs the class path again. Real output without it:

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/lang3/StringUtils

The manual way

Here is what the full manual routine looks like for a tiny project with one library (paths shortened for readability):

javac -cp "libs/commons-lang3-3.21.0.jar" -d out src/main/java/com/example/*.java
java  -cp "out;libs/commons-lang3-3.21.0.jar" com.example.Shout

On Windows the class path separator is ;, on Linux and macOS it is :. Already a command that works on one teammate's laptop fails on another's. Now imagine the real case.

Why it does not scale

Count what a real project asks of you:

• Many libraries. A library often depends on other libraries (its own dependencies), which depend on others. A project with ten direct libraries can easily need dozens of JARs on the class path. You would list each one by hand.
• Manual downloads. You find each JAR on a website, download it, keep it in a folder, and copy that folder to every machine. You also have to check that two libraries do not want different versions of a third.
• Long, fragile commands. One missing path, one wrong separator, one forgotten source folder, and the build fails or, worse, builds the wrong thing.
• No repeatable steps. Compile, then compile the tests with the test library on the class path, then run the tests, then create the JAR: four commands that each person remembers a little differently.
• No shared truth. Which version of the library did the project use last month? The answer lives in somebody's download folder.

A shell script could hide some of this, but then every team writes its own scripts, and nobody can join a new team and know how its project builds.

What a build tool does

A build tool reads a description of the project and runs the build steps for you, in a fixed order, the same way on every machine. In recipe terms, the card is a file that lists the project's name, the Java version, the libraries it needs, and the steps. The assistant is the tool: it fetches the ingredients (downloads libraries) and follows the steps (compile, test, package).

That gives the two jobs from the lecture:

1. Run the build steps (compile, test, package) with one short command.
2. Manage dependencies: you write down which libraries you need, and the tool downloads them, and the libraries they need, from a public repository.

A bonus follows from these two: because the card is a file in the project, it is committed to Git like source code (module BEG-046), so a new teammate clones the project and builds it with the same command as everyone else.

Maven and Gradle

The two main build tools in the Java world are Apache Maven and Gradle. They solve the same problem with different styles: Maven describes the project in an XML file called pom.xml and follows fixed conventions, while Gradle uses a script file and is more flexible. This course uses Maven: it is very common in backend jobs, and its strict conventions are easier for a beginner to learn. Everything you learn about build tools transfers to Gradle.

Where the analogy stops

A real kitchen assistant understands what you want. A build tool only follows the card. If the card says the wrong library version, Maven will faithfully fetch the wrong one. The card is your responsibility, which is why the next lessons teach you to read and write it.