Explore the use of `force` in resolver
jvican opened this issue · 6 comments
From the ivy docs:
Any standard resolver can be used in force mode, which is used mainly to handle local development builds. In force mode, the resolver attempts to find a dependency whatever the requested revision is (internally it replace the requested revision by 'latest.integration'), and if it finds one, it forces this revision to be returned, even when used in a chain with returnFirst=false.
By using such a resolver at the beginning of a chain, you can be sure that Ivy will pick up whatever module is available in this resolver (usually a private local build) instead of the real requested revision. This allows to handle use case like a developer working on modules A and C, where A -> B -> C, and pick up the local build for C without having to publish a local version of B.
since 2.0
It looks like this could be beneficial for some scenarios. I'm not sure what the status quo is.
force is Ivy's emulation of Maven semantics. pom.xml is already translated with force, which makes it difficult knob to tweak for the end user since it doesn't have enough power. So my general recommendation is using dependency overrides instead.
I see what you mean. That sounds good.
sbt/ivy interpreting transitive maven dependencies as force=true is giving us some grief because it seems to make LatestConflictManager return whatever arbitrary version it first encounters instead of actually figuring out the latest/compatible versions etc.
Would it make sense to allow sbt users to configure sbt/ivy to not treat transitive maven dependencies as force=true?
@danielnorberg I am open to the idea. If I remember correctly Coursier uses latest-wins semantics so trying that might be a workaround.
I built a version of sbt/ivy locally with the checking of isForce() commented out and it correctly resolves version conflicts and selects the latest revision.
I am closing this due to inactivity, but if this is still relevant let us know.