jenkinsci/plugin-pom: the parent POM that standardises Jenkins plugin builds

The build configuration problem plugin authors kept solving by hand

Every Jenkins plugin is a Maven project that produces an .hpi artifact, and every one of them needs roughly the same build wiring: the HPI Maven plugin, the Stapler Maven plugin, a Jenkins test harness, a baseline Jenkins version, and consistent compiler settings. Before this parent POM existed, that wiring lived inside Jenkins core, which meant plugin builds moved at the speed of the core repository. The README states the plugin parent POM is decoupled from the core Jenkins project, both from a Maven perspective and a repository perspective. That is the actual design goal: a plugin author inherits a build definition without inheriting core's release cadence.

The audience is narrow and well defined. This is for people writing Jenkins plugins, not for people writing Maven plugins in general. The name invites confusion, and the related searches show it: people arrive looking for what a plugin POM is versus Maven, or for a tutorial on creating a Maven plugin. Those readers are in the wrong repository. This POM configures the build of software that runs inside Jenkins.

What the parent actually injects into your build

Usage is a single parent declaration. The POM you inherit from is org.jenkins-ci.plugins:plugin, and the README instructs you to set relativePath to empty so Maven resolves the parent from the repository rather than looking for a sibling directory. Everything else is property overrides.

The overridable properties listed in the README map directly to the moving parts of the build. jenkins.version is mandatory and defines the core version your plugin requires. jenkins-test-harness.version selects the JTH release used for tests, and the README notes it uses the split test harness tracked as JENKINS-32478. hpi-plugin.version and stapler-maven-plugin.version expose the two build plugins. node.version and npm.version are provided so their values can be kept in step with the core version.

The mechanism is ordinary Maven inheritance plus plugin configuration, with a few opt-in switches layered on top. Formatting is off unless you set spotless.check.skip to false. The JUnit 4 import ban is off unless you set ban-junit4-imports.skip to false. That inversion is deliberate: existing plugins inherit the parent and change nothing until they choose to.

Installing the parent and running a first build

There is nothing to install in the usual sense. You declare the parent in your plugin's pom.xml and let Maven fetch it. The README gives this exact shape, with a placeholder for the version and a pointer to the releases page for the available ones.

<parent>
  <groupId>org.jenkins-ci.plugins</groupId>
  <artifactId>plugin</artifactId>
  <version>VERSION</version>
  <relativePath />
</parent>

After the parent block, set the baseline. The README shows jenkins.version as a property and links the developer documentation for choosing a baseline.

<properties>
  <jenkins.version>2.361.4</jenkins.version>
</properties>

One migration step is easy to miss. If your POM has a jar:test-jar execution, the README says to delete it and add no-test-jar set to false in properties. With those three edits in place, a normal mvn test run exercises the inherited configuration.

To turn on formatting, set spotless.check.skip to false, remove any Spotless configuration you already had, and then apply it to the existing sources.

mvn spotless:apply

The README recommends squash merging that formatting commit and adding a .git-blame-ignore-revs file so blame tools skip it. If you want formatting to happen on every build instead, the README describes an activeProfile entry named may-spotless-apply in your settings.xml that runs the apply goal during the validate phase.

Running the plugin locally is also covered. By default the setup wizard is skipped under hpi:run; to keep it, pass the flag the README gives.

mvn -Dhudson.Main.development=false hpi:run

The version floor is the real cost of adoption

The requirements section is the part to read before anything else. Since version 5.0, the parent requires Jenkins 2.479 or newer and JDK 17 or newer. Since 4.52 it required Jenkins 2.361 or newer and JDK 11 or newer. Support for Java 17 arrived in 4.40.

That means the parent POM is not a neutral convenience. It carries a platform floor that moves with each major line, and a plugin that still targets an older Jenkins or an older JDK cannot simply take the newest parent. The README's own example sets jenkins.version to 2.361.4, which sits below the 5.x floor, so the example and the requirements describe different generations of the parent. Reading only the usage snippet without the requirements section is how a build breaks on upgrade.

The JUnit 4 import check has a boundary worth stating plainly. The README says setting ban-junit4-imports.skip to false prevents imports of JUnit 4 classes, but that it only addresses imports in your code, not uses coming from dependencies, and not fully qualified class names. It is a habit guard, not a dependency audit.

Where this is the wrong tool: any project that is not a Jenkins plugin. If you are publishing a general Maven plugin, or you want a build that does not carry a Jenkins baseline, inheriting this parent buys you nothing and constrains your Jenkins and JDK versions.

How this differs from writing your own parent POM

The obvious alternative is a hand-written parent POM, either internal to your organisation or copied from another plugin. The difference is not features, it is who maintains the defaults. A local parent gives you full control over plugin versions, the test harness, and the baseline, and nothing changes underneath you without a commit in your own repository. This POM gives you the ecosystem's defaults and updates them on the project's release schedule, which is what makes Plugin Compatibility Testing across plugins tractable, since jenkins.version can be swapped to test against different core versions.

The second alternative, staying on Jenkins core's older build definitions, is the situation this project was created to leave behind. The README is explicit that the parent is decoupled from core in both the Maven and repository senses, so the two no longer ship in lockstep.

If you need a build stack that is not Maven, or a test harness other than JTH, this parent is not a starting point you can trim down. It is a complete build definition for one specific kind of artifact.

Releases, licence and the upgrade treadmill

The parent is versioned independently and released frequently. The recent releases listed are 6.2221.va_045130417c9 on 2026-08-10, 6.2211.v27f680c93c53 on 2026-07-13 and 6.2208.vb_6798604237e on 2026-07-09. The last push to the repository was on 2026-08-10, so the project is current rather than dormant.

Upgrade cost is mostly a version bump in your parent block plus a check of the requirements section against your baseline. The README does not document a rollback procedure, and it does not describe a deprecation window for properties removed between lines. If you pin a parent version and later need to move, the requirements section is the only stated source for what the new floor is.

The licence is MIT, per the LICENSE file at the repository root and the badge in the README. That is permissive and does not impose copyleft obligations on the plugins that inherit the POM, but this is a description of the licence text, not legal advice; confirm the terms against the LICENSE file for your own distribution model.

Two smaller behaviours matter during release work. Javadoc is set to quiet by default from 2.20 onward and only logs errors and warnings, so set quiet to false if you want the verbose output. Tests are skipped during the perform phase of a release, which can be overridden with release.skipTests set to false.

Editorial conclusion

Adopt jenkinsci/plugin-pom if you are building a Jenkins plugin and want the same build defaults, baseline enforcement and formatting rules the rest of the ecosystem uses. Do not adopt it if you are writing a plain Maven plugin, or if you cannot move to Jenkins 2.479 and JDK 17 on the 5.x line. Before switching, verify the version of the parent you are pulling, the jenkins.version you set, and whether your existing POM already declares a jar:test-jar execution or its own Spotless configuration, since both need to be removed or adjusted.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes