How do I put a "root project" dependency into a sub-project?

(Jon Austen) #1

How do I put a “root project” dependency into a sub-project? I am trying to do this but I can’t find a specific example in the docs (unless I overlooked something).

In my root project build.gradle I have this (which I got from the documentation but it throws an error: Cannot set the value of read-only property ‘name’ on root project): = 'main'

I was intending to reference in like this but I get errors:

subprojects {
      dependencies {
        compile project(':main')

Is there a standard way of doing this?

I also tried it another way and got this warning:

“The Project.childrenDependOnMe() method has been deprecated and will be removed in the next version of Gradle.”

(Peter Niederwieser) #2

You can only set project names in ‘settings.gradle’, and I’d be surprised if the documentation said otherwise. You can refer to the root project with ‘rootProject’, although it’s uncommon to have a project dependency on the root project.

(Jon Austen) #3

Why is it uncommon? I have a root project with libraries that will be needed for all the subprojects. Am I thinking of this incorrectly? I just dont want to duplicate code into my sub-projects.

(Peter Niederwieser) #4

You’d typically use configuration injection to declare common dependencies: ‘subprojects { dependencies { … } }’.

(Jon Austen) #5

At your suggestion I tried this but I get a “package does not exist” message at runtime:

subprojects {
    dependencies {

(Peter Niederwieser) #6

That’s not a valid declaration. Please consult the documentation on how to correctly declare dependencies.

(Jon Austen) #7

Ok but I find that last sentence a little cryptic…

(Jon Austen) #8

In my initial question on this thread I believe I tried what was in the documentation: using “compile project(‘name’)”

(Peter Niederwieser) #9

I suggest to study ‘samples/java/multiproject’ in the full Gradle distribution (which declares a JUnit dependency for all subprojects), and to study the “multi-project builds” chapter in the Gradle User Guide.

(Jon Austen) #10

Yes, I already did, which is why I mentioned the deprecation in my original question. I tried using childrenDependOnMe() as the “water” project suggests but it still fails to find the parent projects classes.

I don’t believe there are any true examples in the documentation of what I am asking. In fact, I suspect what I am doing is impossible by what I am reading around the internet.

The documentation shows an example of using a “shared” project, seemingly as a workaround. If I move the root project code into its own “shared” sub-project I can get it to work but I was hoping I didn’t need to do that.

(Peter Niederwieser) #11

You are still following the wrong approach (dependency on root project, ‘childrenDependOnMe’, etc.). I suggest to study ‘samples/java/multiproject’ in the full Gradle distribution, which declares a JUnit dependency for all subprojects. In the same way, you can declare any other dependency for all subprojects (or a subset thereof).

(Jon Austen) #12

Ok, but what I get from that is that it will work if I move my entire project tree one layer deeper so I have a settings.gradle like

include 'main', 'main:proj1', 'main:proj2'

. Is this correct?

(Jon Austen) #13

Ok, I figured it out. It took a while but I found no way to inherit the default root project dependencies.

I found a workaround that if I arrange my project one level deeper, it worked:

Root project
  Root project 'WebDriverTestingTemplate'
\--- Project ':core'
     +--- Project ':core:bing'
     \--- Project ':core:google'
  To see a list of the tasks of a project, run gradle <project-path>:tasks
For example, try running gradle :core:tasks

Then, I can inherit the “:core” parent project like so:

project(':core:google') {
    dependencies {
        compile project(':core')
    project.ext.projVersion = '0.99.2'
    project.ext.projTitle = 'WebDriver on Google'
        task packageTests(type: Jar) {
        from sourceSets.test.output

(Stuart Stevenson) #14

Glad to have found this post. We’ve used this as a temporary step while refactoring a legacy project so it would build with gradle. The next step will be to move the code in the root project to its own submodule. However this allows us to minimize disruption and reduce the impact of each commit.

dependencies {
    testCompile rootProject