A bit more news here. For years @Marcin Erdmann maintained the Webdriver Binaries plugin and did a jolly good job with it. As things go with OSS projects, sometimes single maintainers develop other priorities in life and project upkeep falls behind. So I am happy to announce that we have taken over the Webdriver Binaries plugin, made it compatible with configuration-cache and Gradle 9 and released it under a new plugin id

org.ysb33r.webdriver-binaries

with version

4.0.0

. You can find the documentation here, and the new project home is here. Contributions will be welcomed of-course. Please read the release notes before upgrading, as there are a number of breaking changes in the DSL.

Paper: Maven-Hijack: Software Supply Chain Attack Exploiting Packaging Order arxiv.org/pdf/2407.18760

🥇 Today was the first release of the Gradle Utilities plugin. It provides an extension called

grolifantOps

which contains quite a number of useful utilities for buildscript authors. People that authored plugins using Grolifant as a library might be familiar with a number of them already, but this plugin is aimed that at those that need more power when actually authoring `build.gradle(.kts)`files. All of the functionality is not yet described in the documentation, but you can get a good taste of some of the things already, by reading https://utilities-gradle.ysb33r.org/utilities-gradle-plugin/1.0.0/usage.html. The docs has the wrong plugin id, but the plugin portal is correct

org.ysb33r.utilities

. I hope that this functionality will be really useful to some.

⬇️ Sticking to the theme of small utility plugins,

grabatool 1.0.0

has been released. It has updated to handle Gradle

7.3.3 - 9.2.0

, and the DSL has been simplified.

grabatool

has only one purpose - allow build script authors to download arbitrary SDK, distributions and standalone executables, cache them, and make the appropriate locations available as providers. Nothing is downloaded until a provider is realised. If you used the old

0.5.0

you'll need to make some changes to your buildscript, but hopefully it will be clear enough in the docs on how to upgrade. Documentation is here: https://grabatool.ysb33r.org.

I received a notification from the Add support for updating gradle wrapper #2223 GitHub issue, which belongs to dependabot, stating the ticket was moved from Planned to Done.

Good mornig everyone. You could be interested in this new and simple to use plugin https://plugins.gradle.org/plugin/it.rebirth-project.catalog-dependencies-monitor check that out if interested. Regards.

Announcement We now have a channel (#C09F8V7L7QV) for community support of the Netflix Nebula OSS Gradle plugin ecosystem (https://nebula-plugins.github.io / https://github.com/nebula-plugins). If you haven't looked at the Nebula suite recently, you can quickly review the plugins (past and present) on the project status page: https://nebula-plugins.github.io/documentation/plugin_overview.html#project-status

This Thanksgiving season, we are thankful for the wonderful ArchUnit Project, which makes it very easy to write rules which enforce architectural patterns as well as API usage. To show our thanks, we are open-sourcing a Gradle plugin system for authoring and sharing rules across repositories: https://github.com/nebula-plugins/nebula-archrules-plugin we also have some OSS rule libraries to start: https://github.com/nebula-plugins/nebula-archrules but the real power is in writing your own rules! Take a look at the README for more details, and ask questions in #C09F8V7L7QV.

Hey folks, FYI looks like Cloudflare is down, which is impacting plugins.gradle.org. • https://www.cloudflarestatus.com/

New Gradle Blog post: https://blog.gradle.org/detect-maven-hijack-risks-in-gradle-with-plugin

Hi folks, I built DevAnalyzer because I kept losing storage to IDE leftovers, SDK folders, NDK installs, Gradle caches, and other hidden files. One day I discovered my setup was using 100+ GB — without me noticing 😅 So I created DevAnalyzer to help developers instantly understand: • Where their storage is going • How their SDK/IDE/Gradle environment is structured • What plugins/modules/dependencies their project really uses Website: https://coding-meet.github.io/DevAnalyzer Release: https://github.com/Coding-Meet/DevAnalyzer/releases Github: https://github.com/Coding-Meet/DevAnalyzer I’d love your feedback, ideas, or suggestions — and if you try the app,

Why write another plugin for publishing to Maven Central if there are already a number of them? At one time there were 18 plugins listed on the Publishing By Using a Gradle Plugin page. The reality was that the ones we investigated did not do what we required for the YSF. We would have preferred to use JReleaser, but it leaks far too many dependencies onto the plugin classpath, which makes it incompatible with some other plugins. We then decided to try nmcp, as we know some of the authors, but we found a limitation and even the authors recommended using the vanniktech plugin. The latter is really a great plugin plugin and in reality is the one to use when one needs Kotlin Multi-platform support. But for us it did too much - we needed something simpler. We also looked at a number of other plugins, including offerings DanySK, deepmedia, and yannanhub, but all of these plugins suffered from various shortcomings. So here we go, we released the Nempi plugin and it is: • Fully automated release by default. • Compatible with isolated projects. • Compatible with configuration cache. • Ability to have access tokens securely stored. • No hardcoded property names which could clash with other plugins. • Handle single project and multi-project layouts correctly. • As per typical Sonatype practice, pushes all artifacts in a single ZIP file. See the docs at https://nempi.ysb33r.org. (Plugin ID is

org.ysb33r.nempi

) If your project is the classic write a JVM-based code-base, make a JAR and publish to MavenCentral, then this might just be a plugin that works well for you too.

