Probably a minor thing, but the Kotlin logo is outdated here: https://docs.gradle.org/current/userguide/userguide.html

8.6 release notes refer to the

Property.update()

API, which doesn't exist, because it was removed

here https://docs.gradle.org/current/userguide/plugins.html#sec:binary_plugin_locations

maven

should be inside

repositories

settings.gradle

pluginManagement {
    repositories {
        gradlePluginPortal()
        maven {
            url '<https://maven.example.com/plugins>'
        }
    }
}

also here there is a mismatch between the

App

package

authoring.tutorial

and the

mainClass = <http://org.example.App|org.example.App>

A change in

buildSrc

causes the whole project to become out-of-date.

Thus, when making small incremental changes, the

--no-rebuild

command-line option is often helpful to get faster feedback. Remember to run a full build regularly.

(ref)

`--no-rebuild`: Do not rebuild project dependencies. Useful for debugging and fine-tuning

buildSrc

, but can lead to wrong results. Use with caution!

(ref) I just tried this flag and my build immediately failed because it didn't rebuild the conventions plugin included build, which is basically what I expected that flag to do based on the "Do not rebuild project dependencies" description. The other parts of the docs around this don't make sense to me though, how is this useful for iterating on conventions plugins if using this flag prevents them from being rebuilt?

