# Dependencies and multiple projects (non-java)

**URL:** <https://discuss.gradle.org/t/dependencies-and-multiple-projects-non-java/27654>\
**Category:** Help/Discuss\
**Created:** [July 7, 2018, 5:54am UTC](https://discuss.gradle.org/t/dependencies-and-multiple-projects-non-java/27654 "2018-07-07T05:54:13Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![nicolasbarbe](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/nicolasbarbe/32/7069_2.png) [@nicolasbarbe](https://discuss.gradle.org/u/nicolasbarbe)\
**Post date:** [July 7, 2018, 5:54am UTC](https://discuss.gradle.org/t/dependencies-and-multiple-projects-non-java/27654/1 "2018-07-07T05:54:13Z")

</div>

Hi,

I would like to leverage tasks and dependency resolution of Gradle for a non-java project. I have read the documentation, a few threads in SO and in this forum, but I still don’t understand how it works.

Here is a simplified version of my use case:

**project structure**

```
myproject/
  a/
  b/
  build.gradle
  settings.gradle

```

**settings.gradle**

```
include ':a', ':b'

```

**build.gradle**

```
allprojects {
  configurations {
    foo
  }

  apply plugin: "base"

  task test {
     doLast {
       println "Yeah"
     }
   }
}

project(':a') {
  dependencies {
    foo project(':b')
   }
}

```

If I run `gradle test` the task is executed first on a and then b. I would have expected the opposite:

```gradle
# gradle test

> Task :test
Yeah

> Task :a:test
Yeah

> Task :b:test
Yeah

BUILD SUCCESSFUL in 0s
3 actionable tasks: 3 executed

```

---

<div class="post-metadata">

**Author:** ![jjustinic](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/jjustinic/32/9005_2.png) [@jjustinic](https://discuss.gradle.org/u/jjustinic)\
**Post date:** [July 8, 2018, 6:47pm UTC](https://discuss.gradle.org/t/dependencies-and-multiple-projects-non-java/27654/2 "2018-07-08T18:47:43Z")

</div>

In your example, there are zero dependencies that would influence order of execution for your `test` tasks.

> [@nicolasbarbe](#):
>
> ```groovy
> project(':a') {
> dependencies {
> foo project(':b')
> }
> }
> 
> ```

This code configures a dependency from the `foo` configuration of project `a` to the main output of project `b`. However, unless you have a task that consumes `foo` as an input, it won’t influence task ordering.

Even in a Java project, these `test` tasks wouldn’t have a guaranteed order unless you set `dependsOn` or `mustRunAfter`, or `shouldRunAfter` between them. They would depend on the compilation of the main project code and the test code, so more dependencies of `:b:test` would be met before `:a:test`.

As your example project is simplified, it’s hard to know what is most sensible for your actual project. It may be explicitly configuring `mustRunAfter` / `shouldRunAfter` for those `test` tasks. The main thing is that a project dependency will not control the order of isolated tasks in that project.

---

<div class="post-metadata">

**Author:** ![nicolasbarbe](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/nicolasbarbe/32/7069_2.png) [@nicolasbarbe](https://discuss.gradle.org/u/nicolasbarbe)\
**Post date:** [July 9, 2018, 6:59am UTC](https://discuss.gradle.org/t/dependencies-and-multiple-projects-non-java/27654/3 "2018-07-09T06:59:32Z")

</div>

> [@jjustinic](#):
>
> unless you have a task that consumes `foo` as an input, it won’t influence task ordering.

Thanks, that’s exactly the part I misunderstood!

So I should write something around these lines, correct?

```gradle
 task test {
     inputs.files(configurations.foo) 
     doLast {
       println "Yeah"
       // use configurations.foo
     }
   }
```

---

<div class="post-metadata">

**Author:** ![jjustinic](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/jjustinic/32/9005_2.png) [@jjustinic](https://discuss.gradle.org/u/jjustinic)\
**Post date:** [July 10, 2018, 3:40am UTC](https://discuss.gradle.org/t/dependencies-and-multiple-projects-non-java/27654/4 "2018-07-10T03:40:04Z")

</div>

On the consuming side, yes, but nothing in your example really screams producer.

Typically you’d have something in project `b` that would produce a file and you’d configure it as an artifact. That could be an artifact of the `foo` configuration on project `b`. Depending on what it is, you may need to use `builtBy`. Once you have that, the domain modeling would cause the relevant task in project `b` to run before the relevant task in project `a`. Generally that doesn’t make sense for the `test` task of multiple projects though.

If it’s just a `test` task that must run before another `test` task, you’re better off just configuring that. It doesn’t make sense to force artifacts and dependencies into the model if that’s not really what you have.

---

<div class="post-metadata">

**Author:** ![nicolasbarbe](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/nicolasbarbe/32/7069_2.png) [@nicolasbarbe](https://discuss.gradle.org/u/nicolasbarbe)\
**Post date:** [July 10, 2018, 6:35am UTC](https://discuss.gradle.org/t/dependencies-and-multiple-projects-non-java/27654/5 "2018-07-10T06:35:07Z")

</div>

So let’s say the `test` task produces an archive and needs to do something with archives produced by its dependencies ( project `a` having a dependency on project `b` for such artifacts).

My example would be:

```gradle
 allprojects {
  
  configurations {
    foo
  }

  task test(type: Tar) {
     inputs.files(configurations.foo) 

     // configure Tar

     doLast {
       // use configurations.foo to access Tar files produced by task's dependencies
     }
   }

   artifacts {
     foo test
   }
}

project(':a') {
    dependencies {
        foo project(path: ':b', configuration: 'foo')
    }
}

```

I have not tested this code, but I have implemented this approach on my use-case successfully. I understand now better how it works, thanks for your help!