Where is the pom.xml File in jenkinsci/jenkins? Root and Module Locations Explained

The primary pom.xml file in jenkinsci/jenkins resides at the repository root, orchestrating a multi-module Maven build, while individual module pom.xml files live in subdirectories such as core/, war/, cli/, and test/.

The jenkinsci/jenkins repository follows a standard Maven multi-module project structure. Understanding where these pom.xml files are located is essential for building the project, running tests, or contributing to specific components. This guide maps every significant pom.xml location and explains how the root descriptor coordinates the entire build lifecycle.

Root pom.xml Location and Purpose

The main entry point for the Jenkins build system sits at the repository root:

• Root descriptor: pom.xml (located at the repository root)

This file defines global properties, dependency versions, and plugin configurations that cascade to all child modules. It declares the <modules> section that references subdirectories, ensuring Maven recognizes the project as a multi-module build. When you execute Maven commands from the repository root, this pom.xml controls the build order and aggregates results across all components.

Module-Specific pom.xml Locations

Jenkins splits its functionality into discrete Maven modules, each with its own pom.xml. These module descriptors extend the root configuration while defining component-specific dependencies and build goals.

Core Module (core/pom.xml)

The Jenkins core library lives in core/pom.xml. This module contains the fundamental APIs, model classes, and core runtime logic that power the automation server. When building Jenkins from source, the core module compiles first to provide dependencies for downstream modules.

WAR Packaging (war/pom.xml)

The deployable artifact is assembled in war/pom.xml. This module takes the core library and bundles it with web resources, plugins, and servlet configurations into the final jenkins.war file suitable for deployment to servlet containers or execution via java -jar.

CLI Client (cli/pom.xml)

Command-line tooling is defined in cli/pom.xml. This module produces the Jenkins CLI client JAR, enabling remote scripting and administrative tasks against a running Jenkins instance.

Test Harness (test/pom.xml)

Integration testing infrastructure resides in test/pom.xml. This module contains the test harness utilities and comprehensive integration tests that validate Jenkins functionality across modules. It depends on both the core and war modules to execute full-stack verification.

Additional Modules

The repository contains several specialized modules for extended functionality:

• WebSocket SPI: websocket/spi/pom.xml defines the service provider interface for WebSocket support
• WebSocket Jetty Implementation: websocket/jetty12-ee9/pom.xml provides the Jetty-based runtime implementation
• Coverage Aggregation: coverage/pom.xml collects code-coverage metrics across all modules
• Bill of Materials: bom/pom.xml aligns dependency versions consistently across the multi-module project

Building from the Root pom.xml vs Module pom.xml

You can build the entire Jenkins project or target specific components depending on which pom.xml you reference.

Building the Entire Project

Execute Maven from the repository root to traverse all modules defined in the root pom.xml:

mvn clean install -f pom.xml

This command builds core, war, cli, and all other modules in the dependency order specified by the root <modules> section.

Building Specific Modules

To compile only the WAR artifact without rebuilding unaffected modules:

cd war
mvn clean package -f pom.xml

Alternatively, from the root directory, use the -pl (projects list) flag to build specific modules with their dependencies:

mvn -pl war -am clean package

The -am flag ensures Maven builds the war module plus all its required upstream dependencies (like core).

Running Tests

Execute the complete test suite across all modules:

mvn test -f pom.xml

Generate site documentation for a specific module:

mvn site -f core/pom.xml

Summary

• The root pom.xml in jenkinsci/jenkins sits at the repository root and coordinates the multi-module build
• Module pom.xml files reside in subdirectories: core/pom.xml, war/pom.xml, cli/pom.xml, and test/pom.xml
• Specialized modules include WebSocket implementations in websocket/spi/pom.xml and websocket/jetty12-ee9/pom.xml, plus coverage/pom.xml and bom/pom.xml
• Build from the root to compile everything, or navigate to specific module directories to build isolated components
• Maven commands executed at the root automatically respect module dependencies and build order

Frequently Asked Questions

Where is the main pom.xml file located in the jenkinsci/jenkins repository?

The main pom.xml file is located at the root of the jenkinsci/jenkins repository. This file serves as the parent descriptor that defines global build settings and declares all sub-modules in its <modules> section.

What is the difference between the root pom.xml and core/pom.xml?

The root pom.xml orchestrates the entire multi-module build and manages dependency versions across all components, while core/pom.xml specifically defines the Jenkins core library build. The core module depends on the root parent POM for shared configuration but adds its own specific dependencies and build plugins relevant to the core APIs.

How do I build only the Jenkins WAR file without compiling everything?

Navigate to the war/ directory and run mvn clean package -f pom.xml, or execute mvn -pl war -am clean package from the repository root. The second approach from the root directory builds only the war module and its upstream dependencies (like core) without processing unrelated modules such as cli or test.

Why are there multiple pom.xml files in the jenkinsci/jenkins repository?

Jenkins uses a Maven multi-module architecture to separate concerns into distinct components—core runtime, web application packaging, command-line tools, and testing infrastructure. Each module requires its own pom.xml to define specific dependencies and build configurations while inheriting shared settings from the root parent POM, enabling independent development and faster builds of specific components.

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