How no to duplicate dependencies in multiprojectbuild

I am new to gradle and Following the tutorial https://docs.gradle.org/current/userguide/multi_project_builds.html#sec:project_jar_dependencies

This layout perfectly fit my need but now. I am adding dependencies to my project i am wondering what’is the best way to do it because i am duplicating some lines….

Let’s take the same tutorial project

java/
  settings.gradle
  build.gradle
  api/
    src/main/java/
      org/gradle/sample/
        api/
          Person.java
        apiImpl/
          PersonImpl.java
  services/personService/
    src/
      main/java/
        org/gradle/sample/services/
          PersonService.java
      test/java/
        org/gradle/sample/services/
          PersonServiceTest.java
  shared/
    src/main/java/
      org/gradle/sample/shared/
        Helper.java

Now I have some dependencies in common (for example the lib “apache-commons”) used by shared and services but not by api.

How could I handle such dependencies I can add it to the root project but I prefer to have project that doesn’t depend on useless librarie.

Remarks : there is more than apache-commons, and some other Library can be common to api and service but not shared

Hi,
we are using an extra gradle file (lets call it libraries.gradle), which contains a map as project extra property

project.ext.lib = [
     commonsLang :  'org.apache.commons:commons-lang3:3.7',
     [many more libs]
]

We apply libraries.gradle in the root project (in our case mutiple root projects) and refer libraries by using the map

compile lib.commonsLang

At least this help to have a central place for all libs and not repeating groups, modules and versions.

1 Like

That is the solution I also found by googling around.

I think I will also use this technique.

But now I am wondering if it’s a good idea finally to have project configuration outside the scope of the project ??
My subproject won’t compile alone if i take it outside.

I am still divided between centralize or duplicate…

We have three relativly large projects (each producing multiple JARs) which are finally integrated within one web application (WAR/EAR). Therefore, we have to ensure that the versions of the used libraries do not go wild in the different projects. Using this centralized gradle file with a map for all used libraries makes life easier.

But you are right, sometimes it is not the best way to remove duplication at all cost.