Sharing an effort started by @Aurimas Liutikas to list/document the Gradle metadata attributes: https://github.com/liutikas/gmm-wiki It's the early days but if you're a plugin author introducing a new attribute, consider opening a pull request so we can share best practices about how to use them.

* What went wrong: Execution failed for task 'expo modules coreconfigureCMakeDebug[arm64-v8a]'.

[CXX1214] C:\Users\uppal\Downloads\cometchat-uikit-react-native-5\FloxlyApp\node_modules\expo-modules-core\android\CMakeLists.txt debug|arm64-v8a : User has minSdkVersion 22 but library was built for 24 [//ReactAndroid/hermestooling]

can someone please tell me issue to get it fix I'm working with react-native-expo project for voipcall setup feature

I've written an article on the different terms used by Gradle and what they mean → https://ivan.canet.dev/blog/2026/03/02/gradle-vocabulary.html

Hey folks! We released a new version of the Plugin Publishing Plugin today. Starting with 2.1.0, you can declare your plugin's compatibility with Gradle features. For now, it's only the configuration cache; more will follow later. CC-compatible plugins will be promoted in the search results. We hope this will help the community become more aware of these features and, in particular, accelerate the widespread adoption of configuration cache, making everybody's builds faster. Please share your feedback! Here's how it looks:

Upcoming change: Gradle Forums moving to unified Gradle identity We’re updating how authentication works on the Gradle Forums. What’s changing Historically, forum accounts have been tied to Plugin Portal authentication. We are now migrating to a unified Gradle Identity, powered by Auth0. This unified identity will be used across Gradle services, including DPE University, Forums, and more. What this means for you • You will log in using the new unified Gradle identity • Existing accounts will be automatically merged where possible • You may be asked to authenticate with a different GitHub app if you used this method • You’ll be able to use more login methods • If you use password login, your credentials will remain the same Why we’re making this change • Improved security through a modern identity platform • Simpler and more consistent login experience across Gradle services • Better foundation for future improvements Current vs. target state • Today: Forum access is tied to Plugin Portal authentication • Target: A single unified Gradle identity across all services (DPE University, Plugin Portal, Forums, etc.) What’s next • The Plugin Portal will be the next service to adopt the unified Gradle identity, with more updates to follow.

We have a Netflix TechBlog post about the Nebula ArchRules plugin today: https://netflixtechblog.medium.com/scaling-archunit-with-nebula-archrules-b4642c464c5a

Why the Gradle Build Tool aggressively chases the newest JDK and how toolchains keep your build perfectly safe while we do. https://blog.gradle.org/gradle-is-javamaxxing

The JJ vs Git debate at Gradle: https://blog.gradle.org/the-petty-reason-we-didnt-end-up-using-jj-at-gradle

Since there's a Github Issue on this topic, now there's also a blog post: https://blog.gradle.org/three-kotlin-versions-in-a-gradle-project

Just look at that (drop in IJ EAP 7), it's about Gradle 10 provider api. https://youtrack.jetbrains.com/issue/IDEA-384547/Assist-with-upgrading-Gradle-to-versions-with-breaking-changes

Quite sad about provider delegates https://docs.gradle.org/current/userguide/upgrading_version_9.html#kotlin_dsl_delegated_properties I think they improved significantly the build legibility.

w: file:///.../buildSrc/build.gradle.kts:110:17: 'fun <T : Any, U : T> NamedDomainObjectContainer<T>.getting(type: KClass<U>, configuration: U.() -> Unit): PolymorphicDomainObjectContainerGettingDelegateProvider<T, U>' is deprecated. Use 'val element = getByName<Type>(name) { }' instead. See the Gradle 9.6 upgrading guide.

https://bsky.app/profile/andresalmiray.com/post/3mq2xbtlatc2e yet again

Dear All, Is there any community meetup that happens on a recurring basis?

Also if I can get the contacts for a discussion.

Yesterday 5.0.0 of the Javascript Ecosystem plugins suite was released. It still has support for the older way of doing things that the previous pluings versions supported, but it now has a much better way of managing toolchains in the Javascript ecosystem. IMO the mainline item in this release is the

pnpm

toolchain support, which also makes it very easy to take JS/TS-based tools and run them from Gradle i.e. Antora, Downdoc etc. Because you can allow

pnpm

to manage

node

on your behalf, it simplifies things even more. You can declare a set of packages to be associated with a toolchain and then prepare them with an instance of

PnpmPrepareTask

. You can then execute the appropraite packages from your toolchain using instances of

PnpmExecTask

(which under the hood calls

pnpm exec

with all the appropriate parameters and environment variables. This is a model similar to waht the JRubyPrepare and JRubyExec tasks do in the Simplified JRuby plugin suite. All tasks in this release should be CC-compatible and also work on Gradle 9 (although some of the legacy plugins might raise warnings on Gradle 9.7+). Docs are at javascript-gradle.ysb33r.org/javascript-ecosystem-gradle-plugin-suite/5.0.0/index.html

New video: Understanding Gradle #37 – Gradle on CI: GitHub Actions & TestLens In which I show the basics of defining a GitHub Actions workflow for Gradle builds and motivate why we built TestLens to close the gap in test reporting and failure analysis for Java projects on GitHub Actions CI. Get TestLens now: testlens.app