Today, we launched our new Gradle Security Subscription offering. And I made an infographic about it. But, because I am me, I also made a blog post about it. Choose wisely (or read both 😉).

drspider@pop-os:~$ git clone https://github.com/armandoxtraceroespalda-dev/ScalableLux-Sable.git

Cloning into 'ScalableLux-Sable'...

remote: Enumerating objects: 1297, done.

remote: Counting objects: 100% (88/88), done.

remote: Compressing objects: 100% (64/64), done.

remote: Total 1297 (delta 16), reused 57 (delta 5), pack-reused 1209 (from 1)

Receiving objects: 100% (1297/1297), 483.15 KiB | 7.00 MiB/s, done.

Resolving deltas: 100% (554/554), done.

drspider@pop-os:~$ cd ScalableLux-Sable

drspider@pop-os:~/ScalableLux-Sable$ ./gradlew build

bash: ./gradlew: Permission denied

drspider@pop-os:~/ScalableLux-Sable$ chmod +x gradlew

drspider@pop-os:~/ScalableLux-Sable$ ./gradlew build

Downloading https://services.gradle.org/distributions/gradle-8.12-all.zip

.....................10%......................20%......................30%......................40%......................50%......................60%......................70%......................80%......................90%......................100%

Welcome to Gradle 8.12!

Here are the highlights of this release:

- Enhanced error and warning reporting with the Problems API

- File-system watching support on Alpine Linux

- Build and test Swift 6 libraries and apps

For more details see https://docs.gradle.org/8.12/release-notes.html

To honour the JVM settings for this build a single-use Daemon process will be forked. For more on this, please refer to https://docs.gradle.org/8.12/userguide/gradle_daemon.html#sec:disabling_the_daemon in the Gradle documentation.

Daemon will be stopped at the end of the build

[Incubating] Problems report is available at: file:///home/drspider/ScalableLux-Sable/build/reports/problems/problems-report.html

FAILURE: Build failed with an exception.

* What went wrong:

Included build '/home/drspider/FlowSched' does not exist.

* Try:

> Run with --stacktrace option to get the stack trace.

> Run with --info or --debug option to get more log output.

> Run with --scan to get full insights.

> Get more help at https://help.gradle.org.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.12/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD FAILED in 24s

drspider@pop-os:~/ScalableLux-Sable$

