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

Hey folks, we have a new #C0BQK6SC4LT channel and would love your feedback: https://gradle-community.slack.com/archives/C0BQK6SC4LT/p1787154460508549

A bit more than 11 years ago GradleTest 0.5 was released. It preceded Testkit and it was born out of frustration of hard it was to test a plugin against multiple versions of Gradle. it basically used

javaexec

to run different version of Gradle against a test set. Simplistic, raw and rough around the edges it got the job done. Testkit would eventually come along and GradleTest evolved to use that under the hood, making debugging easier and simplify setup for more complex test cases. Anyhow, after that history tidbit, I am glad to announce the GradleTest 5.0.0 got released today. It comes with three main features. • Support for using custom JDKs in testing. You can create a test set which uses a JDK other than your other compatibility tests. Let's say you build your plugin against JDK11, but want to test against Gradle9, you can create a second test set where the JDK is set to 17. I_t even comes with the option to perform variant selection when it is needed. (Thanks to some tips from @Vampire)_ • Support for testing a plugin against isolated projects if the Gradle version under test is Gradle 9.7+ • Better customisation of a per-version basis. You can change behaviour depending of the Gradle version under testing including activating or silencing specific deprecation warnings, configuration cache modes and now isolation project modes. The new DSL is a good departure away from the clunky 4.0 DSL for version customisation. And it has been tested on a host Gradle version range of 7.3 to 9.7. More info here and hopefully you'll find it useful to test your own plugins. gradletest.ysb33r.org/gradletest/5.0.0/index.html

party gradlephant Today we launched the Gradle Security Subscription: gradle.org/security-subscription! Of course, I wrote a blog post about it. Short version for this channel: nothing changes for open source Gradle. Same EOL policy, same security fixes under it. The subscription adds SLA-backed fixes, coverage for versions past EOL, and embargoed disclosure for orgs that need contractual guarantees. The post also gets into why the toolchain is worth attacking in the first place, with receipts.

Ever had to look up operating system or architecture details in a build script? Yes, it's PITA. You either have to fiddle with reading system properties (and half of the time you can never remember what the correct values are) OR you try to access the internal class

OperatingSystem

. Well, you don't have to suffer. You can have all that information (and more) with the Operating System plugin. It adds an extension called

OS

. What's new with the latest release? • There is a version that you can apply to

settings.gradle(.kts)

• If you work with variants you can even obtain the correct values you need for operating system and machine architecture. • If you need to look up values for OS/Arch for anything other that what Gradle is running on, you can do that do now via

getOsTypes()

and

getArchitectures()

. Hope it helps to resolve some pain for some of you. See the link for more details. os-gradle.ysb33r.org/operatingsystem-gradle-plugin/3.0.1/usage.html

Another release of GradleTest today - 5.1.0. The initial feature was to support Gradle 9.8 and JDK27, but along the way it also added a feature to use a custom manifest per Gradle version under test if anyone needs it. Because yes, you might develop using one version of the JDK and a specific Gradle API, but you might want to test against a different JDK & Gradle version family. And sometimes that affects variants, especially if transitive dependencies have variants. Now you can control that behaviour very simply. (rolling that kind of thing manually with Testkit can be PITA). See gradletest.ysb33r.org

_Preamble_: People are usually aware of lifecycle tasks such as

build

,

check

and

assemble

. Although sufficient for smaller projects I have found doing work for a number of organisations that a couple of petterns arise that really need to have additional lifecycle tasks. Having those also means that CI pipeline recipes can be simplified such that the pipelines only have to call the appropriate lifecycle tasks. Build script and plugin authors can then focus on adding the appropriate tasks into these lifecycle tasks. Anyhow, I finally got fed up, having to recreate similar setups, so I created a lightweight set of plugins that can be reused and hopefully be some standardisation for people. Obviously if you have already done something like this in your organisation, you have no need for this, but if you are building from scratch again or would like for standard, this could be helpful to you. I've setup it up in such a way that you can take all of the lifecycle tasks, or just a subset. There is seven lifecycle tasks in this release. Feel free to discuss or contribute more if you want. gradle-lifecycles.ysb33r.org/lifecycle-tasks/1.0.1/tasks.html

Hey folks, Have you migrated to Isolated Projects? If not, please share in the thread, what's your main blocker 💭 - thinking about it ⏳ - in progress 🧑‍💻 - using for local workflows (IDE sync) 🚦 - using on CI

For the native folks, the Gradle Doxygen plugin

3.0.0

got released today. Not many changes, but there are some important notes: • Only bootstraps versions

1.16.0+

of Doxygen. • Defaults to using version

1.18.0

of Doxygen. • Is now tested to be compatible with both Isolated Projects (Gradle 9.7.0+) and Configuration Cache. • Minimum runtime requirements are JDK8 and Gradle 7.3.3 Details here: doxygen-gradle.ysb33r.org

Hey folks, after a long time lying around as an alpha release Asciidoctor Gradle 5.0.0 is finally out! It has been tested up to Gradle 9.7.1 and is compatible down to 8.0.2. depending on the specific plugins used a minimum of JDK8 or JDK11 is required. All of the model5 plugins that has the new DSL are compatible with CC & IP. The only exception might be Downdoc. I suspect it is, but it does have tests for that atm. The old DSL is still around, but the plan sort of is to dump that in the 6.x release. I am not sure whether the documentation has propagated yet as that is handled by a different project over which this project has no control. At the same time, I am also announcing that I am stepping down as the main maintainer of this project. I simply do not have the time to spend on it, as there are a lot of other plugins I have to look after. I'll still be around to help a bit, but it is time for someone else to come forward and take on the responsibility of at least performing bug fixes.

Hey folks! 👋 Plugin authors can now declare that their plugins are compatible with Isolated Projects when publishing to the Plugin Portal. When declarations for Configuration Cache landed in March (announcement), we promised more features would follow. Starting with Plugin Publish Plugin 2.2.1, you can add

isolatedProjects

right next to `configurationCache`:

gradlePlugin {
    plugins {
        create("myPlugin") {
            id = "io.github.my.plugin"
            // ...
            compatibility {
                features {
                    configurationCache = true
                    isolatedProjects = true
                }
            }
        }
    }
}

Before enabling Isolated Projects, most users first want to know whether their plugins support it. A declaration answers that on your plugin's page and can help your plugin in search results. Declaring

false

is useful too -- there's no penalty for it. All you need is the new Plugin Publish Plugin version, no Gradle upgrade required. We've also covered it in the Gradle 9.8.0 release notes, out today, and in the user manual: • Release notes: Declaring plugin compatibility with Isolated Projects on the Plugin Portal • User manual, with Kotlin and Groovy snippets: Declaring compatibility with Gradle features • New to Isolated Projects? Start here: Isolated Projects A few things to know: • In the Kotlin DSL,

compatibility

needs `import org.gradle.plugin.compatibility.compatibility`; in Groovy, it's

compatibility(it) { ... }

. • While Isolated Projects is incubating, the declaration shows up in the compatibility table on your plugin's page, marked "(Incubating)", but not as a badge at the top yet. • Isolated Projects constraints may get stricter before the feature is stable, so treat the declaration as something to revisit. Questions and feedback are welcome here or in #C0BJEV93WMA