DEV Community: Gradle Community

Centralized POM Configuration Management with Maven Central utility plugins for Gradle

Yongjun Hong — Fri, 22 Aug 2025 16:06:02 +0000

As part of GSoC, I am developing a plugin that helps developers configure POM more easily. My work mainly focuses on reducing duplicated code and adding validation so that developers can use it more conveniently.

My ultimate goal is to enable developers to configure POM using my plugin and then publish their work through tools such as vanniktech/maven-publish.

Understanding Hierarchical Configuration Management

In multi-module Gradle projects, managing POM configurations can become a maintenance nightmare if you publish projects to Maven Central or another Maven repository. The primary challenge arises when each module and artifact require their own POM definition - even a single configuration change requires updating POM information across all modules throughout the project.

To address this issue, in the new https://plugins.gradle.org/plugin/io.github.yonggoose.maven.central.utility.plugin.setting and https://plugins.gradle.org/plugin/io.github.yonggoose.maven.central.utility.plugin.project plugins, I implemented a hierarchical management structure where POM configuration is defined once in the root project and automatically inherited by all submodules. This approach maintains consistency while providing flexibility - submodules can override specific properties when needed, ensuring both structural integrity and adaptability.

Root Project Configuration

Here's how you can set up centralized POM management in your root project:

Root Project's build.gradle.kts

plugins {
    id("java")
    id("io.github.yonggoose.maven.central.utility.plugin.project") version "0.1.7"
    id("maven-publish")
}

rootProjectPom {
    groupId = "io.github.yonggoose"
    artifactId = "organization-defaults"
    version = "1.0.0"

    organization {
        name = "YongGoose"
        url = "https://github.com/YongGoose"
    }

    mailingLists {
        mailingList {
            name = "Developers"
            subscribe = "dev-subscribe@example.org"
            unsubscribe = "dev-unsubscribe@example.org"
            post = "dev@example.org"
            archive = "https://example.org/archive"
        }
    }
    ...
}

With this root project configuration, all POM settings are automatically inherited by submodules.

Verifying Inherited Configuration in Submodules

Sub Project's build.gradle.kts

tasks.register("verifyPom") {
    doLast {
        if (!project.extensions.extraProperties.has("mergedDefaults")) {
            throw GradleException("there is no merged defaults")
        }

        val pom = project.extensions.extraProperties.get("mergedDefaults") as OrganizationDefaults
        check(pom.groupId == "io.github.yonggoose")
        check(pom.artifactId == "organization-defaults")
        check(pom.version == "1.0.0")

        check(pom.organization?.name == "YongGoose")
        check(pom.organization?.url == "https://github.com/YongGoose")

        check(pom.mailingLists.size == 1)
        check(pom.mailingLists.name == "Developers")
        check(pom.mailingLists.subscribe == "dev-subscribe@example.org")
        check(pom.mailingLists.unsubscribe == "dev-unsubscribe@example.org")
        check(pom.mailingLists.post == "dev@example.org")
        check(pom.mailingLists.archive == "https://example.org/archive")
    }
}

As demonstrated above, submodules can access inherited POM properties through mergedDefaults, confirming that the root project's POM attributes are successfully propagated. Additionally, submodules retain the flexibility to override specific properties when necessary.

Integration with Vanniktech Maven Publish Plugin

The Gradle Maven Publish Plugin (vanniktech) is a popular choice for publishing Android and Kotlin libraries to Maven Central, JCenter, and Nexus repositories. Here's how Maven-Central-utility-plugins-for-Gradle seamlessly integrates with it:

import io.github.yonggoose.organizationdefaults.OrganizationDefaults

plugins {
    id("java")
    id("io.github.yonggoose.maven.central.utility.plugin.project") version "0.1.7"
    id("com.vanniktech.maven.publish") version "0.34.0"
    id("maven-publish")
}

rootProjectPom {
    groupId = "io.github.yonggoose"
    artifactId = "organization-defaults"
    version = "1.0.0"
    ...
}

afterEvaluate {
    val mergedPom = project.extensions.extraProperties.get("mergedDefaults") as OrganizationDefaults

    mavenPublishing {
        coordinates(
            groupId = mergedPom.groupId,
            artifactId = mergedPom.artifactId,
            version = mergedPom.version
        )

        pom {
            name.set(mergedPom.name)
            description.set(mergedPom.description)
            url.set(mergedPom.url)
            ...
        }
    }
}