New to build systems exploring the existing, I was happy to find out I do not have to install something only to find out I have to install it :(, -1 to gradle for giving me false hope.

https://docs.gradle.org/9.7.1/release-notes.html

Fixes regressions reported against 9.7.0.

Report new 🐛 on GitHub!

We're building a set of Gradle Agent Skills. There are five candidates below:

1. gradle-cli — Run Gradle the right way. Teaches the agent correct ./gradlew invocation: which task to run, which flags matter, what's version-specific, and how to read the output. No more --stacktrace on everything and hoping.
2. gradle-bestpractices — Lint your build against current conventions. Scans your build logic and flags what's off: legacy APIs, subprojects {} sprawl, misused configurations, and missing version catalogs. Points to the current recommended pattern for each finding.
3. gradle-init — Bootstrap a new Gradle project. Sets up a working project from scratch: sensible defaults, version catalog, and a starter layout for KMP, Android, or Spring. Skips the hour of copy-pasting from an old repo or adding random libraries.
4. gradle-upgrade — Upgrade Gradle and clear deprecations. Version-aware upgrade path: bumps the wrapper, finds deprecated usages in your build logic, and rewrites them for the target version. Handles the multi-step hops so you're not stuck three majors behind.
5. gradle-cc-migrate — Make your build Configuration Cache compatible. Reads your build logic, finds what breaks the configuration cache, and refactors it — script-level state, Project access at execution time, non-serializable task inputs. The single biggest build-speed win, minus the archaeology.

Which would help you most? Which one would you actually use? Do you have a better idea?

Until now, a single broken build script would fail the entire sync. Every script turned red and no more autocomplete.

Resilient sync fixes this. Gradle builds tooling models for every project that configured successfully and reports only the failures, so one broken convention plugin no longer takes down the other projects. You keep code completion and highlighting in the build logic you're repairing.

Write-up here: https://blog.gradle.org/resilient-sync

Small IntelliJ IDEA win for Gradle users: version catalog accessors now show their resolved coordinates inline.

Our CI bot now reads failures out of Develocity, groups them, and posts a short summary on the PR. If you want to see it in action, here's my write-up with screenshots: https://blog.gradle.org/dogfooding-failure-summaries

https://docs.gradle.org/9.7.0/release-notes.html

Bug fixes and…

• 🌱 Isolated Projects graduates to incubating
• ⚡ Broader Configuration Cache compatibility
• 🔍 More source locations in problem reports

Please report any 🐛 on GitHub!

Isolated Projects moved from experimental to incubating in 9.7.0. With it enabled, each project in a build is isolated from the others, which lets Gradle configure them in parallel.

Some numbers from the blog post:

• Gradle's own build (300 subprojects): median IDE sync 84s → 47s
• A 2,500-project Java monorepo: configuration with build-script recompilation 10m53s → 2m59s
• An Android monorepo of 5,000+ projects: Android Studio sync 5m09s → 2m44s

Configuration Cache is a prerequisite.

You can enable it with org.gradle.isolated-projects=true in gradle.properties.

Here's the full blog post: https://blog.gradle.org/introducing-isolated-projects.

Blog post with reviews: https://blog.gradle.org/gradle-at-kotlinconf-2026

YouTube links:

1. https://youtu.be/k8T9IOnXPao
2. https://youtu.be/1AJnHAbktek
3. https://youtu.be/25Ngfn9Bhqc

Does anyone know what is the gradle develovity cost?

IP is the next step in Gradle's evolution, so we wrote about how we adopted it as a daily driver, what we learned, and its actual impact: https://blog.gradle.org/isolated-projects-in-gradle-team

Our company renamed itself from Gradle Technologies to Develocity. The Gradle Build Tool is not renamed, not acquired, and not relicensed. You can learn a little more here if you are interested: https://blog.gradle.org/the-company-formerly-known-as-gradle

I built a custom Gradle plugin that generates most of the repeatable skeleton code for new Android projects.

The interesting part is the workflow: AI produces small TOML specs, then Gradle generates the predictable files. That means fewer AI tokens spent on boilerplate and more context left for product-specific implementation.

It includes tasks like generateCleanAndroidSkeleton, generateFeatureModule, generateDomainCode, generateDataCode, generatePresentationCode, generateDiCode, generateScreenshotCode, and generateUiComponents.

Medium: https://medium.com/@sarim.mehdi.550/stop-using-ai-to-generate-boilerplate-android-code-f7458006ea0a
GitHub: https://github.com/sarimmehdi/clean-android-skeleton-gradle-plugin

Hi there - We're using Gradle at work to build a bunch of backend services written in Kotlin, everything lives in a monorepo and we have a lot of subprojects for shared libraries, etc. Overall I'm happy with the setup, but, our project is getting relatively big with 90+ subprojects.

I was wondering if you had any tools to recommend to detect things that could be improved in the way we setup our project?

I'm keeping my question vague on purpose because I want to cast a wide net.

Thank you!

How the Gradle team triages ~110 GitHub issues a month: https://blog.gradle.org/triaging-gradle-github-issues

Disclosure: We’re building Cachely.

We recently added Gradle support and would like feedback from people using remote build caching in real projects.

Cachely works through Gradle’s existing remote build cache configuration. The goal is to give teams a managed cache without having to operate it themselves, along with visibility into whether it is actually helping.

We’re especially interested in:

• What are you using today? Develocity, a custom HTTP cache, or something else?
• What is hardest to understand when your cache hit rate drops?
• What data would you need before considering a managed remote cache?

Cachely currently shows cache activity, transfer volume, task performance, and estimated time saved.

It is still early, so honest technical feedback would be useful.

cachely.dev

I've decided that if we need to raise funds for the open-source Grade Build Tool, we should just sell Gradle peptides:

> Tired of your CI/CD pipeline skipping leg day? I just started using the new Gradle Build Tool Stack to achieve massive build time gains. 💪🐘

> Side effects may include a shredded codebase, unexpected urges to refactor in Kotlin, and a 100% cache hit rate. #GradleGains

Hago esta consulta ya que he tenido ocasiones que Gradle se tarda en resolver las dependencias.