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 > daniel.k...@googlemail.com 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 >> aaravmah...@gmail.com 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/a073934d-239a-4840-8d2a-7cb48044712bn%40googlegroups.com.
