Hi folks, what would be a good way to prefer a version of a SNAPSHOT artifact living in

mavenLocal()

over a RELEASE one living in a Maven Repository? I'd like it where if the artifact exists in mavenLocal, it's preferred and used. Otherwise if a RELEASE version is found, it can be used. I think this goes against Gradle's typical rules of preferring the highest version first (1.0-RELEASE > 1.0-SNAPSHOT). We have our architecture set up in such a way that doing composite builds isn't practical and we'd like to keep referring to mavenLocal, despite it's pitfalls. I've seen examples where you can prefer a local dependency on a

project(':myProject')

over a artifact coming from elsewhere, but I'm unsure how to take on this approach if the project I'd like to refer to doesn't live in the same code repository/Gradle project space.

for a non-specific fix, you could 1. put Maven Local before other repositories (because order matters) 2. tell Gradle to only use Maven Local for snapshots

repositories { 
  mavenLocal {
    mavenContent { snapshotsOnly() }
  }
  mavenCentral()
}

I think what I'm trying to do here is override Gradle's default behavior which doesn't seem feasible. Up to this point, we've been using an enforcedPlatform on our own platform to strictly set versions from the top down. We'd like to pave way for removal of the strict versions provided by the enforced platform as we know it conflicts with Gradle's Module Metadata, so we're replacing the enforcedPlatform with a platform and as a result Gradle's conflict resolution now prefers the higher of the versions. This is a problem in development, but I think the way around it is to ask the developer to provide their own custom platform version with an enforcedPlatform instead of a platform, that way their local changes will be enforced over Gradle's preference.

Maybe you want

preferProjectModules()

https://docs.gradle.org/current/kotlin-dsl/gradle/org.gradle.api.artifacts/-resolution-strategy/prefer-project-modules.html I was looking at a different problem, and just bumped into it.

I think that solution will work for sibling projects in a repository, but it won't work for other local projects that live outside of that repo. Regardless, I was originally iterating over every sibling project and making the project prefer the local manually rather than using this. This will be much cleaner than using that 🙂