Recent developments/updates:
1. A new announcement blog <https://www.jenkins.io/blog/2025/08/31/aarav-mahajan-gsoc-gradle-convention-plugin-for-jenkins-plugin-development/> for this plugin is now live on Jenkins.io. 2. The plugin has been transferred from my personal repository to its new home <https://github.com/jenkinsci/gradle-convention-plugin> 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 <https://github.com/jenkinsci/gradle-convention-plugin/issues/211>] Update Gradle Plugin Portal coordinates to the official Jenkins namespace (WIP, pending RFC <https://groups.google.com/g/jenkinsci-dev/c/AXZyPqgQzos> ). - [#214 <https://github.com/jenkinsci/gradle-convention-plugin/issues/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 <https://github.com/jenkinsci/gradle-convention-plugin/issues/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! On Monday, August 25, 2025 at 12:27:45 PM UTC+5:30 [email protected] wrote: > Hey Oleg, > > Thanks for taking the time for that elaborate explanations. > I was indeed unaware of the existence of such "3rd-party plugin > development" using Gradle, which of course is a valid use case for > providing more alternatives to the Maven toolchain. > Looking forward to hear more of this project and the improvements it > brings to the ecosystem. > > Thanks again Aarav for your determination and Oleg for the support. > > Daniel > > Oleg Nenashev schrieb am Sonntag, 24. August 2025 um 10:54:24 UTC+2: > >> 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 >> <https://community.jenkins.io/t/jenkins-governance-meeting-april-14-2025/30082> >> >> are not detailed, but you can see the video here >> <https://youtu.be/hDFnilJAW3k?si=vLJSYEr3gRgezh1L&t=1176>. 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 >> >> <https://github.com/search?q=user%3Ajenkinsci+path%3Abuild.gradle&type=code&ref=advsearch>. >> >> 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 >> >> >> On Thursday, August 21, 2025 at 1:59:29 PM UTC+2 >> [email protected] wrote: >> >>> Hello Aarav, >>> >>> 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. >>> Would you mind giving me an idea of what benefit Gradle could bring in >>> the long run over Maven? >>> Would it solve issues that currently can not be solved using Maven? >>> Would it make maintenance easier? >>> >>> BR, >>> Daniel >>> [email protected] schrieb am Donnerstag, 21. August 2025 um >>> 12:07:28 UTC+2: >>> >>>> Hello Jenkins Developers! [image: 👋] >>>> >>>> I am very excited to announce the Jenkins Gradle Convention Plugin >>>> <https://github.com/aaravmahajanofficial/jenkins-gradle-convention-plugin> >>>> — a Kotlin-first, Gradle Convention plugin (a feature similar to Maven >>>> Parent POM - docs >>>> <https://docs.gradle.org/current/samples/sample_convention_plugins.html>) >>>> that standardizes and simplifies building Jenkins plugins with Gradle. >>>> This >>>> plugin extends and builds upon the well-established gradle-jpi-plugin >>>> <https://github.com/jenkinsci/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 >>>> <https://github.com/oleg-nenashev>, Steve Hill >>>> <https://github.com/sghill> and Rahul Somasunderam >>>> <https://github.com/rahulsom>. >>>> >>>> For more details, check out the Project Idea Page >>>> <https://kotlinlang.org/docs/gsoc-2025.html#gradle-convention-plugin-for-developing-jenkins-plugins-easy-to-hard-90-hrs-to-350-hrs> >>>> >>>> and My Project Page >>>> <https://community.gradle.org/events/gsoc/2025/jenkins-plugins-toolchain/>. >>>> >>>> Here is also my demo from the mid-term evaluation: Google Drive Link >>>> <https://drive.google.com/file/d/1VaGFiRP466RS1FyaT6rT7xskZKXJ50x_/view?usp=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 >>>> <https://groups.google.com/g/jenkinsci-dev/c/lHQAiEepBiw?pli=1> 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 >>>> <https://plugins.gradle.org/plugin/io.github.aaravmahajanofficial.jenkins-gradle-convention-plugin/> >>>> >>>> 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 >>>> <https://github.com/jenkinsci/plugin-compat-tester/pull/795>. >>>> >>>> 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 >>>> <https://github.com/jenkins-infra/pipeline-library/blob/master/vars/buildPluginWithGradle.txt> >>>> >>>> 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 >>>> <https://github.com/aaravmahajanofficial/jenkins-gradle-convention-plugin>. >>>> >>>> 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 <https://slack.gradle.org/>. >>>> >>>> Best wishes, >>>> >>>> Aarav Mahajan <https://github.com/aaravmahajanofficial/> >>>> >>>> -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/de14baa8-c4bb-4b0b-8411-1e6e561a91cen%40googlegroups.com.
