First POM to a Maven Reactor

Table of Contents

1. Challenge

   Step 1: Set up Maven and the project layout

   Welcome to Maven. Nearly every Java team uses it to turn source files into a repeatable, traceable build, and the habits you build here carry over to any Maven project you meet. In this lab, which covers similar concepts to those covered in the Maven Fundamentals course, you'll grow a small text utility library called textkit from a single hand-written POM into a multi-module project that uses the Maven reactor, with a library module and a consumer application. Along the way, you'll declare scoped dependencies, bind plugins to lifecycle phases, inspect the build in VS Code, and share versions through a parent POM and an imported BOM.

   The lab's codebase lives in the application directory, and every path in this guide is relative to it. It already holds the library's Java source files and a JUnit test, but they sit in a loose legacy folder and nothing builds them yet. Maven's folder structure is already in place, so you'll write files and move code instead of creating folders. In this step, you'll confirm Maven is installed, write the smallest POM that works, and move the code into that structure so a single mvn compile produces class files.

2. Challenge

   Step 2: Declare and resolve dependencies

   Your project now builds from a POM and a conventional layout, so Maven knows where code lives and can start managing what the code needs. You'll declare a compile-scope library, a test-scope library, and a runtime-scope library, then move the remaining legacy classes into place so they can use them. You'll also trace how Maven resolves transitive dependencies and how it records downloaded artifacts in the local repository, so you can explain where each JAR on your classpath came from.
   Maven records where it downloaded each artifact from in a _remote.repositories file.

   In the TERMINAL, run

   cat ~/.m2/repository/org/apache/commons/commons-text/1.12.0/_remote.repositories
   

   Find the entry for the commons-text JAR. You should be able to trace the downloaded commons-text artifacts back to central, the repository that supplied them.

3. Challenge

   Step 3: Configure lifecycle plugins

   Your project resolves its dependencies and runs its tests, which means the early lifecycle phases are already doing real work through default plugins. You'll now configure the compiler plugin, set the executable entry point with the JAR plugin, and bind the source and Javadoc plugins to the package phase. By the end, one mvn package produces a main JAR, a sources JAR, and a Javadoc JAR, and you'll know which plugin produced each.

4. Challenge

   Step 4: Inspect the build in VS Code

   Your build now has dependencies, scopes, and several configured plugins, and that is enough complexity to make it worth seeing the whole picture at once. You'll use the Maven view in VS Code, its dependency hierarchy, and the effective POM view to understand what Maven actually computed. You'll then act on what you find: Add a profile that skips documentation, take control of a transitive version, and pin a plugin version that the effective POM revealed.

5. Challenge

   Step 5: Use the reactor to handle multiple modules

   Your single module builds cleanly, and you can see exactly how Maven resolves it, so the next question is how a second project would reuse the same decisions. You'll move the library into its own module, create a parent POM that owns shared versions and imports the JUnit BOM, and add a textkit-app module that depends on the library. The result is one reactor build that compiles, tests, and packages both modules with consistent versions. Congratulations on completing the lab. You built textkit, a Java library with a consumer application, and grew it from a single hand-written POM into a two-module Maven reactor. Along the way, you structured a project around Maven's conventions, declared dependencies in compile, test, and runtime scopes, and traced where each artifact came from. You also bound compiler, JAR, source, and Javadoc plugins to lifecycle phases, read the effective POM to pin a plugin version, and shared versions through a parent POM and an imported BOM. The final command ran App from the textkit-app module, which printed the slug and title for your phrase using the library module that the reactor built before it.