This integration demonstrates how Maven-Central-utility-plugins-for-Gradle's centralized configuration management works seamlessly with existing publishing workflows, eliminating the need for repetitive POM configuration across multiple modules.

Credits

This GSoC project was carried out under the guidance of my mentor, Oleg, to whom I am deeply grateful for his support and valuable insights. (Best mentor ever!!)
I would also like to acknowledge other mentors, such as martin, who have provided helpful feedback along the way!!

Gradle Convention Plugin for Developing Jenkins Plugins

aaravmahajanofficial — Mon, 18 Aug 2025 10:51:34 +0000

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.

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:

Non-compliance with Jenkins hosting requirements → blocks acceptance
Limited Plugin Compatibility Tester (PCT) support → weak cross-version testing
Dependency management & BOM gaps → unreliable builds
Outdated Groovy-based codebase → harder to maintain
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"
}

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

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

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

Quality tools pre-configured
BOMs automatically synced
PCT support
Compliance checks ready
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

Project Idea Page
My Project Page
My Proposal
GitHub Repository
Official Slack Channel - #jenkins-plugin-toolchain

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.

Enhanced Kotlin Code Quality Reporting with the Gradle Problems API

Vanessa Johnson — Mon, 04 Aug 2025 23:58:47 +0000

Improving Detekt's Quality Reporting with the Problems API

Static analysis tools like Detekt and Ktlint are popular and invaluable tools that are used for maintaining high code quality in Kotlin projects. An issue that affects a lot of developers is that the reporting of issues found in a project often speak different languages in a sense. You may see warnings in one format, errors in another, and diagnostics somewhere else. This results in developers juggling multiple outputs, CI jobs having to parse different report styles, and IDEs may struggle to present a cohesive view of issues.

We can unify these outputs via the Gradle Problems API. The Problems API reports rich structured information about problems happening during the build. This information can be used by different user interfaces such as Gradle’s console output, Build Scans, or IDEs to communicate problems to the user in the most appropriate way.

In my Google Summer of Code 2025 project, Enhanced Kotlin Code Quality Reporting with the Gradle Problems API, I built a proof of concept integration into Detekt.

Implementing a ProblemsApiConsoleReport

There are a few different types of reports that could have been considered which are the OutputReport and the ConsoleReport. However, since the Problems API surfaces structured problems and we don’t want to duplicate a formatted report, ConsoleReport is the appropriate tool for translating Detekt issues to the Problems API reporter.

Key behaviors of the custom report:

Injects Gradle’s Problems service.
Iterates over Detektion.issues, creating a ProblemId for each.
Populates metadata (file location, line number, severity, details) on the ProblemSpec.
Collects a fallback textual summary for output

detektion.issues.forEach { issue ->
           val group = ProblemGroup.create("validation", "detekt issue")
           val id = ProblemId.create(issue.ruleInstance.id, issue.message, group)
           reporter?.report(id) { spec ->
               val filePath = issue.location.path.toString()
               val line = issue.location.source.line
               spec.fileLocation(filePath)
               spec.lineInFileLocation(filePath, line)
               spec.details(issue.message)
               spec.severity(mapSeverity(issue.severity))
               reportLines.add(
                   "${issue.location.path}:${issue.location.source.line} [${issue.ruleInstance.id}] ${issue.message}"
               )
           }
       }
       return reportLines.joinToString(separator = System.lineSeparator())
   }
}

After publishing locally:

./gradlew publishToMavenLocal

Testing

I built the plugin jar and injected it into a temporary project via DslGradleRunner with this command:

./gradlew :detekt-report-problems-api:jar

The jar file was used in the dependencies of the mainBuildFileContent of the DslGradleRunner in the functional test:

mainBuildFileContent = """
           plugins {
               id("io.gitlab.arturbosch.detekt")
           }
           repositories {
               mavenLocal()
               mavenCentral()
           }
           dependencies {
               detektPlugins(files("${pluginJar.replace('\\', '/')}"))
               detektPlugins(gradleApi())
           }
           detekt {
               allRules = true
               ignoreFailures = false
           }
       """.trimIndent(),
       dryRun = false
   ).also {
       it.setupProject()
       val badClass = it.projectFile("src/main/kotlin/BadClass.kt")
       badClass.parentFile.mkdirs()
       badClass.writeText("class badClassName")
   }

