1

I have a gradle project like this:

root
  |
  |---- projectA
  |
  |---- projectB
 ...

My root build.gradle contains dependencies which are needed for projectA and projectB. I have defined them like this:

subprojects {
    repositories {
        jcenter()
        mavenCentral()
        mavenLocal()
    }
    dependencies {
        compile 'com.google.guava:guava:23.0'
        compile group: 'com.google.code.gson', name: 'gson', version: '2.8.2'

Now I am trying to add a dependency on projectA from projectB so my projectB build.gradle looks like this:

dependencies {
    implementation project(':projectA')
}

and projectB settings.gradle:

include ':projectA'
project(':projectA').projectDir = new File(settingsDir, '../projectA')

This is currently failing, as projectA and B do not depend on root to get their needed dependencies.

Can I add another dependency from projectA on root or what is the default gradle approach to share same dependencies from one root project?

JoJota
  • 35
  • 10

2 Answers2

1

Your modules (A and B) are not correctly setup as child modules of the root project. In your base folder, create if necessary the settings.gradle file, and add the child modules definition:

root/settings.gradle

include 'projectA', 'projectB'

The build.gradle file of projectB is ok as it is, then you need to remove the root/projectB/settings.gradle file; child-modules and their locations are specified in the parent build file.

Daniele
  • 2,672
  • 1
  • 14
  • 20
1

Specifying dependencies with the "compile" keyword is being deprecated. The new keyword to use is "implementation". (See this SO question for an example of explanation.) The difference between "compile" and "implementation" as it relates to your case, is that "compile" propagates the dependency to all connected modules, while "implementation" is single-level. So, if you have 

root
  module A
  module B

and module B has a depandency brought in with "compile", then root has access to that dependency. But if you now change B to bring the dependency in with "implementation", then you'll still need to add the dependency to the root project's build.gradle.

Why is this relevant? Because a child module isn't allowed to know who its parent is. So, while A and B both see the dependencies you brought into root, they really shouldn't -- seeing those dependencies is a quirk of how Studio works. This is also why the answer to "Can I add another dependency from projectA on root" is "no, you're out of luck there, it'd create a circular dependency and that's not allowed".

The dependencies I'd try are:

In both module A and module B:

dependencies {
  implementation 'com.google.guava:guava:23.0'
  implementation group: 'com.google.code.gson', name: 'gson', version: '2.8.2'

Then in Module B, you do:

implementation project(':projectA')

Then in root, you depend on both A and B.

gothamgreen
  • 25
  • 7
  • Thanks, that was very helpful. So that means when using another module as a dependency, I am not able to specify the same dependency libraries for module A and B inside the root's build.gradle? I really want to make sure I am using the same version of each library on all modules and I am trying to avoid maintaining all implementations separately for each module. – JoJota Jun 03 '18 at 09:31
  • Good question. I don't know. I know that, sometimes, when dependencies don't match, Studio will complain at you in a yellow warning and let you fix it. But I don't know if that's guaranteed. I'm a beginner with gradle, so there may be a way to factor dependencies out into a separate file, and keep including that file, but I don't know it. You can also use a service such as Nexus. You put your dependencies into Nexus, and pull them down with gradle. That way, if you have a version that's not matching what's up on the server, you'll have a visible fail. – gothamgreen Jun 08 '18 at 00:46
  • However, while the setup you're working on is exactly like one I've recently researched for my project, the details of doing it better are beyond my ken for right now. – gothamgreen Jun 08 '18 at 00:49
  • Okay, thanks for coming back on this. I might then ask another question for it. – JoJota Jun 11 '18 at 10:01