Resolving Dependencies From Local Maven Repository

Gradle is able to resolve artifacts stored in the local Maven repository (usually ~/.m2/repository) via mavenLocal().

According to the documentation, mavenLocal() is resolved like this:

Gradle uses the same logic as Maven to identify the location of your local Maven cache. If a local repository location is defined in a settings.xml, this location will be used. The settings.xml in USER_HOME/.m2 takes precedence over the settings.xml in M2_HOME/conf. If no settings.xmlis available, Gradle uses the default location USER_HOME/.m2/repository.

To resolve artifacts from a non-standard local Maven repository, you can use the following configuration in your build.gradle:

repositories {
    maven {
        url '/Users/manuelj/apache/maven/repository'
    }
}

(From: How does Gradle resolve the directory of the local maven repository?)

Custom Maven repositories are documented here.

Storing Artifacts in the Local Maven Repository

Gradle stores resolved dependencies in its own Dependency Cache. The dependency cache is so much more than just a simple Maven artifact repository:

• Stores binaries (jars), artifact meta-data (POM, Ivy files), dependency resolution results and module descriptors.
• Tuned for performance, for example shorter file paths.
• De-duplicates artifacts: Same binaries are stored only once.
• Tracks where a dependency came from. A dependency resolved from jcenter() might be different to the one resolved from mavenCentral().
• Automatic, time and usage bases, cache cleanup.

Artifacts produced by the build can be easily pushed to the local Maven repository via publishToMavenLocal task contributed by the Maven Publish Plugin.

But what about resolved dependencies? For the aforementioned reasons, Gradle cannot store dependencies in the local Maven repository. There’s currently no built-in functionality to even publish dependencies to the Maven’s local repository from the build script. So what are your options:

• Create a shell script that does the necessary legwork. Daniel Dietrich once wrote one and published it on Twitter (Gist).
• Use an artifact proxy like Nexus or Artifactory. Maven and Gradle can be configured to consume dependencies from the same proxy. This setup is quite common in professional environments and my personal preference.