Stufe 6·Professionelles Java

Build Automation Tools

Maven and Gradle: project models, lifecycles, dependencies, and packaging JARs.

16 Min. LesezeitFortgeschritten

Deutsche Übersetzung in Arbeit

Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.

Auf dieser Seite

Real projects have dozens of dependencies, compile steps, tests, and packaging to manage. Doing this by hand is impossible. Build tools - Maven and Gradle - automate the whole lifecycle: fetch libraries, compile, test, and package your app into a distributable artifact.

What a build tool does

A build tool is like a general contractor

You don't personally source every brick, mix concrete, and wire the electrics to build a house - a contractor coordinates it all from a plan. A build tool reads your project's plan and handles fetching dependencies, compiling, running tests, and packaging - reliably and repeatably, for you and every teammate.

Core jobs:

Dependency management - download the libraries you declare (and their dependencies) from repositories like Maven Central.
Build lifecycle - compile → test → package, in the right order.
Reproducibility - everyone builds the same way, on any machine or CI server.

Maven - convention and XML

Maven uses a pom.xml file and favors convention over configuration. Declare dependencies, and Maven fetches them automatically.

<project>
  <groupId>com.myapp</groupId>
  <artifactId>shop</artifactId>
  <version>1.0.0</version>

  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>5.11.0</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Common commands:

mvn compile      # compile source
mvn test         # run tests
mvn package      # build a JAR
mvn clean install  # full clean build, install to local repo

Maven's lifecycle runs phases in order: validate → compile → test → package → verify → install → deploy. Running a later phase runs all earlier ones.

Gradle - flexible and fast

Gradle uses a concise build script (Groovy or, preferably, Kotlin DSL) and is known for speed and flexibility.

// build.gradle.kts
plugins {
    java
}

dependencies {
    testImplementation("org.junit.jupiter:junit-jupiter:5.11.0")
}

./gradlew build    # compile, test, and package
./gradlew test     # run tests

Maven or Gradle?

Both are excellent and widely used. Maven is simpler and ubiquitous in enterprise Java - great for learning. Gradle is more flexible and faster on big projects, and is the default for Android. You'll meet both; the concepts (dependencies, lifecycle, artifacts) transfer directly.

Understanding dependencies

You declare a dependency by its coordinates: group, artifact, and version (e.g. org.junit.jupiter:junit-jupiter:5.11.0). The tool fetches it and everything it needs (transitive dependencies), resolving conflicts.

Mind your dependencies

Every dependency is code you now rely on - and a potential source of bugs or security vulnerabilities. Keep them updated, prefer well-maintained libraries, and don't pull in a huge framework for a one-line need. Tools can scan for known vulnerabilities.

Packaging: the JAR

The usual output is a JAR (Java ARchive) - a zip of your compiled .class files. An executable ("fat" or "uber") JAR bundles your dependencies too, so it runs standalone:

java -jar shop-1.0.0.jar

Quick check

What is a build tool's dependency management responsible for?

Key takeaways

Build tools automate dependency management, compiling, testing, and packaging - reproducibly.
Maven uses pom.xml with a fixed lifecycle (compile → test → package → install).
Gradle uses a concise Kotlin/Groovy script and is fast and flexible.
Declare dependencies by coordinates (group:artifact:version); the tool fetches transitive deps too.
Keep dependencies updated and minimal - each is code and risk you take on.
Projects package into JARs; a fat/executable JAR bundles dependencies to run standalone.

With building handled, let's survey the big Java frameworks that structure real applications.