The test sets up a deliberately bad Kotlin source class badClassName and expects Detekt to fail:

 gradleRunner.runTasksAndExpectFailure("detekt") { result ->
       val output = result.output
       assertThat(output).contains("The file does not contain a package declaration.")
   }

To validate the Problems API wiring more directly several tests were written, for example this unit test mocks Detektion and captures the ProblemSpec to verify that the correct fields (details, severity, file/line) are populated:

   whenever(detektion.issues).thenReturn(listOf(issue))
   val result = report.render(detektion)
   assertThat(result).isEqualTo("")

   val specCaptor = argumentCaptor<Action<ProblemSpec>>()
   verify(problemReporter).report(any(), specCaptor.capture())

   val spec: ProblemSpec = mock()
   specCaptor.firstValue.execute(spec)

   verify(spec).details("Class name should match the pattern...")
   verify(spec).severity(GradleSeverity.ERROR)
   verify(spec).lineInFileLocation(any(), eq(4))
   verify(spec).fileLocation(any())

Performance
Problems API Branch Performance Build Scan
Main Branch Build Scan

The Problems API integration does not seem to drastically change overall performance.

If you want to stay connected about the Problems API, join the Problems API channel in the gradle community slack!

You can also see the project page here which is still in progress.

Upcoming

The Problems API will be integrated in Ktlint and will be in a future post!

- Vanessa Johnson (GSoC 2025 Contributor)

Supporting Configuration Cache - my learnings from the Nebula Lint Plugin

Nouran — Thu, 17 Jul 2025 17:28:19 +0000

Project Context & Links

This post details the work done to add Gradle Configuration Cache compatibility to the gradle-lint-plugin.

Plugin: gradle-lint-plugin
Primary Pull Request: PR #433

Overview
Refactoring LintGradleTask
Refactoring LintService
Refactoring LintRuleRegistry
Guiding Principles for Other Classes
Technical Notes
Strategic Plan for Future Work

A hands-on journey into Gradle’s Configuration Cache , lessons learned, obstacles tackled, and contributions made during Google Summer of Code.

Overview

Welcome! This document details my journey improving Configuration Cache compatibility in Gradle plugins as a Google Summer of Code contributor. My goal is to offer a practical reference for plugin developers, Gradle users, and future GSoC applicants.

To demonstrate how to add this compatibility, we'll use my work on the gradle-lint-plugin as a real-world example of refactoring a plugin that relies heavily on the Project object.

LintGradleTask

The Problem: Accessing project at Execution Time
This is violate the Configuration Cache rules in a few key places:

Direct project access in the task action: The line

new LintService().lint(project, ...)

inside the @TaskAction directly used the project object.
Passing project to services: The GradleLintPatchAction and GradleLintInfoBrokerAction were created in the constructor with a direct reference to the project object, which they held onto until the task executed.

@TaskAction
    void lint() {
        //TODO: address Invocation of Task.project at execution time has been deprecated.
        DeprecationLogger.whileDisabled {
            def violations = new LintService().lint(project, onlyCriticalRules.get()).violations
                    .unique { v1, v2 -> v1.is(v2) ? 0 : 1 }

            (getListeners() + new GradleLintPatchAction(project) + new GradleLintInfoBrokerAction(project) + consoleOutputAction).each {
                it.lintFinished(violations)
            }
        }
    }

Solution:

The Configuration Cache works by recording the state of all tasks after the configuration phase and saving it. When you run the build again, Gradle can restore this saved state instead of re-configuring the entire project, leading to significant performance gains. This process fails if a task holds a direct reference to the live Project model, which is not serializable.

We solved this by creating simple, serializable data containers ProjectInfo and ProjectTree that act as a "projection" of the data we need from the Project object.

Here’s a breakdown of the key changes and the "why" behind them:

1) Create Serializable Data Containers (ProjectInfo & ProjectTree)
The first step was to define classes that could hold the project data we needed, but in a simple, serializable way.

ProjectInfo: It stores primitive data like name, path, File objects, and serializable collections like Map. It safely carry information from the configuration phase to the execution phase.

