Introducing the Gradle Convention Plugin for Jenkins Plugin Development
Building Jenkins plugins with Gradle just got easier!
Meet the modern, Kotlin-first, and convention-based Jenkins Gradle Convention Plugin. Plugin development made effortless 🏄♂️🏎️.
🌀 Try it today on the Gradle Plugin Portal
Today’s Jenkins Plugin Development Landscape
Apache Maven remains the primary and officially recommended build tool for Jenkins plugin development, powering the vast majority of plugins in the ecosystem. Its strong integration with the Jenkins plugin parent POM, extensive documentation, and mature lifecycle support make it the safest and default choice for most developers.
Gradle, while technically capable and widely adopted across the broader Java ecosystem, has seen limited adoption in the Jenkins community. It offers powerful advantages, including:
-
Extensible build logic defined in code rather than rigid XML.
-
Faster build times with incremental builds, caching, and the Gradle Daemon.
-
A developer-friendly experience with Kotlin and Groovy DSLs, plus interactive tooling.
-
Convention Plugins — a powerful way to share and reuse standardized build logic across projects. They can be combined like traits, much like multiple or diamond inheritance in OOP. In contrast, Maven’s parent POM model only allows a single parent (since Maven 3), forcing developers to rely on heavy profile usage and boilerplate.
Despite these strengths, Jenkins plugin development continues to be dominated by Maven. The primary reasons are that the core build infrastructure, tooling ecosystem, and CI pipelines are deeply aligned with Maven conventions.
The following table highlights some key differences between Maven and Gradle in the context of Jenkins plugin development.

Motivation
In late 2022, the Jenkins community identified significant gaps in Gradle support for plugin hosting and automation. At that time, new open source Jenkins plugins using Gradle were even blocked from hosting until those requirements were addressed.
This sparked discussions and community initiatives to close the gaps. The Jenkins Gradle Convention Plugin is a direct outcome of that effort, providing a standardized and supported way to build Jenkins plugins with Gradle.
Where the Gradle JPI Plugin falls short ?
The Gradle JPI Plugin provides a Maven-free path for Jenkins plugin development, but it falls short in matching the full Maven-based experience. Key limitations include:
-
Non-compliance with Jenkins hosting requirements → blocks acceptance
-
No Plugin Compatibility Tester (PCT) support → weak cross-version testing
-
Dependency management & BOM gaps → unreliable builds
-
Outdated Groovy-based codebase → harder to maintain
-
No convention plugin → developers face more configuration overhead
Meet the Jenkins Gradle Convention Plugin
A Kotlin-first, Gradle convention plugin that acts as the Maven Parent POM equivalent for Jenkins plugin development with Gradle. Built on top of the well-established gradle-jpi-plugin
, it provides a unified, opinionated foundation for building, testing, and publishing Jenkins plugins—standardizing best practices, automating quality checks, and eliminating boilerplate.
A new “JPI2” variant of the Gradle JPI Plugin was introduced by Rahul and Steve, adding support for Gradle 8+, improved dependency handling, and a modern architecture. The gradle convention plugin is designed to be forward-compatible, once JPI2 APIs stabilize, we plan to migrate the convention plugin to leverage it for an even better experience. |
Built by me, as part of Google Summer of Code (GSoC) 2025 in collaboration with Gradle, Netflix, and the Kotlin Foundation, under the expert mentorship of Oleg Nenashev, Steve Hill and Rahul Somasunderam. Their mentorship has been invaluable, and the plugin continues to be actively maintained.
What it brings ?
-
Modern language standards enforcement: Minimal/Zero configuration, maximum productivity for Java, Kotlin, and Groovy
-
Jenkins Hosting Compliance: PCT support, metadata, and structure all handled
-
Smart dependency management: Automatic BOM alignment and zero version conflicts -
say goodbye to Dependency Hell -
Quality gates & reporting: Pre-configured tools with unified, CI-ready reports
-
Modern testing ecosystem: Ready-to-use test stack with optimized execution for reliable, fast Jenkins plugin testing
-
Configuration & extensibility: Flexible DSL or properties-based setup for multi-module projects
-
Future-Proof: Embraces Gradle 9 best practices like Configuration Cache, Version Catalogs, and caching
Getting started in seconds
-
Step 1: Define the plugin in the project’s
libs.versions.toml
file
[versions]
jenkinsConvention = "<LATEST_VERSION>"
[plugins]
jenkinsConvention = { id = "io.github.aaravmahajanofficial.jenkins-gradle-convention-plugin", version.ref = "jenkinsConvention" }
-
Step 2: Configure the Version Catalog
In the root settings.gradle.kts`
, add the plugin’s version catalog:
dependencyResolutionManagement {
repositories {
mavenCentral()
}
versionCatalogs {
create("baseLibs") {
from("io.github.aaravmahajanofficial:version-catalog:<LATEST_VERSION>")
}
}
}
-
Step 3: Basic Build Script
In the root build.gradle.kts
, add the following:
plugins {
alias(libs.plugins.jenkinsConvention)
}
jenkinsConvention {
// Only override the defaults that need to be customized for your plugin.
// Set the Jenkins version (default: as per version catalog).
jenkinsVersion = "2.525"
}
That’s it! Enjoy pre-configured tools, synced BOMs, PCT support, and ready-to-go compliance checks.
Roadmap
Next steps for plugin delivery and integration:
-
Support continuous delivery for Jenkins plugins
-
Integrate seamlessly with Jenkins pipelines (e.g.,
buildPluginWithGradle
for CI) -
Migrate to Gradle JPI2 Plugin once new APIs stabilize
I invite all the Jenkins community developers - especially maintainers of Gradle-based plugins - to try it out, provide feedback, and help refine it into a stable toolchain that benefits all. Contributions, real-world testing, and discussions are very welcome .
Learn more
-
Official Slack Channel -
#jenkins-plugin-toolchain
Concluding with the Elephant 🐘
This plugin isn’t just another build tool tweak—it’s about making Gradle a first-class citizen in Jenkins plugin development. Let’s bring modern productivity engineering to the Jenkins ecosystem.
Thanks for reading! Star or contribute to the repo if you found this useful.