First question is if you need such a place. For example, if you have a single multi-project build rather than many small builds, you won’t need such a place, and won’t have versioning issues between the components of your application. This is a convenient model. Another solution is to have your CI server constantly building snapshots which are then used in dependent builds. Again, this model is more reliable than exchanging artifacts via a local repository.
If you do need a local repository, only use Maven local if it’s necessary to exchange artifacts with Maven builds. Otherwise it’s better to declare a Maven or Ivy repository with a ‘file://’ URL.
PS: The Gradle cache is a cache in the real sense of the word. It’s only reason of existence is performance optimization. It isn’t possible to install anything there, which is important to achieve reproducible builds.
I am trying to avoid maven altogether, though I may need to rethink that and its good to know there is an option with publishToMavenLocal.
Peter: Yes, most of what you say matches my understanding.
We do produce our flagship financial product with about 20 maven1 builds, each producing a locally build artifact (and uniquely tagged),
The maven 1 multiproject is used and so the reactor determines ordering - and all artifacts will be pushed to a remote repo.
So…what I’m hearing is that I should not base my strategy on what maven 1 formerly provided but think about what I need and how I can use gradle to provide it.