ProjectTree: This class holds a list of ProjectInfo objects, representing the entire project structure needed for the linting process. It is also serializable.

Learning: If you need data from the Project object during execution, create a dedicated, Serializable class to hold that data.

/**
 * A CC-compatible projection of project data.
 */
class ProjectInfo implements Serializable{
    String name
    String path
    File rootDir
    File buildFile
    File projectDir
    File buildDirectory
    GradleLintExtension extension
    Map<String, Object> properties
    Supplier<Project> projectSupplier

    static ProjectInfo from(Task task, Project subproject) {
        String subprojectPath = subproject.path
        return build(subproject, { task.project.project(subprojectPath) })
    }

    static ProjectInfo from(Task task) {
        return build(task.project, task::getProject)
    }

    @VisibleForTesting
    private static ProjectInfo build(Project project, Supplier<Project> projectSupplier) {
        GradleLintExtension extension =
                project.extensions.findByType(GradleLintExtension) ?:
                project.rootProject.extensions.findByType(GradleLintExtension)
        Map<String, Object> properties = [:]
        if (project.hasProperty('gradleLint.rules')) {
            properties['gradleLint.rules'] = project.property('gradleLint.rules')
        }
        if (project.hasProperty('gradleLint.excludedRules')) {
            properties['gradleLint.excludedRules'] = project.property('gradleLint.excludedRules')
        }

        return new ProjectInfo(
                name:project.name,
                path:project.path,
                rootDir:project.rootDir,
                buildFile: project.buildFile,
                projectDir:project.projectDir,
                extension: extension,
                properties: properties,
                projectSupplier: projectSupplier,
                buildDirectory : project.buildDir
        )

    }
}

class ProjectTree{
    List<ProjectInfo> allProjects

    ProjectTree(List<ProjectInfo> allProjects){
        this.allProjects = allProjects
    }

    /**
     * Returns the base project this tree was built from.
     */
    ProjectInfo getBaseProject() {
        return allProjects.head()
    }

    /**
     * Build a project tree based on the given task's project.
     *
     * @return a project tree reflecting information and the structure of the given task's project
     */
    static from(Task task) {
        def baseProject = task.project
        List<ProjectInfo> projectInfos = [ProjectInfo.from(task)] + baseProject.subprojects.collect { Project p -> ProjectInfo.from(task, p) }
        return new ProjectTree(projectInfos)
    }
}

Capture Project Data During the Configuration Phase The task constructor is part of the configuration phase, so it's the perfect place to safely access the project object and extract our data. We use Gradle's Provider API to do this lazily.

LintGradleTask() {
        failOnWarning.convention(false)
        onlyCriticalRules.convention(false)
        projectTree.set(project.provider {ProjectTree.from(this) })
        projectInfo.convention(projectTree.map(ProjectTree::getBaseProject))
        projectRootDir.set(project.rootDir)
        infoBrokerAction = new GradleLintInfoBrokerAction(this)
        patchAction = new GradleLintPatchAction(getProjectInfo().get())
        group = 'lint'
    }

project.provider { ... }

: This creates a Provider. The code inside the closure is executed by Gradle during the configuration phase. It accesses the project and creates our serializable ProjectTree.

.set(...)

: We set this Provider as the value for our projectTree property.

.map(...)

: We then create a derived provider for the projectInfo by transforming the result of the projectTree provider.

Learning: Use the Provider API inside your task's constructor to capture and transform project data without breaking task-configuration avoidance.

LintService

We transform LintService from a class deeply integrated with Gradle's live project model into a stateless service. The new design makes it compatible with the Configuration Cache by ensuring it operates exclusively on simple, serializable data during the task's execution phase.

The Problem: A service that is associated with the Project instance

The original LintService was not compatible with the Configuration Cache because its methods required a live Project object as a parameter.

Methods like

lint(Project project, ...)

and

ruleSetForProject(Project p, ...)

directly manipulated Project objects.

It would read configuration dynamically by calling

p.extensions.getByType(...)

and

p.property(...)

This design meant the service could only function when connected to the live Gradle build model, making it impossible for Gradle to serialize the task that uses it.

The Solution: A stateless service using pre-existing configuration data from the Project object

