Skip to content

GSoC 2025 - Gradle Convention Plugin for Developing Jenkins Plugins#

Status GitHub License Slack

TL;DR: Make Gradle a first-class, compliant, low-friction toolchain for Jenkins plugin development—on par with (and nicer to use than) Maven.

Overview#

This project aims to make Gradle a first-class tool for Jenkins plugin development by introducing a modern, Kotlin-first convention plugin built on top of the Gradle JPI plugin. This convention plugin will strictly adhere to the principle of Convention over Configuration (CoC). Its objectives are to ensure full compliance with Jenkins hosting requirements, achieve feature parity with Maven-based workflows, and deliver a streamlined developer experience. By automating best practices for build, test, and release, this project empowers the Jenkins community with a robust, future-proof, and efficient Gradle-based ecosystem—improving both developer productivity and plugin reliability.

For more details, refer to the Project Idea Page.

Project Banner
Smarter Jenkins plugin builds with Gradle — simple, fast, and modern.

Status#

Team#

Contributor#

Mentors#

Rationale#

  • Limitations of the Current Jenkins Build Ecosystem:

    • Jenkins plugin development is tightly coupled with Maven (Parent POM, Plugin Compatibility Tester, metadata, CI pipelines).
    • Gradle, though powerful, lacks standardized, hosting-compliant workflows, limiting adoption.

  • Existing Gradle JPI plugin is insufficient:

    • Non-compliance with Jenkins hosting requirements → blocks acceptance
    • Dependency management & BOM gaps → unreliable builds
    • Outdated Groovy-based codebase → harder to maintain
    • No convention plugin → developers face more configuration overhead

  • Developers need modern, efficient, and maintainable workflows: Despite Gradle strengths, Jenkins plugin development continues to be dominated by Maven due to deep alignment of core infrastructure with Maven conventions.

    Key Gradle advantages:

    • 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.

Note

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.

Deliverables#

Integration of Jenkins & Ecosystem BOM Management#

Status: Complete 🟢

Objectives:

  • Simplify dependency management for Jenkins plugin projects, eliminating "dependency hell" by providing robust, convention-driven BOM (Bill of Materials) integration.
  • Ensure that developers spend less time troubleshooting version conflicts & more time building features, with reliable, reproducible builds as the default experience.

Implemented Features:

  • Apply a curated set of BOMs (Bill of Materials) for Jenkins core & major ecosystem dependencies (Spring, Jackson, Jetty, Netty, SLF4J, Guava, Log4J, Vert.x, etc.) which leads to transparent, idiomatic BOM management.
  • Add support for toggling BOMs on/off via plugin DSL or Gradle properties.
  • Users may declare additional BOMs as needed for their plugins, including test-only.

Quality Tools & Static Analysis Integration#

Status: Complete 🟢

Objectives:

  • Minimize configuration burden & reduce boilerplate for plugin developers, raising the baseline of code quality across all Jenkins plugins built with Gradle.

Implemented Features:

  • Provide out-of-the-box integration with industry-standard static analysis & code quality tools (Checkstyle, PMD, SpotBugs, Detekt, Spotless, Jacoco/Kover, OWASP Dependency Check, Dokka, etc.) to enforce Jenkins community best practices.
  • Add effortless customization & conditional enablement/disablement of each tool via the plugin DSL or Gradle properties.
  • Enforce consistent, modern Kotlin project setup by auto applying recommended compiler options, JVM toolchain, & dependency alignment using a centralized version catalog; minimizing misconfiguration.

Publish Convention Plugin#

Status: Complete 🟢

  • Successfully published the Jenkins Gradle Convention Plugin on the Gradle Plugin Portal with proper versioning & metadata for discoverability and usability by plugin developers.

Add Unit/Integration Tests#

Status: Complete 🟢 | Actively Expanding 🟠

Related to: #112

Fix Metadata Generation#

Status: Complete 🟢

Objectives:

  • Improve the metadata/manifest/pom generation by automatically populating essential & previously missing manifest entries.

Resolved in: #134

Implementation Features:

  • Programmatically injected the missing manifest attributes in the GenerateJenkinsManifestTask of the gradle-jpi-plugin by creating an additional manifest file and merging it with upstream manifest files.

Native-Gradle Support for Plugin Compatibility Tester (PCT)#

Status: Under Review 🟡

Objectives:

  • Provide integration of PCT within Gradle builds, for enabling seamless cross-version testing of Jenkins plugins.

Pull Request: #795

Implemented Features:

  • Add ExternalGradleRunner and GradleExecutionException for Gradle support
  • Add support for extracting metadata from Gradle-generated POM files by gradle-jpi-plugin

Jenkins Plugin Hosting Request#

Status: Complete 🟢

Objectives: To get plugin source code hosted in a repository in the jenkinsci GitHub organization.

Resolved in: #4608

Solicit Feedback#

Status: In progress, actively collecting feedback 🟡

Objectives: Gather input from the Jenkins & Gradle communities to guide improvements and ensure the plugin meets developer needs.

Activites:

Roadmap#

Next steps for plugin delivery and integration:

  • Update the Gradle Plugin Portal Coordinates - see tracking issue #211
  • Support continuous delivery for Jenkins plugins
  • Integrate seamlessly with Jenkins pipelines (e.g., buildPluginWithGradle for CI)
  • Migrate to Gradle-JPI2-Plugin when new APIs are available

References#