This message was deleted.

this is an IDE error?

'val Project.libs: LibrariesForLibs' can't be called in this context by implicit receiver. Use the explicit one if necessary

as a side note: I find it baffling every time I go into the gradle documentation that stuff like this is not documented. The official page talking about version catalog and TOML say nothing about this: https://docs.gradle.org/current/userguide/platforms.html

that it is a known issue, just run

./gradlew assembleDebug

for example and check if everything is working

Do you have a link to the bug tracker? I can't consider this OK tho', is there any workaround?

you can just suppress the error with @Suppress annotation

Is there a bug I can track / add a comment for the suppress annotation?

https://youtrack.jetbrains.com/issue/KTIJ-19370 this is 100% an IDE issue, not a Gradle issue. I just ignore the IDE diagnostics, no need to suppress them since everything works regardless.

@ephemient this bug looks similar but it's not. It works fine for me in the

dependencies

section, the issue is in the

plugins

one. and I'm not OK ignoring IDE error, I'd like to either Suppress it or wait for the bugfix

https://youtrack.jetbrains.com/issue/KTIJ-19369 is the plugin-specific issue but either way, why do you need to care if the IDE warns about it? the project still imports into and builds in the IDE without any problems, and Gradle builds are not affected

I prefer to use

@Suppress("DSL_SCOPE_VIOLATION")
plugins {
  // ...
}

Thanks everyone. I care because when there's an error people look at it. An error has to be fixed, and if it is a false positive the correct fix is a suppression with comment explaining why it has been suppressed

it does, https://docs.gradle.org/current/userguide/platforms.html example 10

gradle is would be great if the documentation was better

I find Gradle is well documented, especially relative to other build systems of similar complexity. the problem is often finding the right documentation. I know some people have been writing targeted blog posts matching keywords that people are searching for, to help steer Google traffic to the right place. however in this case, a search for "gradle version catalog plugin" already leads to that as the top result

gradle is would be great if the documentation was better

I can fullheartedly disagree here. Gradle has amazingly good documentation. Especially compared to many other tools. Imho the documentation of course has potential for improvement as anything, but all-in-all I quite like it. If you have specific improvements in mind, open issues or prs about it so the Gradle guys can consider it.

the thing is, I believe, it misses some getting started that actually get you the tools to know what you are doing and know where to find what you need. I've to read A LOT of documentation to know what to do. Maybe you are right, the documentation is good. But it is overwhelming and requires a deep dive to actually know what to do. Most developers just want to build their app, they don't want / have time to dig deep into how gradle works. I know I'm not alone thinking this. And don't get me wrong here, when I do learn how to do stuff I think gradle is great. I just wish it was a bit more beginner friendly. I've been using gradle for years now and I still don't know how to achieve a lot of stuff. Kotlin DSL helped me with the discovery (autocompletion) in the last year I've to say. I'll think about it if I can come up with some specific pointers on what I think could be different / improved

There is a getting started page and there are also example projects and tutorials, there is not only the user guide in case you missed it. 🙂

I went through those long time ago, when android switched to Gradle. And they weren't that helpful back then. I'll check them again.