Updated LintService Full Code

The refactored LintService is now completely decoupled from the Project object at execution time. It operates like a pure function: it receives all the data it needs as input (ProjectTree and ProjectInfo) and produces a result.

Accepting Data Projections Instead of Project Objects The most significant change is in the method signatures.

Before:

lint(Project project, ...)

After:

lint(ProjectTree projectTree, ...)

The service no longer receives the Project object. Instead, it gets the ProjectTree ,our serializable snapshot of the entire project structure. All subsequent operations, like iterating over subprojects, are done using this simple data object

(projectTree.allProjects.each { ... })

Reading Configuration from Snapshots The service now gets all its configuration from the ProjectInfo data transfer object.

Before: It actively queried the project for properties and extensions:

p.hasProperty(...)

p.extensions.getByType(...)

After: It passively reads pre-extracted data from the input:

projectInfo.properties[...]

and

projectInfo.extension

This ensures the service doesn't need to communicate with the live build model. All the decisions were already made during the configuration phase, and the results were stored in ProjectInfo.

Isolating Operations That Require the Live Model The new code cleverly handles rules that must access the live project model ModelAwareGradleLintRule.

It first checks if any such rule is present

(if (containsModelAwareRule))

Only if it's true does it use the

supplier (Project project = p.projectSupplier.get())

to re-acquire the Project object when it really needed.

This is an advanced pattern that minimizes the impact on caching. The non-cache-friendly code path is isolated and only executed when absolutely necessary.

Learning: Services called by a cacheable task must also be cache-friendly. They should be designed to be stateless, receiving all necessary information through their method arguments and avoiding any direct interaction with the Project object during the execution phase.

LintRuleRegistry

The Problem: Directly Injecting the Project Object

The original LintRuleRegistery created a direct and hard dependency on the Project object, which is a blocker for the Configuration Cache.

The buildRules method took a Project as a parameter and, for certain rules, assigned it directly to a field:

(r as ModelAwareGradleLintRule).project = project

This meant that any ModelAwareGradleLintRule instance created by the registry held a reference to the non-serializable Project object, making it impossible for Gradle to cache any task that used this registry.

The Solution: Lazily Access Project with a Supplier when it needed

Updated LintRuleRegistery
The solution was to stop passing the Project object itself and instead pass a

Supplier<Project>

a lightweight, serializable object that knows how to get the Project object later.

Injecting the Supplier, Not the Project
A new, primary buildRules method was introduced with a new signature.

Before:

buildRules(String ruleId, Project project, ...)

After:

 buildRules(String ruleId, Supplier<Project> projectSupplier, ...)

The critical line inside was changed to inject this new supplier:

(r as ModelAwareGradleLintRule).projectSupplier = projectSupplier

This is the core of the fix. Instead of giving the rule the Project object directly, we are now giving it a "recipe" to get the project if and when it actually needs it. The Supplier is serializable, so the entire process becomes cache-friendly.

Learning : Object creation logic is a common source of Configuration Cache issues. When an object you are creating needs access to the Project model, inject a Supplier instead of the Project object itself. This defers the access and allows the object and its creation process to be serializable.

Guiding Principle for the Remaining Classes

The rest of the refactoring follows a single, consistent rule: Any class used during the task's execution phase must be decoupled from the Project object.

This is achieved by applying one of two patterns:

Operating on Data (ProjectInfo): If a class needs to read data from the project, its methods are changed to accept a ProjectInfo or ProjectTree object as a parameter. All internal logic is then updated to read from this serializable data instead of the live Project object.
Deferring Access (Supplier): If a class absolutely must interact with the live project model (the "escape hatch" scenario), it's given a Supplier. This allows it to re-acquire the Project object on-demand, a process that is compatible with the Configuration Cache.
Original Source Code (Before Changes):
Updated Source Code (After CC Compatibility Changes):

Technical Notes

findByType() vs. getByType()

When working with Gradle extensions, there are two common methods to retrieve an extension by its class:

findByType()

and

getByType()

The key difference lies in how they behave when an extension is not found.

getByType(Class<T> type)

Returns: The extension instance if it exists.

Throws: An UnknownDomainObjectException if the extension does not exist.

Use this when you consider the extension's presence mandatory for your plugin's logic to proceed.

