I’m trying to identify strategies to govern how Gradle handles locally published snapshots taking priority over centrally published snapshots.
Say I have project ‘A’ depending on project ‘B’, and both are published to my shared object repository.
I want to publish B.jar locally and have A pick up those local changes, ignoring the B.jar that gets resolved out of the shared repository.
I never used Maven much but I’m told this is fairly transparent in Maven. In Ivy, this behavior was possible, but hairy to implement… basically people usually chain the local and remote repository and then fiddle with Ivy’s 100 different knobs to make the local artifact take priority in whatever way is desired.
It was hairy and buggy and never totally satisfactory.
Am I talking about ‘project dependencies’ here?
What knobs are there to control this behavior, like say to prevent a stale local artifact from hanging around too long?
The order in which you declare repositories (or resolvers) in the repositories script block is meaningful.
The easiest way to resolve dependencies via the local repository is to apply ‘maven’ plugin to the upstream dependencies, use ‘install’ task to install them to the local repo, then use mavenLocal() repository definition in your downstream project.
Alternatively you configure the ivy resolver that will look for artifacts in some designated folder. Upstream projects will have to upload their products into that folder.
Hope that helps somehow 
Hi Szczepan, thanks for replying.
I may be misunderstanding but I still don’t see an answer to the question, which I probably did not form very well.
If project B has been installed, locally, then I want project A to use the local version.
If B is not built locally, then I want A to retrieve B from our repository where B is built nightly.
This eliminates the need for me to build B locally if I don’t need to change it locally.
Does that make sense?
Does it change your response?