Introduction
The history of software building is a journey from manual, error-prone labor toward automated, "intelligent" systems. Before specialized tools existed, developers were "program builders" themselves, stitching together code using raw shell commands. In case you prefer you can read this in Portuguese
The Era of Manual Compilation (Pre-2000)
In the early days of Java, building a project meant running the compiler (javac) manually. If you had 4 files and a couple of external libraries (stored as JAR files), your "build process" was a long, fragile string in a terminal.
Imagine you have Main.java, Utils.java, Data.java, and Config.java, and you need the json.jar and log4j.jar libraries. You would have to type:
# Compiling manually
javac -cp "lib/json.jar:lib/log4j.jar" -d bin src/*.java
# Packaging into a JAR manually
jar cvf MyProgram.jar -C bin .If you missed a semicolon or a file path, the whole thing collapsed. To fix this, developers wrote Makefiles (borrowed from C++), but these were platform-dependent and struggled with Java's directory structures.
Apache Ant: The First True Java Builder (2000)
Ant ("Another Neat Tool") replaced the messy shell scripts with XML. It introduced "Targets" (like clean, compile, and jar). However, Ant had no "brain" regarding libraries; you still had to manually download every JAR file and put it in a /lib folder.
Example build.xml snippet:
<project name="MyProject" default="compile">
<target name="compile">
<mkdir dir="build/classes"/>
<javac srcdir="src" destdir="build/classes">
<classpath>
<fileset dir="lib" includes="**/*.jar"/>
</classpath>
</javac>
</target>
<target name="jar" depends="compile">
<jar destfile="MyProgram.jar" basedir="build/classes"/>
</target>
</project>How to install
To Install ant, first go to their website to download it: Here You can follow the step-by-step with more details if you want here, but it is basically a matter of unziping the file you just downloaded, copying the folder to somewhere your user have read+write access(I usually have a folder called .apps in my /home/my-user and in there I create another folder called builders), then open the file ~/.bashrc or ~/.zshrc, go to the end of the file and add these two changes:
# File ~/.bashrc or ~/.zshrc
# ..... lots of lines
export ANT_HOME=~/.apps/builders/ant_folder
export PATH=$PATH:$ANT_HOME/binif export PATH=... already exists, make sure to not change what is already there but only add on the end of it :$ANT_HOME/bin, and don't forget the : before $ANT_HOME
Now go to you terminal and type:
ant --versionIf everything went well, you should see ant's version on your terminal.
All of these instructions are for Linux/Mac users, but can also work for Windows as well. The difference is where you create the ANT_HOME environment variable and where you and how you add it to PATH.
The containers
Web developing was becoming a big thing at the time and even though Ant came save developers in relation to building and packaging their projects, thus helping them to focus more on the core business than how to deploy it, there was still a small problem: External dependencies.
As a web applicatio consists of an application running on a server that other people will access through various means(most of the time a web browser), one could not carellessly upload code to a server, and with Ant you had to manually download all external libraries your application depended on, opening many possiblities for malicious code.
To help improve that, companies working on making web development easier came up with a brilliant idea: Containers. Don't confuse it with docker. The idea was that they would hand you a half baked web application filled with the bare minimum of libraries to start a simple or even intermediary level web application(whatever that means, i kind just invented this term).
You might have heard of these containers as they still live among us: Jboss, Tomcat, Glassfish, Websphere. You still had to manually download any other external dependencies you might have, like log4j, maybe a better jsf implementation(like richfaces or primefaces), etc, but it was a bit safer now as the number of things youd have to download was lesser.
Apache Maven: Convention over Configuration (2004)
The containers seemed to have improved management and decreased the need for downloading lots of dependencies at the beginning, but as time progressed, many new libraries to help decrease development time were created bringing the chaos back, so came Maven
Maven was a revolution. It introduced two world-changing concepts: a Standard Directory Layout (everyone puts code in src/main/java if it was a java application, src/main.scala for a scala application and so on and so forth) and Centralized Dependency Management called Maven Repository. You no longer "owned" JAR files; you just listed them in a pom.xml, and Maven downloaded them for you.
Example pom.xml:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>my-app</artifactId>
<version>1.0</version>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>
<version>20231013</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.3.0</version>
</plugin>
</plugins>
</build>
</project>These two libs would then proceed to be downloaded in a folder outside of your project(default to ~/.m2), and would only be added to your project if you needed to package the application making it a shared folder for as many applications as you wanted.
How to install
To Install maven, first go to their website to download it: Here You can follow the step with more details if you want here, but it is basically a matter of unziping the file you just downloaded, copying the folder to somewhere your user have read+write access(I usually have a folder called .apps in my /home/my-user and in there I create another folder called builders), then open the file ~/.bashrc or ~/.zshrc, go to the end of the file and add these two changes
# File ~/.bashrc or ~/.zshrc
# ..... lots of lines
export MAVEN_HOME=~/.apps/builders/maven_folder
export PATH=$PATH:$MAVEN_HOME/binif export PATH=... already exists, make sure to not change what is already there but only add on the end of it :$MAVEN_HOME/bin, and don't forget the : before $MAVEN_HOME
Now go to you terminal and type:
mvn --versionIf everything went well, you should see maven's version on your terminal.
All of these instructions are for Linux/Mac users, but can also work for Windows as well. The difference is where you create the MAVEN_HOME environment variable and where you and how you add it to PATH.
Gradle: Performance and Flexibility (2007)
As projects grew, Maven’s XML became bloated and rigid. Gradle arrived, ditching XML for a Groovy (or Kotlin) DSL. It combined Ant's flexibility with Maven's dependency management, while adding "Incremental Builds" to save time by only compiling what changed.
Example build.gradle:
plugins {
id 'java'
}
dependencies {
implementation 'org.json:json:20231013'
testImplementation 'org.junit.jupiter:junit-jupiter:5.9.2'
}
jar {
archiveBaseName = 'my-gradle-app'
manifest { attributes 'Main-Class': 'com.example.Main' }
}Just like maven, it uses the same repository where the jars are stored, the aforementioned Maven repository, but unlike maven that only supports JVM languages, you can use Gradle for languages such as C and C++, Python, Javascript, etc.
How to install
To Install gradle, first go to their website to download it: Here You can follow the step-by-step with more details if you want here, but it is basically a matter of unziping the file you just downloaded, copying the folder to somewhere your user have read+write access(I usually have a folder called .apps in my /home/my-user and in there I create another folder called builders), then open the file ~/.bashrc or ~/.zshrc, go to the end of the file and add these two changes
# File ~/.bashrc or ~/.zshrc
# ..... lots of lines
export GRADLE_HOME=~/.apps/builders/gradle_folder
export PATH=$PATH:$GRADLE_HOME/binif export PATH=... already exists, make sure to not change what is already there but only add on the end of it :$GRADLE_HOME/bin, and don't forget the : before $GRADLE_HOME
Now go to you terminal and type
gradle -versionIf everything went well, you should see maven's version on your terminal.
All of these instructions are for linux users/mac, but can also work for windows as well. The difference is where you create the GRADLE_HOME environment variable and where you and how you add it to PATH.
SBT: The Scala Standard (2008)
For the Scala ecosystem, SBT (Scala Build Tool) became the standard. It is highly optimized for the complex needs of Scala compilation but handles Java just as well. It uses the sbt-assembly plugin to create "Fat JARs" (one JAR containing all your code and all your dependencies).
Example build.sbt:
name := "MySbtProject"
version := "1.0"
scalaVersion := "2.13.12"
libraryDependencies += "org.json" % "json" % "20231013"
// Assembly plugin settings (requires project/plugins.sbt: addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "2.1.1"))
assembly / mainClass := Some("com.example.Main")
assembly / assemblyJarName := "my-fat-app.jar"How to install
To Install sbt, first go to their website to download it: Here You can follow the step with more details if you want here, but it is basically a matter of unziping the file you just downloaded, copying the folder to somewhere your user have read+write access(I usually have a folder called .apps in my /home/my-user and in there I create another folder called builders), then open the file ~/.bashrc or ~/.zshrc, go to the end of the file and add these two changes
# File ~/.bashrc or ~/.zshrc
# ..... lots of lines
export SBT_HOME=~/.apps/builders/sbt_folder
export PATH=$PATH:$SBT_HOME/binif export PATH=... already exists, make sure to not change what is already there but only add on the end of it :$SBT/bin, and don't forget the : before $SBT_HOME
Now go to you terminal and type
sbt -versionIf everything went well, you should see maven's version on your terminal.
All of these instructions are for linux users/mac, but can also work for windows as well. The difference is where you create the SBT_HOME environment variable and where you and how you add it to PATH.
Each of these tools represents a step toward the developer doing less "plumbing" and more actual coding.
Bonus track
It is worthy to mention that I focused on JVM language builders, even though gradle can work with non JVM, this post is essentially a simple history and tutorial for JVM languages(as I repeated 3 times by this time). So there are other builders for other languages, like cargo for Rust, Webpack for javascript, CMake for C, C++ and so on and so forth.
Even if I wanted to list all builders in here, it would be a huge list. So this is just a small subset, but I thin it is enough for you to get the idea. Knowing how to write a program is just the beginning of the story, building it later to deliver and deploy is just another chapter of this and it is always evolving.