findByType(Class<T> type)

Returns : The extension instance if it exists.

Returns : null if the extension does not exist.

Use this when the extension is optional, and your code needs to safely handle cases where it might be missing.

Notes on Gradle TestKit

For those new to testing Gradle plugins, the Gradle TestKit is an essential tool. It allows you to run real builds as part of your tests, giving you confidence that your plugin behaves correctly for end-users.

I started by learning from the official TestKit documentation and by studying the extensive examples in the nebula-lint-plugin's existing test suite. I also found the talk "Testing the Build with Testkit" to be very helpful for understanding the different types of tests.

Here are some key takeaways:

Types of Tests:

Unit Tests:

Focus on a single class in isolation.
The class under test does not use the Gradle API.

Integration Tests:

The class(es) under test use Gradle APIs, often interacting with a Project instance.
These do not execute a full build but test the integration with Gradle's model.

Functional Tests (The focus of TestKit):

Executes a build script from an end-user's perspective.
Examines the build outcome, output, and any created files.
Runs in a fully isolated test environment.

The Structure of a TestKit Test
Most functional tests follow a clear "Given-When-Then" structure, which makes them easy to read and understand:

given block: Sets up the test environment. This is where you create a temporary project directory and write the build.gradle or other files needed for the test.

when block: Executes a Gradle task using the GradleRunner. This is where you run the build (e.g., ./gradlew lintGradle).

then block: Verifies the outcome. Here, you use assertions to check if the build succeeded or failed, inspect the build output, or verify that files were created or modified as expected.

Strategic Plan for Future Work

The following notes serve as a technical blueprint for completing the Configuration Cache compatibility work in the Nebula Lint plugin or for tackling similar challenges in other Gradle plugins. This strategic plan breaks down the complex problem into manageable steps.

1. Understanding the Challenge
What the Plugin Does: The plugin works by building an Abstract Syntax Tree (AST) of a build script and then traversing it with a set of rules.

The Core Issue: Many of these rules rely on querying Project.configurations at runtime to analyze dependency setups. This dynamic querying is precisely what breaks the Gradle Configuration Cache, which forbids accessing the live Project model during the execution phase.

2. Defining the Goal
The objective is to refactor the plugin so that rules operate on pre-computed, serializable data instead of the live Project object.

Separate Configuration Queries: Decouple rules from Project.configurations by having them work with a "data projection"—a snapshot of the configuration data taken at the right time.
Enable Configuration-Time Setup: Move all data gathering to Gradle's configuration phase, avoiding runtime queries entirely.
Refactor Incrementally: Start with simpler, purely syntactical rules (like SpaceAssignmentRule and DependencyParenthesesRule) to build momentum and prove the approach.

3. The Step-by-Step Plan

Identify Configuration Usage: First, examine each rule to understand how it interacts with Project.configurations. Does it read dependencies? Resolve configurations? Check attributes?
Extract Configuration Data: Create a simple data object (e.g., ConfigurationInfo) to hold only the necessary information. This data should be computed once during the configuration phase using Gradle's Provider API.
Simplify Rule Dependencies: Refactor the rules to depend on the new ConfigurationInfo data object instead of accessing Project.configurations directly.
Modify the Data Flow: Enhance the main ProjectInfo data object to include this new ConfigurationInfo structure, making it available to all rules that need it.
Test Incrementally: After refactoring each rule, test it thoroughly with various build scripts to ensure its original functionality remains intact and that it no longer violates Configuration Cache rules.

By following this iterative plan, anyone can progressively improve a plugin’s compatibility with the Gradle Configuration Cache while ensuring it remains stable and functional.

A Heartfelt Thank You

A sincere thank you to the Google Summer of Code program for this experience. I am especially grateful to my mentors for their exceptional support and guidance throughout the project.

Written by Nouran Atef, GSoC 2025 Contributor

Announcing Dependency Analysis Gradle Plugin 2.0.0!

Tony Robalik — Tue, 27 Aug 2024 21:24:18 +0000

Cover photo by Sandie Clarke on Unsplash

The Dependency Analysis Plugin v2.0.0 has just been released!

Why 2.0.0?

Breaking changes, of course. The ABI has been updated, which is relevant for anyone accessing the analysis results programmatically. There has also been an important behavioral change, which will be relevant to all users.