(Disclaimer: I'm new to Gradle community slack. If I'm posting in the wrong place/manner, please do let me know.) tl;dr; Please categorize the "fixed issues" listing in release notes. In the Gradle release notes "fixed issues" section, there are often quite a lot of things listed, and they are of varying relevance/usefulness to anyone trying to understand what's really been fixed. Typically I'm looking for functional bug fixes and performance improvements, and all of the "fix doc info" and "fix punctuation" issues are just a distraction in this case. It would be nice if the issues in this table could be organized into categories (as with the analogous information that IDEA's release notes provide). Notice the signal-to-noise ratio of the 8.8 release notes, for example: https://docs.gradle.org/8.8/release-notes.html?_gl=1*1ry7vuj*_ga*OTQyODQzNjkzLjE2OTI[…].*_ga_7W7NC6YNPT*MTcxNzQzNzIwMi42OC4wLjE3MTc0MzcyMDIuNjAuMC4w Example of how IDEA's categorization is really much easier to read: https://youtrack.jetbrains.com/articles/IDEA-A-2100661977/IntelliJ-IDEA-2024.1.2-241.17011.79-build-Release-Notes?_ga=2.24205050.1597409904.1717432795-943381524.1691692911&_gac=1.92545775.1714148239.CjwKCAjwoa2xBhACEiwA1sb1BEmZLlsLnTGeMWjU1WfhB7MX9x-x4D9eOGEZSoGI_uHluuIt9Df_0xoCwzYQAvD_BwE&_gl=1*4s3c0i*_gcl_aw*R0NMLjE3MTQxNDgyMzIuQ2p3S0NBandvYTJ4QmhBQ0Vpd0Exc2IxQkVtWkxsc0xuVEdlTVdqVTFXZmhCN01YOXgteDREOWVPR0VaU29HSV91SGx1dUl0OURmXzB4b0N3ellRQXZEX0J3RQ..*_gcl_au*ODg1NTc1OTEuMTcxNjkyNDg2MQ..*_ga*OTQzMzgxNTI0LjE2OTE2OTI5MTE.*_ga_9J976DJZ68*MTcxNzQzODQ5Mi4xMzMuMC4xNzE3NDM4NDkyLjYwLjAuMA.. Is this something for which I should file a documentation issue in GitHub?

Launching lib\main.dart on sdk gphone64 x86 64 in debug mode... Running Gradle task 'assembleDebug'... FAILURE: Build failed with an exception. * Where: Build file 'C:\Flutter\studio project\minor_project\android\build.gradle' line: 9 * What went wrong: A problem occurred evaluating root project 'android'.

Could not find method claspath() for arguments [com.google.gms.google-services:4.4.2] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

* 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 BUILD FAILED in 59s Error: Gradle task assembleDebug failed with exit code 1

I was thinking about adding a dedicated page for gradle with buildkite to the cookbook. just double checking that someone else hasn't started on something like that yet?

https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:developing_tasks Groovy code snippet: Is

tasks.named(Copy, "myCopy") {

2️⃣ Should be

tasks.named("myCopy", Copy) {

2️⃣

Incremental Release for the Gradle Community site. It is getting more solid https://github.com/gradle/community/releases/tag/v1.1.0

I think the code sample and the explanation aren’t in sync: https://docs.gradle.org/current/userguide/implementing_gradle_plugins_precompiled.html#sec:plugin_conventions

For those who wants to work on Documentation during Hacktoberfest, the main Gradle Documentation, Gradle Community Site, Gradle Cookbook, and many other bits are open for contributions! Cya on #C07HHBL4PMM See https://community.gradle.org/contributing/documentation/ and https://community.gradle.org/events/hacktoberfest/2024/

I was looking at the docs for the Java plugin, and saw it still references the

uploadArchives

task 😱 (in

Figure 1

). Does that task still exist?

Gradle Cookbook is now a separate entity/repository: https://cookbook.gradle.org/ . We split it to enable more sophisticated template with more content. Patches are welcome 🙂

Tomorrow we are doing a stream and Q&A on contributing to Gradle Documentation. It is in the Americas West Coast and APAC timezones, but the recording will be available. If there is interest, we can do more sessions in other timezones. And see you in #C07HHBL4PMM!

Contributing to Gradle Docs, fixed version:

message has been deleted

Hello everyone I'm Anurag (Anu for short) I'm working on fixing documentation links issue #17 on gradle cookbook repo and there are a lot of these redundant linkedin link check with status code 999 (see photo) I think these are because html-proofer is bombarding linkedin with requests can we do some quick fix about it, or just ignore it?

Hello this page has a link at the top But that link leads to nowhere https://docs.gradle.org/current/samples/gradle_ides.html#gradle_ides

image.png

Thanks for your patches for the community site automation @StefMa! There's a bunch of improve to get it to the state of art documentation engine, but happy that we're moving towards that, one step at a time.

I have a question: What can be done if something in the documentation explains some basics for beginners fairly well, but is technically wrong/bad practice for advanced users/when using the configuration cache? Currently thinking of 2 examples: https://docs.gradle.org/current/userguide/writing_build_scripts.html#sec:local_variables -> this is not technically a local variable but an implicit property and these constructs break the configuration cache The other example is here: https://docs.gradle.org/current/userguide/writing_settings_files.html#settings_file_scripting Iterating over the list of directories in such a way will cause unnecessary configuration cache misses as clearing .gradle or build will invalidate the build cache and this needs to be done using a ValueSource These examples are both really great for beginners but really ugly when considering the configuration cache

Actually i am facing the issue with gradle in my androidstudio as below while uploading to playstore Update your com.google.android.playcore1.7.2 Maven dependency to an Android 14 compatible version! Your current com.google.android.playcore1.7.2 library is incompatible with targetSdkVersion 34 (Android 14), which introduces a backwards-incompatible change to broadcast receivers. As a reminder, from August 31, 2024, Google Play requires all new app releases to target Android 14. Update to the latest library version dependency to avoid app crashes. Previous release

The table that in the Gradle user guide doc is obscured, I can’t view the complete content of the table.

Launching lib\main.dart on sdk gphone64 x86 64 in debug mode... Running Gradle task 'assembleDebug'... Warning: SDK processing. This version only understands SDK XML versions up to 3 but an SDK XML file of version 4 was encountered. This can happen if you use versions of Android Studio and the command-line tools that were released at different times. [Fatal Error] flutter_embedding_debug-1.0.0-a18df97ca57a249df5d8d68cd0820600223ce262.pom290: The markup in the document following the root element must be well-formed. [Fatal Error] flutter_embedding_debug-1.0.0-a18df97ca57a249df5d8d68cd0820600223ce262.pom290: The markup in the document following the root element must be well-formed. [Fatal Error] flutter_embedding_debug-1.0.0-a18df97ca57a249df5d8d68cd0820600223ce262.pom290: The markup in the document following the root element must be well-formed. [Fatal Error] flutter_embedding_debug-1.0.0-a18df97ca57a249df5d8d68cd0820600223ce262.pom290: The markup in the document following the root element must be well-formed. [Fatal Error] flutter_embedding_debug-1.0.0-a18df97ca57a249df5d8d68cd0820600223ce262.pom290: The markup in the document following the root element must be well-formed. [Fatal Error] flutter_embedding_debug-1.0.0-a18df97ca57a249df5d8d68cd0820600223ce262.pom290: The markup in the document following the root element must be well-formed. [Fatal Error] flutter_embedding_debug-1.0.0-a18df97ca57a249df5d8d68cd0820600223ce262.pom290: The markup in the document following the root element must be well-formed. [Fatal Error] flutter_embedding_debug-1.0.0-a18df97ca57a249df5d8d68cd0820600223ce262.pom290: The markup in the document following the root element must be well-formed. [Fatal Error] flutter_embedding_debug-1.0.0-a18df97ca57a249df5d8d68cd0820600223ce262.pom290: The markup in the document following the root element must be well-formed. [Fatal Error] flutter_embedding_debug-1.0.0-a18df97ca57a249df5d8d68cd0820600223ce262.pom290: The markup in the document following the root element must be well-formed. [Fatal Error] flutter_embedding_debug-1.0.0-a18df97ca57a249df5d8d68cd0820600223ce262.pom290: The markup in the document following the root element must be well-formed. FAILURE: Build failed with an exception. * What went wrong: Execution failed for task 'path provider androidcompileDebugJavaWithJavac'.

Could not resolve all files for configuration 'path provider androidandroidJdkImage'.

> Failed to transform core-for-system-modules.jar to match attributes {artifactType=_internal_android_jdk_image, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}. > Execution failed for JdkImageTransform: C:\Users\jeets\AppData\Local\Android\sdk\platforms\android-34\core-for-system-modules.jar. > Error while executing process C:\Program Files\Android\Android Studio\jbr\bin\jlink.exe with arguments {--module-path C:\Users\jeets\.gradle\caches\transforms-3\4a46fc89ed5f9adfe3afebf74eb8bfeb\transformed\output\temp\jmod --add-modules java.base --output C:\Users\jeets\.gradle\caches\transforms-3\4a46fc89ed5f9adfe3afebf74eb8bfeb\transformed\output\jdkImage --disable-plugin system-modules} * 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.

BUILD FAILED in 2m 8s Error: Gradle task assembleDebug failed with exit code 1

qq: CONTRIBUTING.md says Java 11 is required for cache hits, but isn't Java 17 the minimum version now? https://github.com/gradle/gradle/blob/5670f2e30375f94a477e21a5358c86c11aa69e3c/CONTRIBUTING.md?plain=1#L269

Hey everyone! I am new to Gradle, so I started reading the reference docs and found this part sort of confusing: In Understanding the Daemon, Shouldn't "The Wrapper" be "The Daemon"? It seems like the paragraph as a whole would make more sense if in the second sentence the Daemon is related back to the client: "The Gradle JVM client sends the Daemon build information such as command line arguments, project directories, and environment variables so that it can run the build. The Wrapper is responsible for resolving dependencies, executing build scripts, creating and running tasks; when it is done, it sends the client the output." This definition of the Wrapper conflicts with earlier notion from the Gradle Wrapper Reference (https://docs.gradle.org/current/userguide/gradle_wrapper.html), "*The Wrapper is a script that invokes a declared version of Gradle, downloading it beforehand if necessary.*"

Has the section about why Maven Local is best avoided been relocated or removed from the docs? I couldn't find it. https://docs.gradle.org/8.9/userguide/declaring_repositories.html#sec:case-for-maven-local

when looking up userguide documentation I nowadays get this as a first suggestion in google. But this is not the actual userguide, just a polished javadoc. IMO the link description is really misleading (and annoying)