How to Read the Jenkins pom.xml to Understand Project Structure

The Jenkins project uses a multi-module Maven structure where the root pom.xml declares the overall project coordinates, lists sub-modules (core, war, cli, test, plugins), and centralizes dependency management, allowing you to trace how each component contributes to the final jenkins.war artifact.

Jenkins is built as a multi-module Maven project under the jenkinsci/jenkins repository. By reading the pom.xml files systematically, you can decipher how the source tree is organized, what each module contributes, and how they are assembled into the final application. Understanding these files reveals the hierarchical relationships between the core engine, the web application archive, and the plugin ecosystem.

Key Sections in the Root pom.xml

The root pom.xml at the repository base serves as the parent for all modules. When you read Jenkins pom.xml files, focus on these critical sections to grasp the project architecture.

Project Coordinates and Packaging

Every Maven project declares its coordinates through <groupId>, <artifactId>, and <version>. In the root pom.xml, these values are inherited by child modules unless explicitly overridden. The <packaging> element is typically set to pom, indicating that the root project itself does not produce a JAR or WAR but acts as a container for sub-modules.

The Modules Section

The <modules> block lists the directory names that constitute the Jenkins application. According to the jenkinsci/jenkins source code, these include core, war, cli, test, plugins, and bom. Each entry points to a sub-directory containing its own pom.xml, establishing the build order and dependency graph.

Properties and Dependency Management

Global properties within <properties> define compiler settings such as java.version, maven.compiler.source, and maven.compiler.target, ensuring consistent bytecode levels across the entire tree. The <dependencyManagement> section locks versions for libraries used across modules, preventing version conflicts and guaranteeing that all components compile against compatible dependencies.

Build Configuration

The <build> section configures plugins that execute across all modules. Key entries include maven-compiler-plugin for compilation, maven-surefire-plugin for testing, and license-maven-plugin for compliance checks. These configurations ensure uniform build behavior whether you are compiling the core engine or a specific plugin.

Understanding the Multi-Module Hierarchy

Navigating from the root pom.xml to individual module descriptors reveals how Jenkins is architected. Each module has a distinct responsibility within the build lifecycle.

• core – Located in core/pom.xml, this module contains the Jenkins engine, plugin container, and essential APIs.
• war – Defined in war/pom.xml, this assembles the final jenkins.war file by bundling compiled classes from core, cli, and other dependencies.
• cli – The cli/pom.xml generates jenkins-cli.jar, providing command-line interface functionality.
• test – The test/pom.xml houses integration and unit test suites that validate the assembled application.
• plugins – Each plugin resides in its own sub-module under the plugins/ directory, such as plugins/docker-commons/pom.xml, following the same inheritance pattern from the root.
• bom – The bom/pom.xml provides a Bill of Materials POM that downstream projects can import to align on Jenkins dependency versions.

Command-Line Techniques to Read Jenkins pom.xml Structure

You can programmatically inspect the project structure without manually parsing XML files. These commands read the Jenkins pom.xml metadata directly from the command line.

To display the module list defined in the root POM:

grep -A1 "<modules>" -n pom.xml | head -20

To visualize the full reactor build order:

mvn -DdryRun=true -q validate | grep "\[INFO\] Building"

To extract a specific property value such as the Java version:

mvn help:evaluate -Dexpression=java.version -q -DforceStdout

To generate a complete dependency tree from the root:

mvn dependency:tree -Dincludes=*:* -DoutputFile=deps.txt

Navigating Key Module pom.xml Files

When analyzing the jenkinsci/jenkins codebase, reference these specific files to understand component relationships:

Module	pom.xml Path	Purpose
Root	pom.xml	Declares multi-module structure and global configuration
Core	core/pom.xml	Builds the core Jenkins engine and APIs
WAR	war/pom.xml	Packages the final jenkins.war artifact
CLI	cli/pom.xml	Generates the command-line interface JAR
Tests	test/pom.xml	Contains integration and unit test suites
Bill of Materials	bom/pom.xml	Provides centralized version management for dependencies
Plugins	plugins/<name>/pom.xml	Individual plugin builds (e.g., plugins/docker-commons/pom.xml)

Summary

• The root pom.xml in jenkinsci/jenkins uses <packaging>pom</packaging> to coordinate a multi-module build.
• Key modules include core (engine), war (web archive), cli (command-line tool), test (validation suites), bom (dependency management), and individual directories under plugins/.
• The <modules> section defines the build order, while <dependencyManagement> ensures version consistency across components.
• Command-line tools like mvn help:evaluate and grep allow you to read Jenkins pom.xml structure without manual file inspection.

Frequently Asked Questions

What is the purpose of the root pom.xml in Jenkins?

The root pom.xml acts as the parent descriptor for the entire jenkinsci/jenkins project. It declares the multi-module structure via the <modules> element, defines global properties like java.version, and centralizes dependency versions through <dependencyManagement>, ensuring consistent builds across the core, war, cli, and plugin modules.

How do I find all modules in the Jenkins project without opening files?

Run the command mvn -DdryRun=true -q validate | grep "\[INFO\] Building" from the repository root. This executes a dry run of the Maven reactor and prints the build order, revealing every module defined in the root pom.xml without requiring you to parse the XML manually.

What does the bom module do in Jenkins?

The bom module (Bill of Materials) provides a specialized pom.xml located at bom/pom.xml that defines curated versions for all Jenkins dependencies. Other projects can import this BOM to automatically align their dependency versions with the Jenkins core, preventing classpath conflicts and ensuring compatibility.

Why is the packaging type set to pom in the root Jenkins pom.xml?

The root pom.xml uses <packaging>pom</packaging> because it is an aggregator project meant to manage and build sub-modules rather than produce its own artifact. This packaging type tells Maven to treat the file as a container that coordinates the build lifecycle of the listed modules (core, war, cli, etc.) without generating a JAR or WAR from the root directory itself.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}