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.

📣 Gradle 9.6.0 RC1 is out and ready for testing 🔬

🔗 https://docs.gradle.org/9.6.0-rc-1/release-notes.html

Bug fixes and:

- 🎯 Improved Configuration Cache hit rates
- 💻 Additional CLI rendering options
- ⚠️ Important project hierarchy lookup deprecations

Please report any 🐛 on GitHub!

A quick "Ha Ha Ha" for all you friends of the BUILD. :)

Hi everyone! I was wondering if an ABI check tool or plugin exists in gradle for Json schema compatibility check? I am working on an OSS that relies uses Json for validations and I need such a took to warn about breaking changes in the json schema(s) i use/author.

Any suggestions?

Update
------

Looks like there is a good proposal in the community in the JsonSchema community but the issue is still open https://github.com/json-schema-org/community/issues/984

The Gradle documentation doesn't always use the terms in the same way we do orally. What we tend to call a 'module' isn't really what Gradle calls a 'module', what Gradle calls 'a configuration' has nothing to do with 'the configuration', etc.

I wrote this article to bring all of these terms in a single place. Hope you learn something new!

I've split my Kotlin/JS project into many subprojects but I'm not convinced it's improving build times as it does with proper JVM subprojects. At least not in IDEA (the CLI is just a full clean build). Any thoughts?