Technical blog

When to (not) use mavenLocal() in your Gradle build script

When to (not) use mavenLocal() in your Gradle build script

Technical Blog
Image
Author
Bruno Berstel
Reading Time
5 minutes

Contents

Gradle as build tool

If you’re like me and you work in a company that uses Gradle as its build tool, you may have wondered, while writing the build scripts for your project, what exactly should go into that repositories block. And in particular whether or not to include mavenLocal(), and if so where: as the first element? the last one? The short answer is that you don’t want to include it.

Repositories

As you most probably know if you’re reading this, Gradle can leverage the Maven system of components (such as Java libraries) and repositories (such as Sonatype's Nexus). Using those, you just need to declare a dependency like the following in the build script of your Java application: 
dependencies {
  implementation "com.fasterxml.jackson.core:jackson-core:2.9.9"
  // ...
}
and Gradle will take care of retrieving version 2.9.9 of the core library of Jackson provided by FasterXML, and include it in the appropriate class paths when compiling or running your application.

This, provided Gradle knows where to look for this library. And that is precisely the point of the repositories block, that could typically read as follows:
repositories {
  maven {
    url "http://nexus.mycompany.loc/repository/internal"
    mavenCentral()
  }
}
In the repositories block above, you state that when looking for a dependency, Gradle should first query the internal Nexus repository of your company, then the central Maven repository at https://repo1.maven.org/maven2/ .
The central repository is where Gradle will find all publicly available libraries, such as Jackson. Your company may also use an internal repository to store the software components shared between projects, or between modules of a project.

Imagine that your application, in addition to Jackson, uses code from a shared library of DTOs for your project. Its dependencies could then read:
dependencies {
  implementation "com.mycompany.myproject:common-dtos:1.0.0-SNAPSHOT"
  implementation "com.fasterxml.jackson.core:jackson-core:2.9.9"
  // ...
}
When compiling your application code, Gradle will look for the common-dtos and jackson-core libraries, first in its dependency cache in your home directory, then in your company’s internal repository, then in the central Maven repository.

Now, what about mavenLocal?

Up to here, everything works as expected. Yet, you may come across some Gradle build scripts with a repositories block that would read as follows: 
repositories {
  maven {
    mavenLocal()
    url "http://nexus.mycompany.loc/repository/internal"
    mavenCentral()
  }
}
At first, this looks sensible: don’t query the internal or central repository if the dependency is already present in the local repository. Whatever “the local repository” may actually mean…

It turns out that the mavenLocal() repository is not the Gradle dependency cache. It is a repository where you can deploy components with ./gradlew publishToMavenLocal (assuming you use the maven-publish Gradle plugin ). Now, why would you like to deploy to a local repository? My take is, you don’t.

The typical case where I would consider using a local repository is to test a change in a shared library without publishing it to a repository visible to other people than me, so that I’m sure of what I publish, when I publish it. However, there are better ways to achieve that.

First case: the shared library that I want to test is in the same Gradle build as the code that uses it. (Let me remind that in Gradle parlance, a 'build' is the code base that is considered when running a command such as ./gradlew build. This is what Eclipse refers to as a workspace, or IntelliJ IDEA as a project.) In that case, where the common DTOs library is built from, say, a common-dtos subfolder of the project root, specifying the dependencies of the application as a project dependency ) is enough:
dependencies {
  implementation project(":common-dtos")
  implementation "com.fasterxml.jackson.core:jackson-core:2.9.9"
  // ...
}
Second case: the shared library is in a different Gradle build, typically its source code is in a different Git repository (let us name it common-components). Then I will use the composite build feature to instruct Gradle to use the version of the common components that I cloned, rather than the one from the repository, when building my application. To this end, assuming that I have cloned the two Git repositories next to each other on my disk (if not, it’s just a matter of setting up the right relative path), I simply have to add the following line in the settings.gradle file at the root of of my application:
includeBuild "../common-components"


Conclusion

Although you may come across some Gradle build scripts that include mavenLocal() in the list of repositories where to look dependencies from, I cannot think of a good reason to do so. There are use cases where mavenLocal() could look like a solution, and maybe it was at a time when project dependencies and composite builds were not available in Gradle. But now they are. Even worse: the official Gradle documentation warns about different issues that could arise when using mavenLocal().

Originally published March 27, 2020, modified July 25, 2022

Keep up to date with our Medium blog .

Share this Post

