Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version Catalogs documentation is outdated regards using values defined in Versions scope #20370

Closed
Alaksion opened this issue Apr 4, 2022 · 1 comment · Fixed by #20784
Closed
Assignees
Milestone

Comments

@Alaksion
Copy link

Alaksion commented Apr 4, 2022

The documentation defined here says we should use libs.versions.yourVersion.get() to retrieve values declared in version catalog's versions block, but in fact this method only works if you add .asProvider() before the get() function.

Incorrect example: libs.versions.compose.get()
Working example: libs.versions.compose.asProvider().get()

Expected Behavior

In a gradle file we should be able to retrieve version values using libs.versions.yourVersion.get()

Current Behavior

In a gradle file when using .get() function in a previously declared version of the version catalog an "unsolved reference" error is thrown, as we can see in the picture below:
image

Context

I was migrating my app from groovy + buildscript extensions to kotlin-dsl + version catalogs. To declare that a module can use Jetpack compose we must assign the compiler version to be used with compose (which is the same value of the current compose version), and then when i tried to use libs.versions.compose.get()the error occurred.

Steps to Reproduce

  1. Enable version catalogs in your project
  2. Create a version catalog TOML file
  3. Declare a value in the versions block
  4. Try to access the value using libs.versions.yourValue.get()
  5. Notice the unsolved reference error

Your Environment

  • MacOs Monterey
  • Gradle Version 7.4.2
  • Android Gradle Plugin 7.1.2
  • Android Studio Version Bumblebee 2021.1.1 Patch 2
@melix
Copy link
Contributor

melix commented Apr 5, 2022

This is actually almost true. If there's a nested accessor, you need to call asProvider() first. So here you need to call asProvider() because you have a child node to compose I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants