I was trying out the preferProjectModules resolution strategy. It sounds like it would fit our multi-project build environment very well, as we do publish artifacts from these projects but it’s definitely preferable to use the local source, even if the published artifact has a higher version.
But I kept running in to cases where a project would get the published jar instead of resolving to its sibling project.
The much-touted build scan didn’t have the explanations I was looking for and in frustration I built my own DependencyResolutionListener to try to track things down.
In the end I hit the limits of what the public interfaces of the data structures were willing to show me. (The screenshot here is of sections where it was using the subproject. I confess I have added it here more for visual flair for the post than its use in answering the question.)
I think my conclusion is that in the places where I was seeing the jar used instead of the sibling project, the resolver was never kicking in because it never perceived any conflict to resolve? Even though other parts of the multi-project did have dependencies to that sibling project.
This seems like it’s the source of a lot of my frustration in dependency debugging. Gradle has developed the tools to explain why it’s chosen to resolve things the way it did in case of conflicts, but it seems as if the values I am expecting were never even considered as valid candidates in the first place, and it leaves me struggling to understand where the miscommunication is.
Any advice for better visibility in to where the resolver is looking for candidates and which things it filtered out?