Maven’s pom.xml and Standard Source Directory Layout

Hello! This course begins with the tools that make a Java project understandable and buildable before moving into backend development. In this first lesson, you’ll learn what Maven expects to find when it opens a project: a pom.xml describing the project and a familiar set of folders for application code, tests, and other files. Being able to recognize that structure will help you navigate an unfamiliar repository and, later, build the expense-tracker API.

Why Maven projects have a recognizable shape

A Java application may need several routine build tasks: compiling source files, running tests, and producing a file that can be distributed. Maven is a build tool that coordinates those tasks. Rather than specifying the location of every source file anew for each project, Maven starts with conventions. It expects Java application code in one place, test code in another, and build results in a third.

Watch this short introduction for the distinction between Maven’s project description and its directory conventions.

The useful idea is convention instead of repeated configuration. If your files follow Maven’s expected layout, Maven can find ordinary application and test sources without a custom path for each one. A developer opening the project also gains a quick map of where to look.

pom.xml: the project’s build description

The file pom.xml sits at the project root—the top-level folder from which the project is built. POM stands for Project Object Model. This XML file tells Maven which project it is working with and holds build-related choices. It can declare libraries the project needs, configure build plugins, and provide other project information. It is not the application’s Java source code, and it is not a list of shell commands to run in order.

Read Apache Maven’s introduction to see both the POM’s general role and the small set of fields needed to identify a project.

Here is a deliberately small example for an expense-tracker project:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.example</groupId>
    <artifactId>expense-tracker</artifactId>
    <version>0.1.0</version>
</project>

The outer <project> element contains the project description. <modelVersion>4.0.0</modelVersion> identifies the version of the POM model Maven expects; it is not the version of your application. The remaining three fields are the project’s coordinates:

• groupId identifies the group or namespace under which the project is published.
• artifactId identifies this particular project within that group.
• version identifies a particular release or development version of it.

Together, the example coordinates are org.example:expense-tracker:0.1.0. The distinction matters: two projects can share a group, and the same project can have many versions. When you later add a library, Maven will use the same kind of coordinates to identify the library you want.

A short POM is possible because Maven supplies defaults. For example, its default source locations are the standard folders you’ll examine next. If packaging is not specified, Maven defaults to a JAR. Real projects often have a longer pom.xml, but its central job remains the same: describe what project this is and how Maven should build it.

The directory layout: source material versus build output

The POM answers questions about the project; the directory layout answers a different question: what role does each file play? Read Maven’s layout guide with that distinction in mind.

For the Java backend project in this course, the core layout would look like this:

expense-tracker/
├── pom.xml
├── src/
│   ├── main/
│   │   ├── java/
│   │   └── resources/
│   └── test/
│       ├── java/
│       └── resources/
└── target/

src/main/java holds Java code that belongs to the application. Later, this is where the API’s controllers, services, and other Java classes will live. src/test/java holds Java tests. Keeping tests apart from application sources lets the build treat them differently while preserving a predictable place to find them.

The resources folders hold non-Java files used by their respective sides of the project. For example, application configuration can live in src/main/resources, while a sample input file used only by tests can live in src/test/resources. These files are resources, not Java classes to compile.

Java packages introduce further folders inside a java directory. A class declared in package org.example.expenses, for instance, would normally sit under org/example/expenses. The same package path may appear beneath src/test/java for its tests. Look at how the application and test paths mirror one another in this sample tree:

Finally, target is output, unlike src, which contains material you maintain. Maven puts generated results there, such as compiled classes, test results, and packaged artifacts. If you want to change application behavior, edit the appropriate file under src/main—not a generated copy under target. The folder may not exist when a project is first created; a build can create it.

Reading an unfamiliar repository

Imagine opening a Java repository for the first time. Finding pom.xml at the root tells you it is a Maven project and gives you a starting point for its identity and build settings. Looking under src/main/java shows the application code; src/test/java shows the tests. A properties file under src/main/resources is an application resource, whereas one under src/test/resources belongs to test support. Files under target are evidence of a previous build, not the primary source to maintain.

This structure is a convention, not an absolute restriction: Maven can be configured to use other locations. But following the standard layout makes the project easier for both Maven and other developers to understand. The folders also need not all be present in a small project; knowing their expected roles is more important than creating empty directories.

Key takeaways

pom.xml is Maven’s project description: it identifies the project with a groupId, artifactId, and version, and it can hold build configuration. The standard layout gives files distinct roles: src/main for application material, src/test for test material, java for Java source, resources for supporting files, and target for generated build output.

In the next lesson, you’ll use the POM for two concrete build choices: adding a library dependency and configuring a build plugin.