[ANNOUNCE] Jenkins Gradle Convention Plugin — modern Gradle conventions for Jenkins plugin development
Aarav Mahajan
Hello Jenkins Developers!
I am very excited to announce the Jenkins Gradle Convention Plugin — a Kotlin-first, Gradle Convention plugin (a feature similar to Maven Parent POM - docs) that standardizes and simplifies building Jenkins plugins with Gradle. This plugin extends and builds upon the well-established gradle-jpi-plugin, adding the unified build flow, conventions, opinionated defaults, and integrations that bring Gradle-based Jenkins plugin development tools closer to what is possible in the Maven tools (hosting compliance, BOMs, testing and PCT, quality gates). It also allows for idiomatic Gradle experience.
This plugin is being developed as part of my Google Summer of Code 2025 project, in collaboration with Gradle, Netflix and the Kotlin Foundation. My mentors for this project are Oleg Nenashev, Steve Hill and Rahul Somasunderam.
For more details, check out the Project Idea Page and My Project Page. Here is also my demo from the mid-term evaluation: Google Drive Link.
P.S.: A newer “JPI2” variant of the Gradle JPI Plugin was introduced by Rahul and Steve, adding support for Gradle 8+ and improved dependency handling. Once this new version provides the necessary APIs, the convention plugin can be moved to it.
Background & Motivation
In late 2022 the community discussed the limitations of Gradle for Jenkins plugin hosting and automation. New OSS plugins built with Gradle were temporarily blocked until the hosting requirements were met, and maintainers called for help to close the gaps in the Gradle toolchain. This plugin and the wider GSoC’25 effort are direct follow-ups to that discussion.
What my plugin brings today
1. First-class support for the Jenkins BOM, plus support for other ecosystem BOMs like netty, jetty, jackson, sl4j etc.
2. Industry-standard code-quality tools like Spotless, Spotbugs, PMD, Checkstyle, Detekt, JaCoCo/Kover, OWASP deps check etc.; all wired up with defaults aligned to the Jenkins ecosystem and defaults in the Maven Parent POM.
3. Corrects and enriches the generated plugin manifest (e.g., developers, licenses, SCM, plugin metadata), aligning with Maven defaults and Jenkins publishing(update-center) expectations
4. Superior DX: version-catalogs, concise DSL to reduce boilerplate
5. Zero-Config Setup: just apply my plugin from the Gradle Plugin Portal in your `build.gradle.kts` and you are ready-to-go :)
Native Gradle Support in Jenkins PCT
One of the major deliverables for this project is enabling Gradle-built plugins to be tested by Plugin Compatibility Tester in the same way as Maven-built ones.
I have suggested a patch for this in this PR.
Next Steps
The Jenkins Gradle Convention Plugin is an important step toward making Gradle a first-class citizen in Jenkins plugin development, closing long-standing gaps identified in prior community discussions.While still under active development as part of GSoC’25, it already provides a usable foundation with conventions, BOM management, quality gates, and PCT integration. More work is needed to add support for plugins continuous delivery. Seamless integration with Jenkins pipeline steps like buildPluginWithGradle for CI workflows is on our roadmap.
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 :)
Source code is available in my GitHub repository. If you would like to share any feedback, please respond in this thread or create a GitHub issue. We also have a #jenkins-plugin-toolchain channel on the Gradle Community Slack.
Best wishes,
Daniel Krämer
While I really appreciate the efforts you have put into this, I can’t help but wonder: Why?
Being a developer myself, I personally do not care too much for the whole “Maven vs. Gradle” discussion that some people seem to make their entire existence about.
But still, I want to question the elephant in the room:
There is already an established ecosystem for Maven in the Jenkins CI universe, aiming to standardize plugin development to a certain degree (in my opinion, one could even add “successfully” here).
A lot of work has been invested into this, and there is still plenty left to do.
By the end, it’s not only about making the creation of new plugins easy, but—more importantly—keeping the cost of maintenance manageable for contributors to existing plugins.
Now, just assuming that everything that works with Maven today would also work with Gradle tomorrow—which is a huge task in itself—we would end up with two systems that need to be kept in sync.
And ultimately, one of them would need to be phased out.
Oleg Nenashev
Hi Daniel,
Thank you for the comment. You are totally right about the elephant in the room we need to address, though it was partially discussed at the governance meetings before the project started. I am sorry for not summarizing the intent in public after the GSoC community bonding started. As discussed with Aarav beforehand, I am responding here to share my opinion. In my response, I am not representing Gradle, Inc., and I deliberately responded on Sunday. To avoid confusion, below “Gradle” means “Gradle Build Tool” only.
First of all, you are totally right that in Jenkins we have the Apache Maven toolchain which is well-maintained and provides a great DevX for developing Jenkins plugins, much better one that what I've seen in some other frameworks. Thousands of Jenkins plugins use it, and there are many dozens of contributors to the toolchain every year. Kudos to all of them. As of now, and unless a black swan happens, I believe that the Maven toolchain will always remain the recommended default in the Jenkins project.
You are also right that having two official build systems requires extra maintenance, and totally not desirable from the core/tooling maintainer point of view. I am not sure whether, as a Jenkins community, we will ever make Gradle toolchain an officially supported toolchain and, clearly, this is not a deliverable for the GSoC project by Aarav.
So, back to your main question - Why? First of all, the Gradle toolchain already exists in Jenkins, and stabilizing it has certain value to the ecosystem (see below). We discussed this topic at the governance board in April 2025 - notes are not detailed, but you can see the video here. IIRC there was another conversation during the GSoC project ideas collection phase. To sum-up the conversation:
Many plugins in the Jenkins organization continue using the Gradle-based development flow - Search Query. Some are deprecated, some are unmaintained, some are still used by the community.
Note that the most prominent users, JobDSL and the Gradle Plugin itself, have moved to the Maven toolchain recently - and that’s the right step IMHO
There are even more 3rd-party open-source and private-source Jenkins plugins implemented with Gradle, and that need maintenance and improvements. E.g. Rahul and Steve can comment on how Netflix, a major Jenkins user, does internal Jenkins plugin development
Just for those two categories, improving the Gradle toolchain and getting it closer to Jenkins’ quality standards makes total sense - this is what Aarav and Rahul have been working on recently in the JPI2 Plugin for Gradle and in the Convention plugin. It would help to sustain the existing ecosystem and to make it easier for Jenkins developers and instance maintainers who have chosen Gradle at some point, whether open source or not.
In the longer term, one could also argue that having a stable Gradle toolchain and allowing for hosting new Gradle plugins, while increasing maintenance overhead as you said, could…
I make Jenkins development more compelling to the potential ecosystem contributors who use Gradle as a main tool in their work - for open source or private plugins. In particular, this would be Android developers where Gradle (and Kotlin) are the default choice - seasoned Android developers and Jenkins contributors like Chris Orr can comment on it better than me.
It would simplify Jenkins development for the companies and FOSS projects that use Gradle as a standard, which is particularly popular in the Monorepo setup
In any case, we are not yet in the position to discuss officially supporting the Gradle flow and, even further, re-enabling hosting. The JPI2 and the Convention plugins should first get enough feedback and stabilized, and there should be some long-term commitment for both in the community before we discuss this step. Aarav's project is very important groundwork for that, and it has community value regardless of the long-term decision. As a mentor, I would like to thank him for his great work on this project!
Best regards, Oleg Nenashev
Aarav’s mentor and GSoC Org Admin in the Kotlin Foundation
Daniel Krämer
Aarav Mahajan
Recent developments/updates:
1. A new announcement blog for this plugin is now live on Jenkins.io.
2. The plugin has been transferred from my personal repository to its new home in the official jenkinsci GitHub organization. There will be another major release of the plugin with new Group IDs.
There is also some future work, any feedback would be appreciated:
- [#211] Update Gradle Plugin Portal coordinates to the official Jenkins namespace (WIP, pending RFC).
- [#214] Ensure Gradle Convention Plugin follows Jenkins build conventions. There are some features that still need to be implemented before the plugin is fully Jenkins build compliance.
- [#221] Add build-time checks to prevent packaging dependencies already provided by Jenkins core/APIs.
- Add a reference Jenkinsfile implementation in one or multiple Jenkins plugins.
Thanks!