This message was deleted.
# dependency-management
s
This message was deleted.
t
I suppose it looks at
metadata/versioning/release
in the
maven-metadata.xml
for the groupId/artifactId, so if it doesn't do what you expect, I'd first check the content of that file.
m
That specifies the correct version, but seems to be ignored. For reference, here's the artifact I'm trying to get: <https://maven.martmists.com/#/releases/io/github/gunpowder/gunpowder> And I've got a dependency resolution rule to reject versions with an incorrect version after the +, leaving gradle to find the most recent version before the +
v
Please show your rule and dependency declaration
m
This code comes from a gradle plugin, hence why I'm using
add
in dependencies:
Copy code
configurations.all {
            resolutionStrategy {
                componentSelection {
                    all {
                        if (candidate.group == "io.github.gunpowder" && candidate.module == "gunpowder") {
                            val parts = candidate.version.split("+")
                            if (parts.last() != ext.minecraftVersion) {
                                reject("Version should match minecraft version ${ext.minecraftVersion}, got ${candidate.version}")
                            }
                        }
                    }
                }
            }
        }
Copy code
dependencies {
    add("modApi", "io.github.gunpowder:gunpowder:latest.release")
}
If I add a
println(candidate.version)
line before the version.split, it always says
2.0.0+1.18.2
I think the issue comes from gradle attempting the entries in
metadata > versioning > versions
in order, assuming the first entry is the most recent one, but I don't have enough knowledge of gradle to know whether this is true or not
v
It is not, the docs explain how the versions are compared and ordered
m
I think I've more or less figured it out;
latest.release
or
maven-metadata.xml
seems to be cached, so even when a new version is published it doesn't seem to pull it in unless I wipe ~/.gradle/caches
v
Yes, for 24 hours by default iirc That is configurable though
And you can use
--refresh-dependencies
to force a refresh
m
Is there a property for gradle.properties to permanently disable that behavior per-project?
v
Only if you define one, you can disable it by code as documented
Btw. I'd prefer
withModule
in
componentSelection
instead of
all
and then checking the coordinates manually.
m
Where exactly are all these things documented? You've mentioned that a couple of times but I've been unable to find this information on the gradle docs
v
m
As this happens in build.gradle.kts, I'm assuming it only applies to dependencies. What if I also wanted to disable the version cache for plugins?
v
Same I think, you just have to call it on the right configurations, for example in the
buildscript
block.
But you should really think twice before doing such things, it will allow down your builds as any dynamic versions needs to be rechecked online on each build.
Besides that I'm not a fan of dynamic versions anyway. :-D
👍 1