From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

:question: 7.6 not yet visible on <https://gradle.org/releases/>

<@U02S31Y7J2K> it takes a little while for caches to be invalidated here, 7.6 should show up shortly

This is now fixed. Our publication failed due to a docker pull issue with <http://ghcr.io|ghcr.io> which had a transient problem.

Woot!!! Christmas Tree of deprecation warning caused by `GUtil` deprecation!

:point_up: I understand the idea of deprecating the `util` package, but that package offers a lot of useful utilities when writing quick build logic. It would be great to have a set of prototyping, MIT licensed, APIs that plugin and build authors can use to quickly test ideas. With a MIT license they can just copy the code in their own codebase (public or private) without issue. #ideas

do you have examples of what from `util` is used elsewhere?

Well GUtil to start. But it's more that the API are useful. VersionNumber was another great one.

large portions of GUtil are collection-related - for Java, that is better handled by other libraries (e.g. Guava), and built-in for Groovy and Kotlin.  Likely other misc utility functions exist in other libraries.

I'm aware of that and that's not my point. It's the ease of access to those APIs that GUtil and the whole util package was providing. I'm not arguing that it shouldn't be deprecated. I'm mentioning that it's an unfortunate lost on the convenience of writing Gradle code.

Perhaps.  Personally I prefer more widely-used utility libraries such as Guava rather than purpose-built internal classes such as GUtil (which is likely a factor in deprecating it, to limit the scope to just Gradle itself).

I'm voicing the fact that not a lot of users may have being aware that util package was internal. It will catch several users off guard. It's a good thing it will only be removed in Gradle 9.

fair point.  and - fair warning, should be lots of time to adjust, for those that are using `util`.

Looks like the official recommendation since this release is to use `build-logic` included build instead of `buildSrc`. Would be nice to see that reflected here as well <https://docs.gradle.org/7.6/userguide/organizing_gradle_projects.html#sec:build_sources>

We'll get there. The change in 7.6 in `init` to use `build-logic` is not the default, you need to opt-in using incubating features when generating builds.