https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# dependency-management
s
This message was deleted.
🙏 1
e
the included build does not inherit the version catalog, it is its own build
you could explicitly load the parent's libs.versions.toml with
Copy code
dependencyResolutionManagement {
     versionCatalogs {
        create("libs") {
            from(files("../gradle/libs.versions.toml"))
        }
    }
}
but that won't pick anything added to the catalog via root settings.gradle, for example
t
Thanks. I completely forgot, that included build has own settings.gradle.kts, but I would anyway expecting that just adding
Copy code
enableFeaturePreview("VERSION_CATALOGS")
there would be enough. But no there must be code as you sent.
v
It is an independent build that is just run as sub-build. Why should it inherit the version catalog? It also does not inherit other things like 
gradle.properties
values and so on.
Btw. if you can upgrade to 7.4, then version catalogs are now a stable feature and do not need the feature preview anymore 🙂
t
Yes. It makes sense that it is independent build and has event own settings.xml. But what doesn't make sense to me why it not loading by default "../gradle/libs.versions.toml". It searching for some other location? It is not file that belong to any specific module, like gradle.properties. According path it is general location and I think that everything should use it. Purpose of version catalog is avoid dependency version duplication. So why to not use the same toml file?
e
it will use its own 
included/gradle/libs.versions.toml
if available
aside from dependency substitution and gradle version, an included build basically is a completely independent build
t
So probably also 
verification-metadata.xml
which can be in 
gradle
folder will be used for included build from this 
included/gradle/
folder, right?
v
Never used it, but I'd expect it to, yes
t
Ok. Thanks!
v
and sure, 
libs.versions.toml
IS specific to one module the same way 
gradle.properties
is
You can though publish the version catalog, or make it a separate build that you can then include from both, the main project and the included build
If for example the included build is really a stand-alone project that is just used as composite here too
t
You can have gradle.properties in root, then is shared by all project, or have it inside module, than it is used only by one module. But libs.versions.toml is definitely not specific to some module, since in is inside of gradle folder, it is common for all modules inside of project, included module is only exeception here.
e
included builds are not like subprojects, but rather more similar to binary dependencies that happen to be built from source on demand
t
If for example the included build is really a stand-alone project that is just used as composite here too
And yes, you have right that make sense that it looking to gradle folder inside of included build, since it can be completely different project. It make fully sense from this point of view.
v
or have it inside module, than it is used only by one module.
If by "module" you mean "build", then this is correct. If by "module" you mean a project within a multi-project build, then this is not correct. You can have at most one 
gradle.properties
and that must be in the root directory (not talking abou the user-specific local one in 
GRADLE_USER_HOME
here) All projects in the build (not in included builds) share that 
gradle.properties
file.
But libs.versions.toml is definitely not specific to some module, since in is inside of gradle folder, it is common for all modules inside of project, included module is only exeception here.
From this I guess you indeed mean "project" when you say "module". So assuming you remembered wrongly about having project-specific Gradle properties file, do you still think it is different between 
gradle.properties
and 
libs.versions.toml
? For me it is the same for both as both behave the same and have the same scope. Except that you can easily import the toml to another build if you like to.
13 Views
Open in Slack
PreviousNext
Powered by