The previous lesson ended with an uncomfortable question: what exactly is mvn test?

You have typed it five times. You have put <scope>test</scope> on a dependency without knowing what it means. You have seen spring-boot-starter-parent, maven-surefire-plugin and spring-boot-maven-plugin appear in a pom.xml and taken them on trust. You have run mvn spring-boot:run and mvn dependency:tree. And in 11-01 there was talk of groupId:artifactId:version coordinates as preparation for this lesson.

This lesson explains the tool that has been holding up the previous three.

Maven is the standard build tool of the Java ecosystem. Its job is to turn your source code and a configuration file into a runnable artifact, resolving the dependencies along the way, running the tests and guaranteeing that the process gives the same result on any machine.

That last point is the most underrated one. Up to module 10, BiblioTech was compiled with javac and a hand-written classpath. With the forty jars Spring Boot has brought in, that is no longer tedious: it is impossible. And there is an underlying reason that goes beyond convenience, and that links back to Log4Shell (11-01): the ability to respond to a vulnerability depends on being able to change a version with one line and verify with one command that nothing broke. You got the second half in 11-04 with JUnit. Here comes the first.

By the end you will understand what problem a build tool solves; you will be able to read and write a complete pom.xml; you will master dependencies, their scopes, transitivity and conflict resolution; you will know the life cycle and its phases; you will know what a plugin is and what the ones you use do; you will handle profiles and multi-module projects; and you will have the judgement to choose between Maven and Gradle.

And BiblioTech will be a complete, reproducible Maven project.

1. The problem: javac by hand
2. What a build tool solves
3. Convention over configuration
4. The standard directory layout
5. Installation and verification
6. The POM: coordinates
7. SNAPSHOT versus a released version
8. properties: POM variables
9. BiblioTech's complete pom.xml
10. Dependencies: declaration and repositories
11. Dependency scopes
12. Transitive dependencies
13. Conflict resolution: the nearest definition
14. mvn dependency:tree in practice
15. exclusions
16. dependencyManagement versus dependencies
17. The BOM and spring-boot-starter-parent
18. The life cycle: three chains
19. The phases of the default chain
20. Plugins and goals
21. The plugins BiblioTech uses
22. surefire versus failsafe
23. Packaging: maven-jar-plugin, shade and spring-boot-maven-plugin
24. Profiles
25. Multi-module projects
26. settings.xml and credentials
27. The Maven Wrapper
28. Day-to-day commands
29. Reproducibility and pinning versions
30. Maven versus Gradle
31. BiblioTech as a complete Maven project
32. Common Mistakes and Tips
33. Exercises

Let us go back to module 1. This is how BiblioTech was compiled and run:

It works with ten files and zero dependencies. Now look at what it would take today:

And that only compiles. Afterwards you would have to:

1. Copy the resources from src/main/resources into target/classes.
2. Compile the tests with another classpath (the production one plus JUnit, AssertJ and Mockito).
3. Run the tests by invoking JUnit's launcher by hand.
4. Package it into a jar with a correct MANIFEST.MF.
5. And before any of that, download the forty jars by hand, with their exact, mutually compatible versions.

Point 5 is the killer. Downloading spring-boot-starter-data-jpa means finding out that it needs Hibernate, that Hibernate needs jakarta.persistence-api, ByteBuddy, Jandex, Classmate and Antlr, that ByteBuddy needs... and doing it with versions that do not clash. By hand it is days of work that has to be redone at every update.

It is called dependency hell, and it is the main problem Maven solves.

And a cultural consequence that matters: every Maven project builds the same way. Somebody hands you an unfamiliar repository, you see a pom.xml, you type mvn package and it works. No documentation to read, nobody to ask.

This is Maven's design principle, and it explains why its configuration is so short.

If you follow the conventions, you do not have to configure anything. You only configure what departs from them.

Maven assumes that:

• The source code is in src/main/java.
• The resources are in src/main/resources.
• The tests are in src/test/java.
• The test resources are in src/test/resources.
• Everything generated goes into target/.
• Every *Test.java file is a test.

That is why in 11-04 you put the tests in src/test/java and mvn test found them without you configuring anything. It was not magic: it was the convention.

The alternative —explicit configuration, like Ant— requires declaring every path, every task and every dependency between tasks. The result is three-hundred-line build files, different in every project, that you have to read before understanding anything.

The trade-off is real: if your project does not fit the conventions, Maven becomes awkward. It is the price of uniformity, and for the vast majority of Java projects it is worth paying.

Two golden rules:

1. target/ never goes into git. It is all regenerable. Your .gitignore must contain target/.
2. src/ is never touched by hand from the build. It is the source, and it is the only thing in the repository besides the POM.

Check three things: Maven's version (3.9.x is the current one), Java's (17 or above for this course) and the platform encoding, which must be UTF-8 to avoid problems with accented characters.

If you do not have it installed, section 27 will give you a very good reason not to need it.

Creating a project from scratch:

In practice, for a Spring Boot project people use Spring Initializr (start.spring.io), which generates the POM, the wrapper and the main class already configured.

The POM (Project Object Model) is the pom.xml: the complete description of the project.

The first three form the groupId:artifactId:version coordinates you already saw in 11-01. They determine the path in the repository:

Values for packaging:

The version has two very different natures:

The practical consequence: if you depend on bibliotech-core:1.0.0-SNAPSHOT, Maven checks daily whether there is a newer version. If you depend on 1.0.0, it downloads it once and never looks again.

Professional rule: a released version is never overwritten. If 1.0.0 has a bug, 1.0.1 is published. Republishing 1.0.0 with different content breaks reproducibility for everybody who already had it cached, and it is one of the worst things you can do in a shared repository.

And its corollary: never depend on a SNAPSHOT in production. It builds today and tomorrow with different content.

Forcing snapshots to update:

They are used with ${name}:

The advantage: when fifteen dependencies share a version (the whole Jackson ecosystem, for instance), you change it in one place.

project.build.sourceEncoding is genuinely important: without it, Maven uses the platform encoding, and building on a Spanish Windows machine and on a UTF-8 Linux server can produce different results. Maven emits a WARNING if it is missing.

There are also useful predefined properties: ${project.version}, ${project.artifactId}, ${project.basedir}, ${maven.build.timestamp}.

This is the complete, commented POM, with everything the project needs after four lessons:

An important detail: no Spring dependency carries a <version>. The parent manages them. We will come back to that in section 17.

A dependency is declared with its coordinates:

Where does the jar come from? Maven looks in three places, in this order:

Adding an extra repository (avoid it if you can):

Professional tip: the fewer repositories, the better. Each one adds a source of artifacts you have to trust. The usual practice in a company is to configure a single corporate mirror in settings.xml (section 26) that in turn replicates Central: that way there is one control point, cached and auditable.

The scope determines which classpath a dependency is available on and whether it is packaged.

The two you have already used without knowing it:

runtime for H2. Your code never writes import org.h2.Driver. Only the running JVM needs it, when Hibernate loads the driver by name. Putting it in runtime means you cannot use it in your code by accident: if somebody writes a class that imports something from H2, it does not compile. That is a free architectural barrier.

test for JUnit and AssertJ. They are available when compiling and running tests, and they are not packaged into the final jar. That is what keeps your production application from carrying a testing framework inside it — with its weight and its attack surface.

provided deserves a note: it means "at run time this will already be there, do not package it". Its classic case was the Servlet API in a .war, provided by the application server. Today, with embedded servers, it is used mainly for Lombok (11-07), which only acts at compile time.

Seeing the resulting classpath:

Here is the feature that makes Maven worth it.

When you declare one dependency, Maven also downloads its own, and theirs, recursively.

That single declaration brings in, among others:

Nearly thirty artifacts you never named. Without Maven, you would have to find each one, work out the compatible version and download it by hand.

And there you can see something 11-03 took for granted: ByteBuddy is in your project because Hibernate uses it to generate the proxy subclasses for lazy loading. It is module 10's mechanism, with a name and coordinates.

An important rule about transitivity: test and provided dependencies do not propagate. If BiblioTech depended on a library that uses JUnit in its tests, you would not inherit JUnit. That is correct: somebody else's test dependencies are none of your business.

With thirty transitive dependencies, it is inevitable that two of them will ask for different versions of the same thing:

There can only be one version of a class on the classpath. Which one wins?

The nearest-definition rule (nearest definition wins): the version that is fewest hops away from your POM wins. On a tie, the one declared first wins.

A very useful practical consequence: declaring a dependency explicitly in your POM gives you absolute control over its version, because it will always be at depth 1 and beat any transitive one.

