4

When creating an Android project from scratch, Android Studio doesn't add mavenLocal() to the list of Gradle repositories. But we added it, and builds are now faster than ever.

Is there any reason to avoid adding mavenLocal() at every Android project we have? I mean, are there any cons in doing it?

Roc Boronat
  • 11,395
  • 5
  • 47
  • 59
  • "builds are now faster than ever" -- presumably, you installed some dependency in your local Maven repository that you had previously been pulling in from the network. That's unusual, and if you do not maintain that local Maven repo, you will fall back to the network as soon as you bump the dependency versions to one that you did not copy locally. – CommonsWare Jul 12 '17 at 11:52
  • @CommonsWare, Sure, but only the first time, as it will be added to cache and used from there next time – Sergi and Replace Jul 12 '17 at 12:06
  • @SergiandReplace: Agreed, but Gradle's cache is not `mavenLocal()`. That's why I am skeptical about the claims of build performance improvements. – CommonsWare Jul 12 '17 at 12:13
  • @CommonsWare it seems that Gradle does a `HEAD` to repos to check something. So, if the network is not excellent, it affects to the build time if `mavenLocal()` is not present. Actually, I don't know how it works internally... and what's why I try to figure what's happening there. – Roc Boronat Jul 12 '17 at 12:17
  • AFAIK, Gradle only does the `HEAD` check once per day per dependency. – CommonsWare Jul 12 '17 at 12:19
  • 2
    BTW. https://stackoverflow.com/questions/32107205/gradle-does-not-use-the-maven-local-repository-for-a-new-dependency – OneCricketeer Jul 12 '17 at 12:29

2 Answers2

1

What if you didn't have .m2 local repository?

mavenLocal() actually adds your .m2 to your Gradle repositories.

Gradle has its own ivy cache, and probably when you migrated the project or had a different project that used some common dependencies, its actually faster as all the dependencies been downloaded already before, therefore adding maven local repo to Gradle repositories makes the fresh project faster as it doesn't need to download them again to its local cache.

I would personally have it there as I have some maven and some Gradle projects, and yes it speeds up the build, and it doesn't use as much space to store duplicated dependencies for multiple projects. But I also think that if you are not using maven, you should let Gradle manage its dependencies.

LazerBanana
  • 6,865
  • 3
  • 28
  • 47
  • Don't know. The .m2 cache is magically created when using Gradle, isn't it? I don't remember installing maven in the computer I'm using right now. By the way, by your answer, you think that there is not any reason to remove that `mavenLocal()`? In that case, why Google doesn't add `mavenLocal()` by default? – Roc Boronat Jul 12 '17 at 12:30
  • @RocBoronat I did not say there is no reason removing it, I would personally have it there as I have some maven and some Gradle projects, and yes it speeds up the build, and I don't use as much space on my SDD to keep duplicated dependencies for multiple projects. But I also think that if you are not using maven, you should let Gradle manage its dependencies. – LazerBanana Aug 07 '17 at 09:00
  • Ok @LazerBanana, thanks for the clarification! :·) I will keep the `mavenLocal()` there. It seems that it doesn't do bad things. So... It sounds good :·) – Roc Boronat Aug 08 '17 at 09:28
0

I think @LazerBanana has pointed out the issue.

But besides that, I also want to mention the continuous integration practices everyone has nowadays for the builds. That is another thing we should not have mavenLocal(), because it makes builds depending on machines.

chenrui
  • 8,910
  • 3
  • 33
  • 43
  • But, if you are using not snapshot artifacts, that will just speed up the build, isn't it? – Roc Boronat Jul 14 '17 at 10:10
  • yeah, snapshot should be also published to Nexus (or the other jar distributor). I dont disagree adding mavenLocal() to speed up the build, I just think the build is not repeatable across machines. – chenrui Jul 14 '17 at 11:18
  • Oh, ok! Thanks for the clarification @chenrui! :·) – Roc Boronat Aug 08 '17 at 09:26