Cache Dependencies into Local Maven Repository from Gradle

Old Forum
1

How to download and cache artifacts into local Maven Repository from Gradle

2 Likes
2

I’m not sure if this answers your answer. First of all, I’m new to Gradle.

First of all, Gradle has its own cache where it stores the downloaded artifacts. It resides in $HOME/.gradle, at least in Unix environments.

However, you can read the local Maven repository by putting this in your build.gradle:

repositories {
     mavenLocal()
...
}

You can publish artifacts into the local Maven repository by putting into your build.gradle:

apply plugin: 'maven'

Then you can write “gradle install” and it will install your artifact into your local Maven repository.

However, if you download artifacts from a remote Maven repo, Gradle will put the artifacts into its own cache, not in the local Maven repository.

3

I want the dependencies to be stored in the local Mavan Repo than the Gradle local repo

4

Gradle will always store downloaded artifacts in its own cache. You can additionally use artifacts stored in the local Maven repository by declaring a ‘mavenLocal()’ repository. You can install into the local Maven repository by applying the ‘maven’ plugin and running the ‘install’ task.

5

Are the cached Jars moved to the local maven repo when installed or just the build artifacts?

6

Only the build artifacts (i.e. what your gradle project built)

7

indeed, this is something I am missing. Are there any plans to support the download to the local maven repository?

8

That’s not something that’s planned at this point, and not likely to be anytime soon.

9

I think this is indeed important! I have to take so long to redownload the artifacts which I have downloaded.

1 Like
10

It would be important if you have not only Gradle projects but also Maven projects which you cannot change or migrate. Then it would be an annoyance to have those duplicate jars.

On the other hand, if you a working in a team environment in the same network, a common repository like Artifactory can be configured as the primary repository for Gradle, and when Gradle asks Artifactory for some Jar which is not already it there it will be downloaded by Artifactory.

11

I have to take so long to redownload the artifacts which I have downloaded.

Gradle already checks the local Maven repository for artifacts. If it finds an artifact with matching coordinates and checksum, it will not download it again. (For best results, make sure to use a recent Gradle version.)

12

That’s great, but I still think gradle doesn’t need to recreate a repo structure. Anyway it already use maven’s dependency management functionality.

13

It’s very necessary to have our own repository for a few reasons. Moreover, to say that Gradle uses Maven’s dependency management functionality is incorrect.

14

Luke: so please explain why it’s incorrect saying " Gradle uses Maven’s dependency management functionality". We all know, Gradle also supports Ivy and supports Maven repositories - by using them as a resource to resolve dependents. So, maybe we should be more concise: Gradle has it’s own dependency management strategy, but it can make usage of Maven and / or Ivy repositories. Anyway: the discussion on this pages, for me, is the question why Gradle cannot WRITE downloaded dependent artifacts back to a local Maven repository, given that a project defines a local Maven repository as the first source to look up for dependent artifacts. Think of this: if a developer has a local repository, he might be using it primary for his ‘old’ Maven based projects, and then he might also have some ‘new’ Gradle based project(s). So, why not have all those artifacts use a common code store? (In the “old days” days I always hated that each Java project had it’s own library directory.)

15

It would be too invasive on our part to write to another software system’s store without explicit instruction and use of a contract, which is what we do for our Maven plugin’s install task.

Also, the physical layout of Maven’s repository would not support the characteristics and features of our cache.

In summary, there are several reasons why using maven’s cache would be a bad thing for Gradle and one good reason (disk space optimization) and one debatable (state sync between the two tools). It’s just not going to happen.

16

It would be great to be able to say gradle installDependencies and all dependencies from local cache get copied to local maven repo. This way if I delete the gradle cache or want to use the same dependencies in a different project I don’t have to pay the penalty for downloading the artifacts.

2 Likes
17

@corneil You can now write this operation yourself by using the Artifact Query API (>= Gradle 2.3) which gives you direct access to the resolved artifacts as well as the metadata files.