DEV Community

Cover image for Gradle Convention Plugin for Developing Jenkins Plugins
Gradle Community profile image aaravmahajanofficial
aaravmahajanofficial for Gradle Community

Posted on • Edited on

Gradle Convention Plugin for Developing Jenkins Plugins

#gradle #kotlin #jenkins #opensource

Building Jenkins plugins with Gradle just got easier. Meet the Jenkins Gradle Convention Plugin → modern, Kotlin-first, convention-based. Plugin development made effortless 🏄‍♂️🏎️
🌀 Try it today on 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 offering a modern, flexible build system widely adopted in other Java ecosystems, has seen limited adoption in the Jenkins community. It brings powerful advantages, including extensible build logic via code rather than rigid XML, blazing build speeds thanks to features like incremental builds, build caching, and the Gradle Daemon, a developer-friendly experience with DSLs and interactive tooling. Despite these strengths, Jenkins development continues to be dominated by Maven, largely because the core build infrastructure, tooling ecosystem, and CI pipelines are deeply aligned with Maven conventions.

The following highlights some key differences between Maven and Gradle in the context of Jenkins plugin development.

Comparison

Origin and motivation

Back in late 2022, the Jenkins community identified major gaps in Gradle support for plugin hosting and automation. New OSS plugins using Gradle were even blocked until hosting requirements were met. This sparked discussions and initiatives to close those gaps and the Jenkins Gradle Convention Plugin is a direct outcome of that effort.

But, where the Gradle JPI Plugin falls short?

The Gradle JPI Plugin offers a Maven-free path for Jenkins plugin development, but its limitations prevent it from matching the Maven-based experience.

Key issues:

  1. Non-compliance with Jenkins hosting requirements → blocks acceptance
  2. Limited Plugin Compatibility Tester (PCT) support → weak cross-version testing
  3. Dependency management & BOM gaps → unreliable builds
  4. Outdated Groovy-based codebase → harder to maintain
  5. No convention plugin → more configuration burden

Meet the Jenkins Gradle Convention Plugin

A Kotlin-first, Gradle Convention Plugin that works like a Maven Parent POM equivalent for Gradle, providing a unified build flow and opinionated defaults. It extends the well-established gradle-jpi-plugin and builds on top of it.

What about JPI2?
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 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, Aarav Mahajan as part of Google Summer of Code 2025 in collaboration with Gradle, Netflix, and the Kotlin Foundation, under the mentorship of Oleg Nenashev, Steve Hill and Rahul Somasunderam.

What it brings:

  • Kotlin-First & Convention-Based – Minimal/Zero config, maximum productivity.
  • Jenkins Hosting Compliance – PCT support, metadata, and structure all handled.
  • BOM Integration – Auto-managed Jenkins Core & plugin BOMs to solve the problem of dependency hell caused due to transitive dependencies.
  • Built-in Quality Gates – Spotless, SpotBugs, PMD, Detekt, Checkstyle, JaCoCo/Kover, Dokka etc., all pre-wired with Jenkins-aligned defaults.
  • Future-Proof – Embraces Gradle 9 best practices like Configuration Cache, Version Catalogs, and caching.

Getting started in seconds

Add the plugin in your build.gradle.kts:

plugins {
  id("io.github.aaravmahajanofficial.jenkins-gradle-convention-plugin") version "latest-version"
}
Enter fullscreen mode Exit fullscreen mode

Also, add this in your settings.gradle.kts:

dependencyResolutionManagement {
    repositories {
        mavenCentral()
    }
    versionCatalogs {
        create("libs") {
            from("io.github.aaravmahajanofficial:version-catalog:<latest-version>")
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

That’s it 😉 No messy boilerplate. Now you have:

  1. Quality tools pre-configured
  2. BOMs automatically synced
  3. PCT support
  4. Compliance checks ready
  5. A clean, consistent developer experience

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 JPI2 when new APIs are available

I invite all the Jenkins community developers and, 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 :)

Explore more

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! ⭐ If you find this project useful, consider starring the repo or contributing.

Kodee Mascot

Top comments (0)