Jenkins Source Code Organization Overview: Core, Web UI, CLI, and Plugin Architecture

Jenkins is organized as a multi-module Maven project with distinct directories for the core engine (core/), web application (war/), command-line client (cli/), integration tests (test/), and bundled plugins (plugins/), all orchestrated by a parent pom.xml.

The jenkinsci/jenkins repository is a large-scale modular Java application that separates concerns across dedicated Maven modules. Understanding this directory structure is essential for contributing to core functionality, debugging build issues, or developing custom plugins. The architecture cleanly isolates the runtime engine from the web interface, remote client, and extension mechanisms.

Core Module (core/)

The core/ directory contains the Jenkins runtime engine, including the job model, build execution logic, security realm, and plugin loading mechanism. This module defines the fundamental APIs that all plugins consume.

Job and Item Model

The hierarchical model of Jenkins is defined in core/src/main/java/hudson/model/Item.java, which serves as the base interface for all Jenkins entities including jobs, folders, and nodes. The abstraction for buildable projects lives in core/src/main/java/hudson/model/Job.java, while individual build executions are represented by core/src/main/java/hudson/model/Run.java.

Extension Points and Plugin Loading

Jenkins uses the @Extension annotation and ExtensionPoint interface to allow plugins to contribute functionality. The PluginManager class in the core module handles dynamic loading and lifecycle management of plugin JARs at runtime.

// Accessing core model objects from within a plugin
import hudson.model.Job;
import hudson.model.Run;

public void perform(Run<?,?> run, FilePath workspace, Launcher launcher, TaskListener listener) {
    Job<?,?> job = run.getParent();   // Access the parent job via core API
    listener.getLogger().println("Executing job: " + job.getFullName());
}

Web UI and WAR Packaging (war/)

The war/ module packages the Jenkins web application as a deployable WAR file. It aggregates the core module, static resources, and servlet configuration required to run Jenkins in a servlet container like Jetty or Tomcat.

Servlet Configuration

The entry point for the web application is defined in war/src/main/webapp/WEB-INF/web.xml, which configures the JenkinsServlet and initializes the application lifecycle. The startup sequence is orchestrated by war/src/main/java/jenkins/InitReactorRunner.java, which manages the initialization reactor that boots core services in the correct order.

Static Resources

This module also houses the Jelly and Groovy view templates, CSS assets, and JavaScript files that render the Jenkins user interface in browsers.

Command Line Interface (cli/)

The cli/ module provides a standalone command-line client distributed as jenkins-cli.jar. It enables remote administration of Jenkins instances over HTTP or SSH without using the web browser.

Remote Communication Protocol

The entry point for the CLI client is cli/src/main/java/hudson/cli/CLI.java, which handles connection establishment and authentication. For SSH-based communication, cli/src/main/java/hudson/cli/SSHCLI.java implements the SSH transport layer that allows secure remote execution of CLI commands.

# List all jobs on a remote Jenkins instance using the CLI

java -jar jenkins-cli.jar -s http://localhost:8080/ list-jobs

Plugin Architecture (plugins/)

The plugins/ directory contains Maven sub-modules for official plugins bundled with Jenkins distributions. Each plugin is a standalone module that depends on the core API and contributes extension implementations such as build steps, SCM integrations, or cloud providers.

Plugins declare their dependencies on core via the parent POM and use the @Extension annotation to register components with Jenkins. For example, GitHub integration logic would reside in paths like plugins/github-plugin/src/main/java/org/jenkinsci/plugins/github/GitHubPlugin.java.

Test Infrastructure (test/)

The test/ module contains integration tests and testing utilities that verify core and plugin functionality. These tests run against a real Jenkins instance using the JenkinsRule JUnit rule, allowing tests to exercise the full stack from HTTP requests down to build execution.

Build Orchestration (pom.xml)

The root pom.xml serves as the Maven parent that aggregates all modules, defines shared dependency versions, compiler settings, and repository configurations. This ensures consistent build behavior across the core/, war/, cli/, and plugins/ modules, enabling reproducible builds with a single mvn clean install command.

Summary

• Core module (core/): Contains the engine, job model (Item, Job, Run), and plugin loading infrastructure (PluginManager).
• Web module (war/): Packages the servlet application, static assets, and startup logic (InitReactorRunner.java, web.xml).
• CLI module (cli/): Implements the remote command-line client (CLI.java, SSHCLI.java) for headless administration.
• Plugins directory: Houses bundled plugin modules that extend core functionality via the ExtensionPoint API.
• Test module (test/): Provides integration testing harnesses that run against live Jenkins instances.
• Parent POM: Root pom.xml coordinates the multi-module build and dependency management.

Frequently Asked Questions

What is the difference between core and plugins in Jenkins?

Core (core/) provides the foundational runtime engine, security model, and extension APIs required for Jenkins to function. Plugins are separate Maven modules that depend on the core JAR and implement specific functionality (like Git integration or cloud provisioning) using the extension points defined in core. The core loads plugins dynamically at runtime via the PluginManager.

Where is the Jenkins web interface defined in the source code?

The web interface is defined primarily in the war/ module, with servlet configuration in war/src/main/webapp/WEB-INF/web.xml and view templates typically using Jelly or Groovy scripting. Static assets such as CSS and JavaScript are also packaged within this module before being bundled into the final WAR artifact.

How does the Jenkins CLI communicate with the server?

The CLI client (cli/src/main/java/hudson/cli/CLI.java) communicates with the Jenkins master over HTTP using a specialized remoting protocol, or optionally via SSH (SSHCLI.java). It sends serialized commands to the server's CLI endpoint, which executes them with the same permissions as the authenticated user would have through the web UI.

How are Jenkins modules built and versioned?

All modules share a common parent POM (pom.xml) at the repository root that defines consistent versioning, Maven plugin versions, and Java compiler settings. This multi-module structure ensures that building the root project compiles core, war, cli, and plugins in the correct dependency order, producing version-aligned artifacts.

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