ABI changes

The PluginAdvice class has been moved from the com.autonomousapps.advice package to the com.autonomousapps.model package, where all the other public model classes live.

The FindInlineMembersTask has been renamed to FindKotlinMagicTask, to better reflect what it actually does. This is unlikely to impact any users, but since it has public visibility, it might.

Finally, the deprecated ignoreKtx() option has been removed from the issues block. It can now only be configured from the structure block.

Behavioral changes

The plugin no longer automatically applies itself to every subproject in your build. Therefore the dependency.analysis.autoapply flag is now a no-op, and using it will either emit a warning (when the value is set to false) or fail your build (if the value is set to true, which was the old default). Users now have two choices if they want to analyze subprojects in their build:

First, you can apply the plugin directly to every module you want to analyze. This has long been the best practice for how to use this plugin.

Second, you can use the new com.autonomousapps.build-health plugin! Apply it to your settings.gradle[.kts] like so:

// settings.gradle[.kts]
plugins {
  id("com.autonomousapps.build-health") version "2.0.0"
}

// And you can configure it from the settings
// script, too!
dependencyAnalysis {
  ...
}

This new plugin is only available from Gradle 8.8. See the wiki for more information, especially if you also use Android or Kotlin.

In order to assist users who might update to 2.0.0 without reading the release notes, the plugin has been updated to attempt to detect the case where the plugin has been applied only to the root project but not to any subproject; this would almost certainly be a user error.

Happy building!

Thanks for being a user, and please keep filing issues if you run into any bugs.

Kradle 9.0: Revolutionizing the JVM Ecosystem with Kotlin at its Core!

Oleg Nenashev — Mon, 01 Apr 2024 16:03:26 +0000

We're thrilled to unveil Kradle 9.0, a groundbreaking release that marks a significant leap forward in the Java ecosystem. With Kradle 9.0, we're embracing Kotlin as the default language for build definitions, starting a new era of simplicity, efficiency, and developer empowerment.

Hence, the Gradle Build Tool now becomes the Kradle Build Tool and gets a new logo!

Key Highlights

🌟 Kotlin as Default Language: Say goodbye to verbosity and complexity! Kotlin is now front and center for defining builds in the JVM ecosystem. In Gradle 8.2 we made it the the default and recommended choice for new build definitions. In Kradle 9.0, the Kotlin DSL Plugin is now a built-in part of the core distribution, while Gradle support is detached to a plugin, which we will keep maintaining. Now, developers can leverage the elegance and expressiveness of Kotlin to streamline their build processes effortlessly.

🚀 Enhanced Developer Experience: We've doubled down on developer experience, prioritizing ease of use and seamless integration by projects like Declarative Gradle. With Kradle 9.0, you'll enjoy a more intuitive and enjoyable development journey, thanks to Kotlin's concise syntax, powerful features, and great DSL customization capabilities through idiomatic definitions.

💡 Developer Productivity Engineering: At Gradle, we understand the importance of developer productivity. That's why we've engineered Kradle 9.0 to supercharge your productivity like never before. Whether building small projects or large-scale applications, Kradle 9.0 empowers you to accomplish more in less time with the help of the new Krataouille framework that allows you to implement build definitions in a wholly asynchronous and functional way based on Kotlin coroutines.

🔧 Rewritten in Kotlin: As part of our commitment to embracing Kotlin, we've completely rewritten Gradle Build Tool itself in Kotlin. This monumental effort ensures seamless compatibility, improved performance, and a more cohesive development experience across the board. We target full support for the K2 compiler soon.

What's next?

And let’s talk about the elephant in the room! As one of the insiders shared, future releases of the Kradle are rumored to be based on Starlark (formerly known as Skylark), the language used in Bazel.

Code named Gradlark, this new version will be another step towards the long-awaited complete Python implementation of the Kradle Build Tool, and it should attract more Python developers and monorepo fans.

Get started!

Whether you're a seasoned veteran or just getting started, Kradle 9.0 is your gateway to a brighter, more efficient future in the JVM ecosystem. Join the Future of JVM Development with Kradle 9.0!

Upgrade today and experience the next evolution in build automation and developer productivity engineering. And join the Gradle Community Slack to follow more community news and Gradle memes!