The rule is deterministic, but it can surprise you: "the newest" does not win, "the nearest" does. If a nearby transitive asks for an old version, that old one wins, and you can end up with a NoSuchMethodError at run time — the classic symptom of a version conflict.

Diagnosis:

That omitted for conflict with tells you exactly which version was discarded and in favour of which.

It is the diagnostic tool that will get you out of trouble most often. Four concrete uses:

1. Seeing the whole tree:

2. Finding who drags an artifact in (11-01's security question):

There is the answer to "do I have Log4j and who pulled it in?", which in December 2021 cost half the industry weeks of work.

3. Seeing resolved conflicts:

4. Detecting dependencies declared but unused, or used but undeclared:

That first warning points at a real risk: you are using SLF4J in your code but you get it transitively. If tomorrow Spring Boot stops bringing it in, your code stops compiling without you having touched anything. Whatever you use directly, declare directly.

Sometimes you have to remove something that arrives transitively. Real cases:

That third case is important and you will see it in 11-07: two logging implementations on the same classpath fight each other and the result is that nothing gets logged, or everything gets logged twice.

To exclude a dependency's entire tree in one go:

Use it carefully: it is easy to remove something that was needed and find out at run time.

Two sections that are constantly confused.

What it is for, three uses:

1. Centralising versions in a multi-module project: the parent declares them, the modules use them without a version.
2. Forcing a transitive's version without declaring it as a direct dependency. Very useful for patching a vulnerability: if a transitive has a CVE, here you impose the fixed version.
3. Importing a BOM, which is what the next section is about.

Point 2 deserves an example, because it is the rapid-response tool against vulnerabilities:

dependencyManagement always wins over transitive resolution, regardless of depth. It is the correct way to patch without waiting for the intermediate library to update.

A BOM (Bill of Materials) is a POM of type pom that contains only dependencyManagement: a catalogue of versions tested together.

It is used in two ways.

Way 1: inheriting from the parent (what BiblioTech does):

That gives you:

Way 2: importing the BOM (when you already have another parent, typical in a company):

And now the warning that appeared in 11-02 makes complete sense:

Do not put a <version> on dependencies the BOM manages.

If you write <version>2.15.0</version> on Jackson, you are overriding the version the Spring Boot team tested with that version of Spring, of Hibernate and of the rest of the ecosystem. You can end up with subtle incompatibilities: a NoSuchMethodError at run time, six months later, in production.

If you really need another version, the correct way is to override the property:

Maven has three independent life cycles, each with its own phases:

mvn site generates a website with project reports. It is little used today; most teams use other reporting tools.

And here is Maven's key idea:

Running a phase runs every previous phase.

That is why mvn test compiled your code in 11-04 without being asked: test comes after compile.

The complete list, with the intermediate phases that also exist:

Which to use in each situation:

A nuance about install: lots of people type mvn clean install out of habit for everything. It is slower than necessary and fills ~/.m2 with local artifacts. To verify, mvn verify is enough; install is only needed when another local project is going to consume your artifact.

And here is the second key idea:

Maven does nothing by itself. Everything is done by plugins.

A phase has no code: it is a hook point. What happens at compile is that the compile goal of the maven-compiler-plugin plugin runs.

The default bindings for packaging=jar:

A goal can also be invoked directly, with no life cycle, using the plugin:goal syntax:

That last one is a diagnostic gem: mvn help:effective-pom shows the complete POM after applying the parent's inheritance, with every version and configuration resolved. When you do not understand where a setting comes from, look there.

About <release>17</release> versus <source>/<target>: release is better because on top of setting the language level, it verifies that you only use API that exists in Java 17. With source/target you can compile code using a Java 21 method with JDK 21 and generate bytecode 17 that will fail at run time with NoSuchMethodError. release prevents that at compile time.

About <parameters>true</parameters>: it keeps the parameter names in the bytecode. Spring needs them (for @Value without an explicit name) and so does Jackson (11-07) to map constructors.

You already used it in 11-02. It provides:

Both run tests. Their difference is the next section.

That difference in behaviour on failure is not a whim. An integration test may have started a database or a container in pre-integration-test. If failsafe stopped dead, those resources would be left dangling. That is why failsafe always lets the tear-down run and only fails when it reaches verify.

A practical consequence everybody falls for:

If you write LoanRepositoryIT.java and run mvn test, it does not run and there is no warning at all. Everything looks fine.

Applied to BiblioTech, with the tags from 11-04:

That way the fast development cycle (mvn test) takes seconds, and continuous integration (mvn verify) runs everything.

Three ways to produce a runnable artifact, with different properties.

It produces a jar with only your classes. To run it you have to supply the complete classpath:

It is what you use to publish libraries, where the consumer resolves the dependencies.

It unpacks every dependency and puts them mixed together into a single jar. It works, but it has a known problem: if two jars have files with the same name under META-INF/services —very common—, one overwrites the other and something stops working mysteriously. It is solved with transformers, but you have to know about it.

It is the one BiblioTech uses. You already saw its structure in 11-02: it keeps every dependency as a separate jar inside BOOT-INF/lib/ and provides its own class loader.

That row about layers matters for 12-06: the Spring Boot jar can be split into layers (dependencies, snapshot dependencies, resources, application classes) so that a Docker image only has to rebuild the layer that changed. Since dependencies change far less than your code, a deployment goes from uploading 50 MB to uploading 200 KB.

To run any class without Spring Boot:

Useful for utilities and maintenance scripts inside the project.

A profile activates conditional configuration. Not to be confused with the Spring profiles from 11-02: those affect beans at run time; these affect the build.

Activation:

Seeing which profiles are active:

A warning: do not put business logic into Maven profiles. If the artifact you build differs depending on the profile, you are no longer testing what you deploy. Modern practice is to build a single artifact and configure it at run time with environment variables (11-02, 12-06).

When a project grows, it is split into modules. It is what BiblioTech will need in 12-01.

The parent POM:

A child module:

From the root:

The real benefit is not organisational, it is architectural: bibliotech-domain cannot use Spring or JPA, because it does not have them on its classpath. Maven enforces the layer separation that in a single-module project depends on the team's discipline. It is a boundary verified by the build, and it is very powerful.

It is developed in 12-01.

While pom.xml describes the project and goes into git, settings.xml describes your machine and never goes into git.

Locations: ~/.m2/settings.xml (user) and ${maven.home}/conf/settings.xml (global).

Security warning. Credentials never go into the pom.xml, because the POM goes into the code repository and stays in its history forever. They go into settings.xml, and preferably read from environment variables as in the example. Maven offers mvn --encrypt-password to encrypt them with a master key, although that is no substitute for a secrets manager.

And a rule that really is absolute: a secret that has been in git is considered compromised forever. Deleting it in a later commit does not remove it from the history. If it happens, the credential must be rotated. Secrets management is covered in 12-07.

A real problem: you use Maven 3.9.8, a colleague has 3.6.3, the continuous integration server has 3.8.1. Something fails on only one of the three. Diagnosing it costs a day.

The Maven Wrapper solves it: a script in the repository that downloads and uses the exact version of Maven the project declares.

It generates:

And from then on:

Advantages:

1. Everybody uses the same version, without exception.
2. Maven does not need to be installed to build the project. Only Java.
3. The version is in git, so changing it is a reviewable commit.
4. Continuous integration needs no configuration at all.

These files do go into git (unlike settings.xml). Spring Initializr generates them by default, and it is standard practice today: a modern Java repository builds with ./mvnw verify with nothing installed but a JDK.

Three practical notes:

• -DskipTests versus -Dmaven.test.skip=true: the first compiles the tests but does not run them (it catches compilation errors in them); the second does not even compile them. Prefer the first.
• -o (offline) is useful on a train or with the network down, if you already have everything in ~/.m2.
• -T 1C can halve the time of a large multi-module project. It is safe if the plugins you use support parallel execution, and the usual ones do.

And for the periodic update of dependencies:

Running it every few weeks and applying the patches is one of the most profitable hygiene practices there is, and the direct answer to the Log4Shell lesson.

The same git tag must produce the same artifact, today and three years from now. That is reproducibility, and it is what lets you rebuild an old version to debug an incident.

Things that break it:

That second-to-last point is real and always forgotten: if you do not pin a plugin's version, Maven uses the latest available and your build can change behaviour without you having touched anything. spring-boot-starter-parent pins the usual plugins; for the rest, give them a version.

Reproducibility is not theoretical. The day there is an incident in version 1.4.2 that was deployed eight months ago, you will have to rebuild it exactly in order to debug it.

The two dominant tools. An honest comparison:

An example of the same project in both:

Gradle is obviously more concise. And that is also where its risk lies: because the build file is code, a team can end up with conditional logic, custom tasks and behaviour that has to be read and understood before touching anything. A three-hundred-line pom.xml is boring but you understand it at a glance; a hundred-line build.gradle.kts can do anything.

Why this course uses Maven:

1. It is the majority in Java enterprise back-end work: it is what you will run into.
2. It is easier to learn: you do not have to learn a language on top of the tool.
3. It is predictable: the life cycle is always the same, and that is exactly what you want while you are learning everything else.
4. Spring Boot's documentation uses Maven in its main examples.

And a professional recommendation: learn Maven first, and Gradle when you need it. The concepts —coordinates, scopes, transitivity, life cycle, plugins— are the same in both. The syntax is what changes.

The result. Final structure:

The minimum .gitignore:

And the complete cycle:

Output of ./mvnw clean verify:

The whole lesson is in that output: the phases in order, the plugins each one runs, surefire with the 41 unit tests, the jar, Spring Boot's repackage and failsafe with the 3 integration ones.

Compared with the starting point:

That second-to-last row is the complete answer to Log4Shell: one line to change the version, one command to verify that nothing broke.

Mistake: putting a <version> on dependencies the BOM manages. You override tested versions and cause subtle incompatibilities that show up at run time. If you need another one, override the property.

Mistake: using version ranges or LATEST. They break reproducibility. Concrete versions, always.

Mistake: believing that mvn test runs the integration tests. The *IT ones are run by failsafe, in mvn verify. And there is no warning that they were not run.

Mistake: not pinning plugin versions. Maven uses the latest available and your build changes without you touching anything.

Mistake: committing target/ to git. It is all regenerable, it takes up a lot of space and it causes constant conflicts.

Mistake: credentials in the pom.xml. The POM goes into git and stays in the history forever. They go into settings.xml, and a secret that has been in git has to be rotated.

Mistake: mvn clean install for everything. It is slower than necessary and it fills ~/.m2. To verify, mvn verify.

Mistake: -DskipTests in continuous integration. That is exactly where they must run.

Mistake: not declaring a dependency you use directly. If it reaches you transitively and tomorrow the intermediary stops bringing it in, your code stops compiling. mvn dependency:analyze detects it.

Mistake: source/target instead of release. It lets you compile code that uses API missing from the target version, and the failure appears at run time.

Mistake: forgetting project.build.sourceEncoding. Accented characters get corrupted differently depending on the machine.

Tip: always use the Maven Wrapper. It eliminates a whole class of "it works on my machine" problems and requires nothing to be installed.

Tip: learn to read dependency:tree. It is what will get you out of trouble most often, and it is the response tool for vulnerabilities.

Tip: mvn help:effective-pom when you do not understand where something comes from. It shows the POM after inheritance, with everything resolved.

Tip: mvn versions:display-dependency-updates every few weeks. Applying patches regularly is far cheaper than an emergency leap.

Tip: keep *Test and *IT apart. The fast cycle takes seconds; continuous integration runs everything.

Tip: mvn -T 1C on large projects. It can halve the time.

Tip: when something fails inexplicably, mvn -X. The debug output says where every setting and every artifact comes from.

A colleague at Nexus Software has written this pom.xml for a new microservice. It builds, but it has seven problems. Find them, explain the consequence of each and write the corrected version.

BiblioTech throws this exception at run time, not at compile time:

The dependency tree, trimmed:

You are asked for:

1. Explain why the error appears at run time and not at compile time.
2. Apply the resolution rule: which version wins, and why?
3. Give three different solutions with their XML, stating advantages and drawbacks.
4. Pick one and justify it.
5. Write the command that confirms the conflict has been resolved.

BiblioTech has 41 unit tests (11-04) and is about to add integration tests against H2. Right now mvn test takes 6 seconds; with the integration ones it would go up to 45.

Configure the pom.xml so that:

1. mvn test runs only the unit tests (fast, for development).
2. mvn verify runs unit and integration tests.
3. The integration ones are named *IT.java and tagged with @Tag("integration").
4. There is a ci profile that also generates the coverage report with JaCoCo and fails if instruction coverage drops below 70 %.
5. There is a fast profile that skips the integration tests even in mvn verify.
6. Write the commands for each scenario: development, before pushing changes, continuous integration and urgent packaging.

Solution 1

The seven problems:

An eighth, minor one: <relativePath/> is missing from <parent>, which makes Maven look for a POM in ../pom.xml first. It does not fail, but it emits a warning and it can surprise you.

Corrected version:

A note on point 6: if bibliotech-common:2.1.0 is not published yet, the correct solution is to publish it first and then release the service. In the meantime, the service must be 1.0.0-SNAPSHOT. It is the rule that a released version can only depend on released versions.

Solution 2

1. Why at run time and not at compile time.

At compile time, Maven uses the resolved version —2.9.8, as point 2 shows— and the compiler only verifies the signatures your code uses. report-client is already compiled: its bytecode contains a call to JsonMapper$Builder.build() that existed in 2.17 but not in 2.9.8.

At run time the JVM tries to link that call against the class on the classpath, does not find it and throws NoSuchMethodError. Linkage errors happen at run time, not at compile time: it is the same mechanism from module 10 when class loading was discussed.

2. Which version wins.

All three are at depth 2 or 3:

report-client (2.9.8) and nexus-utils (2.13.0) tie at depth 2. On a tie, the one declared first in the POM wins, and report-client appears earlier. 2.9.8 wins, the oldest of the three.

That is exactly the case that surprises people: the newest does not win, the nearest does, and an old transitive can bring the project down.

3. Three solutions.

A. Declaring the dependency directly (depth 1: it always wins):

For: simple, explicit, and dependency:analyze stops complaining. Against: you have to remember it is there because of a conflict; a comment is advisable.

B. dependencyManagement (wins at any depth):

For: it is the tool designed for this, it makes the intent clear and it is the standard way to patch a vulnerable transitive. Against: it pins the version by hand instead of leaving it to the BOM (better: override the <jackson.version> property).

C. exclusions on the offending dependencies:

For: explicit about who was causing the problem. Against: verbose, it has to be repeated on every guilty dependency, and if a third one appears tomorrow you have to remember.

4. Which to choose.

B, with one nuance: instead of pinning 2.17.2 by hand, override the BOM's property.

Reasons: dependencyManagement (which is what lies behind that property) is the mechanism designed for this, it wins at any depth, it works even if a fourth dependency appears tomorrow bringing another version, and the comment documents the why for whoever reads it two years from now.

A mandatory precaution: moving report-client from Jackson 2.9.8 to 2.17.2 is a jump of eight minor versions. It might use API that changed. That is why this change must be accompanied by 11-04's tests running green — which is exactly the argument that lesson closed with.

5. Verification:

And afterwards, mvn verify to confirm that the 41 tests are still green.

Solution 3

And the corresponding integration test:

(6) Commands per scenario:

Details of the solution worth underlining:

• A double filter in surefire (by *IT name and by tag). It is redundant on purpose: if somebody forgets the IT suffix but adds the tag —or the other way round—, the test still stays out of the fast cycle. Redundant filters in build configuration are cheap and they prevent surprises.
• ${skipITs} as a property instead of duplicating the plugin configuration in the profile. The profile only changes one value.
• JaCoCo only in the ci profile. Instrumenting the bytecode slows the tests down; in development it adds nothing.
• check in the verify phase. That way the build fails for insufficient coverage after running all the tests, not before.
• The 70 % threshold is a team decision, not a universal truth. And remember the warning from 11-04: coverage is not quality, and too high a threshold produces bad tests. It is discussed in depth in 12-05.

BiblioTech is now a complete Maven project, reproducible and runnable on any machine in the world that has Java 17.

You understand what problem a build tool solves: not just compiling, but resolving dependency hell —the thirty transitive artifacts a single starter brings in, with versions that have to be compatible with each other—, running tests, packaging and doing all of it reproducibly. And you know why module 1's javac with a hand-written classpath stopped being viable the moment Spring Boot came in.

You know the principle of convention over configuration, which explains why in 11-04 you put the tests in src/test/java and mvn test found them without you configuring anything, and why any Maven project in the world builds the same way with no documentation to read. With its trade-off acknowledged: if your project does not fit the conventions, Maven becomes awkward.

You can read and write a POM: the groupId:artifactId:version coordinates you already saw in 11-01 and how they map to the path in ~/.m2, the packaging, the difference between a mutable SNAPSHOT and an immutable released version —with its professional rule: a released version is never overwritten and never depends on a SNAPSHOT—, and the properties for centralising versions and pinning the encoding.

You have mastered dependencies: the three repositories they are looked up in, the scopes —including the two you were already using without knowing it, runtime for H2 and test for JUnit, which is what keeps a testing framework out of the production jar—, the transitivity that brings in thirty jars from one declaration, and the nearest-definition rule with its consequence that surprises everybody: the newest does not win, the nearest does, and an old transitive can cause a NoSuchMethodError at run time. You know how to diagnose it with dependency:tree —which also answers 11-01's security question: "do I have this library and who pulled it in?"— and with dependency:analyze, which detects the real risk of directly using something you only have transitively.

You can tell dependencyManagement from dependencies and you know their three uses, including the one that matters for security: forcing the fixed version of a vulnerable transitive without waiting for the intermediary to update. And you finally understand spring-boot-starter-parent completely, as a BOM managing more than 400 artifacts, with the warning you had been carrying since 11-02 now justified: putting a <version> on what the BOM manages means overriding versions tested together.

You know the life cycle with its three chains and the key idea that running a phase runs every previous one —which is the answer to why mvn test compiled your code without being asked—, and the second key idea: Maven does nothing by itself, everything is done by plugins hooked to phases, also invocable directly as plugin:goal. You know what BiblioTech's plugins do, why <release>17</release> is better than source/target, and —crucially— the difference between surefire and failsafe, with the trap everybody falls into: mvn test does not run the *IT ones, and it does not warn you.

You know how to package in three ways and why Spring Boot's layered jar is superior to shade's uber-jar, with its consequence for 12-06: rebuilding only the layer that changed turns a 50 MB deployment into a 200 KB one. You handle build profiles —different from Spring's— with the warning not to build different artifacts per environment. And you know about multi-module projects, whose real benefit is not organisational but architectural: bibliotech-domain cannot use Spring because it does not have it on its classpath, and that turns layer separation into a boundary verified by the build.

You know that credentials go into settings.xml, never into the POM, and that a secret that has been in git is considered compromised forever. You use the Maven Wrapper, which eliminates a whole class of "it works on my machine" problems and lets the project be built without installing Maven. You have the day-to-day commands and the reproducibility practices: never ranges, never LATEST, never a SNAPSHOT in production, pinned plugin versions and explicit encoding.

And you have the judgement for the comparison with Gradle: more concise, with caching and incremental builds, considerably faster on large projects; but less predictable, because its build file is code that can do anything. With the practical recommendation: the concepts transfer; learn Maven first.

BiblioTech builds with ./mvnw clean verify in twenty-four seconds: forty-one unit tests, three integration tests, and a fifty-megabyte executable jar that starts on any machine with Java 17. And changing the version of a vulnerable dependency is now one line and one command. The Log4Shell lesson is settled.

But look at those forty-one tests again.

They test FineCalculator, which only needs a Clock. They test Loan's rules, which are plain Java. They test AtomicWrite with a temporary directory. And as soon as a real collaborator appeared —a repository, a notice service—, you had to write by hand an in-memory implementation and another one that recorded calls: twenty lines of inner classes per test, with two simple collaborators. LoanManager has five. LoanRepository is a Spring Data interface with twenty inherited methods: implementing it by hand is unfeasible. And the MetadataClient from 09-06 needs a real HTTP API at the other end.

There are also questions that assertions about the result do not answer. Was the notice sent to the right employee, with the right text? Was the repository called exactly once or forty times? What happens when the database throws an exception —a scenario that is extremely hard to provoke with a real implementation and that in production will happen on any given Tuesday?

The next lesson brings in test doubles by name —dummy, stub, spy, mock and fake— and Mockito 5, which generates them for you with an annotation, using exactly module 10's bytecode generation. You will define behaviour with when(...).thenReturn(...), provoke failures with thenThrow, verify interactions with verify —and learn the criterion for when to verify and when not to, because too much verification produces precisely those brittle tests that break when you refactor—, capture with ArgumentCaptor what was really passed to the notice service, and test the MetadataClient without touching the network.

And you will see something more important than any API: that sometimes the best answer is not a mock, but a design that makes the mock unnecessary. Just as 11-04's fixed Clock did.