Project structure and pom.xml

Written Explanation

The standard directory layout

Maven expects this shape (this is the layout used throughout the module):

hello/
├── pom.xml
└── src/
    ├── main/
    │   └── java/
    │       └── com/example/Greeter.java
    └── test/
        └── java/
            └── com/example/GreeterTest.java

The rules:

Notice that the package com.example becomes the folders com/example under src/main/java. The folder src/main/java itself is not part of the package name. You already did this in earlier modules; Maven just fixes the starting folder.

Test code lives in a separate tree so it is compiled and run for the tests but is not packaged into the final JAR. The test class GreeterTest is in the same package as Greeter, which lets it use package-private members.

The target/ folder

After a build, a target/ folder appears. It holds compiled .class files (target/classes), compiled tests (target/test-classes), test reports (target/surefire-reports), and the JAR. Real listing from a build of the example project:

target/classes
target/test-classes
target/surefire-reports
target/hello-1.0-SNAPSHOT.jar

Everything in target/ can be rebuilt from your sources at any time, so it is never edited by hand and never committed to Git. Deleting it is always safe.

The pom.xml

POM stands for Project Object Model. The pom.xml is an XML file that describes your project and tells Maven how to build it. XML is made of nested tags such as <name>value</name>; you only need to read it, not master it.

Here is the complete pom.xml of the example project:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0-SNAPSHOT</version>

  <properties>
    <maven.compiler.release>21</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

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

Read it top to bottom:

• The opening <project ...> lines are boilerplate: they name the XML format. Copy them; do not worry about them.
• <modelVersion> is the version of the POM format itself. It is 4.0.0 for all current Maven projects.
• Coordinates (next section) say who and what this project is.
• <properties> are named settings. maven.compiler.release sets the Java version used to compile; project.build.sourceEncoding sets the text encoding of source files. Always set both, as explained below.
• <dependencies> lists the libraries the project uses (lesson 3).

If <packaging> is not written, Maven assumes jar, which is what we want.

Coordinates

Every Maven project is identified by three values:

They are written together as groupId:artifactId:version, here com.example:hello:1.0-SNAPSHOT. The same three values identify every library you depend on, which is how Maven finds them in a repository.

The suffix -SNAPSHOT marks a version still under development. The JAR name follows the pattern artifactId-version.jar, which is why the real file is hello-1.0-SNAPSHOT.jar.

If a coordinate is missing, Maven refuses to start. Removing groupId from a test project gives this real message:

[ERROR]   The project [unknown-group-id]:demo:1.0 (...pom.xml) has 1 error
[ERROR]     'groupId' is missing. @ line 1, column 52

Why set the Java version

Without a Java version property, Maven uses defaults that may be much older than your JDK. In a test project with no properties, the real build output was:

[INFO] Compiling 1 source file with javac [debug target 1.8] to target\classes
[WARNING] source value 8 is obsolete and will be removed in a future release

That is Java 8 compatibility settings on a JDK 21: modern syntax would fail, and the warnings are noise. The default depends on the Maven compiler plugin version, so do not rely on it: set maven.compiler.release explicitly. (release tells javac which Java version's language and library to compile against.) With the property set to 21, the build compiled with no such warning.

Plugins

Maven itself knows very little. The work (compiling, running tests, creating the JAR) is done by plugins, small programs Maven downloads on demand. You can see them in the build output:

[INFO] --- compiler:3.13.0:compile (default-compile) @ hello ---
[INFO] --- surefire:3.2.5:test (default-test) @ hello ---
[INFO] --- jar:3.4.1:jar (default-jar) @ hello ---

Each line reads plugin:version:goal. The compiler plugin calls javac, Surefire runs tests, the jar plugin builds the JAR. Notice that our pom.xml mentions no plugins at all: the default ones are built into Maven's conventions. You declare a plugin in a <build><plugins> section only when you want to add something or change a default. Here is what such a section looks like (you will not need one in this module):

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jar-plugin</artifactId>
      <version>3.4.1</version>
    </plugin>
  </plugins>
</build>

Plugins have coordinates too: the same groupId:artifactId:version idea.

Where the analogy stops

The recipe card lists steps. A pom.xml mostly lists facts (name, Java version, libraries); the steps come from Maven's built-in conventions. That is why a tiny pom.xml can drive a full build.