Image
About the Author
Bruno Berstel-Da Silva, Ph.D joined DecisionBrain in 2016. He has been serving as Tech Lead on one of DecisionBrain’s largest projects, then as Senior Architect of the company’s technology platform. He has 20+ years of experience in design and development of knowledge-based systems, graphical user interfaces, business rule programming languages, and software engineering. Bruno received a Ph.D. in program formal verification from the University of Freiburg (Germany) in 2012.

Related Resources

New Release DB Gene 4.0.2 fp2

21/11/2022

The new version of DB Gene is available starting today! Learn all about DB Gene 4.0.2 fp2 in our video, our press release notes and documentation documents....

Read More

IBM DOC 3.x Migration to IBM DOC 4.x

12/07/2022

Why you should do a migration to IBM DOC 4.x? The maintenance of a DOC (Decision Optimization Center) 3.x application has become complex mostly because the technology/products...

Read More

CPLEX Datasheet

10/03/2022

Téléchargez la fiche technique d'IBM CPLEX. Un solveur d'optimisation haute performance pour la programmation linéaire, en nombres entiers mixtes et quadratiques. Simplifiez...

Read More
DOC Optimization server

Fiche technique DB Gene

24/11/2021

Téléchargez la fiche technique DB Gene de DecisionBrain. Apprenez-en plus sur les fonctionnalités importantes incluses dans DB Gene 4.0. Ceci inclut les composants, les...

Read More
DOC Optimization server

Fiche Technique Dynamic Scheduler

26/10/2021

Téléchargez la fiche technique du Dynamic Scheduler de DecisionBrain. En savoir plus sur les fonctionnalités clés de Dynamic Scheduler. Il s'agit d'une solution de main-d'œuvre......

Read More

IA Hub France

06/10/2021

DecisionBrain rejoint l'association Hub France IA. Créé en 2017 par des membres indépendants de l’écosystème de l’Intelligence Artificielle en France, le Hub a pour ambition...

Read More

Revendeur Partenaire d’IBM Cplex

24/05/2021

DecisionBrain est fier d'annoncer avoir signé un accord de licence et de distribution de technologie avec IBM pour être revendeur partenaire d' IBM Cplex Optimization Studio....

Read More

AfIA

06/05/2021

DecisionBrain adhère aujourd'hui à l'association AfIA, l’Association française pour l'Intelligence Artificielle. Le but de cette association est de promouvoir et de favoriser...

Read More
world image

Partenariat ATI

06/05/2021

DecisionBrain est fier d'annoncer avoir signé un accord de collaboration avec l'entreprise japonaise Advances Technology Institute, Inc (ATI). ATI est une entreprise qui...

Read More
ROADEF event

ROADEF 2021

03/05/2021

DecisionBrain est fier d'annoncer que pour la 5e année consécutive, nous serons l'un des sponsors de la 22e édition de ROADEF Mulhouse 2021. Cette édition est organisée par le...

Read More
Website Template DOC

Fiche technique DOC OS

27/11/2020

Téléchargez la fiche technique DOC OS . Decision Optimization Center Optimization Server is powered by DecisionBrain and utilized by IBM as a crucial part of the overall DOC...

Read More
DOC Optimization server

Fiche technique DOC

27/11/2020

Téléchargez la fiche technique DOC sur DecisionBrain. En savoir plus sur les caractéristiques importantes incluses dans DOC 4.0. cela comprenait les composants, les clients et...

Read More
DOC Optimization server

Livre blanc des FSM

25/09/2020

Téléchargez le livre blanc sur le management des services de terrain par DecisionBrain. Améliorez votre connaissance du secteur grâce à des tactiques clés pour le choix de...

Read More
ROADEF event

ROADEF Awards

23/09/2020

ROADEF a récompensé DecisionBrain à deux reprises avec "Les pros de la RO" pour le meilleur projet de RO de l'année : En 2018 pour notre solution de partage de vélos En 2015...

Read More
Company Brochure

Brochure DecisionBrain PDF

18/09/2020

Téléchargez la brochure PDF de DecisionBrain. Nous combinons l'optimisation et l'intelligence artificielle pour créer des solutions innovantes qui favorisent l'efficacité...

Read More

Speak with an Expert

Book a personal demo or speak with one of our product managers to learn more.
GET STARTED

Solutions

Industries

Technology

Company

ImageImage
Legal | Terms of Use | Privacy Policy
Copyright © 2022 DecisionBrain S.A.S., All Rights Reserved
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.