# Transitive libraries not included through project dependency

**URL:** <https://discuss.gradle.org/t/transitive-libraries-not-included-through-project-dependency/5444>\
**Category:** Old Forum Archive\
**Created:** [October 17, 2012, 1:51am UTC](https://discuss.gradle.org/t/transitive-libraries-not-included-through-project-dependency/5444 "2012-10-17T01:51:00Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![ari](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/ari/32/878_2.png) [@ari](https://discuss.gradle.org/u/ari)\
**Post date:** [October 17, 2012, 1:51am UTC](https://discuss.gradle.org/t/transitive-libraries-not-included-through-project-dependency/5444/1 "2012-10-17T01:51:00Z")

</div>

I know many questions are asked about gradle handling dependencies, but I just can’t find the answer to this one. I have a multi-module project where module A has build.gradle like this

```gradle
dependencies {
 testCompile project(':common:common-test')
}

```

In turn, the common-test project has test dependencies on a whole bunch of jars. When running:

gradle dependencies

on common-test, the ‘testCompile’ configuration has all the correct dependencies. But when I run that on module A, none of the transitive dependencies appear. To try and force the issue I tried this:

```gradle
dependencies {
 testCompile (project(':common:common-test')) {
  transitive = true
 }
}

```

but that didn’t help.

I also found this old topic from 2008 which suggests that this behaviour is correct: [http://gradle.1045684.n5.nabble.com/project-dependencies-and-transitivity-td1432998.html](http://gradle.1045684.n5.nabble.com/project-dependencies-and-transitivity-td1432998.html) but I can’t see a way around the problem, the section in the manual that forum refers to doesn’t exist in any version of the manual I could find.

I found this quote at [http://gradle.org/docs/current/userguide/userguide\_single.html#multi\_project\_builds](http://gradle.org/docs/current/userguide/userguide_single.html#multi_project_builds)

A lib dependency is a special form of an execution dependency. It causes the other project to be built first and adds the jar with the classes of the other project to the classpath. It also adds the dependencies of the other project to the classpath.

However, I see no clue about how to create such a lib dependency which pulls in dependencies.

Thanks for any assistance.

Ari

---

<div class="post-metadata">

**Author:** ![Peter\_Niederwieser](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@Peter\_Niederwieser](https://discuss.gradle.org/u/Peter_Niederwieser)\
**Post date:** [October 17, 2012, 5:33am UTC](https://discuss.gradle.org/t/transitive-libraries-not-included-through-project-dependency/5444/2 "2012-10-17T05:33:00Z")

</div>

‘project(’:common:common-test’)’ is a shorthand for ‘project(path: ‘:common:common-test’, configuration: ‘default’)’. The ‘default’ configuration (as configured by the Java plugin) includes ‘runtime’, but not ‘testCompile’ or ‘testRuntime’.

The easiest way to solve the problem is to use ‘compile’ instead of ‘testCompile’ for the dependency declarations in project ‘common-test’. Also, the sources of ‘common-test’ will have to be under ‘src/main/java’ rather than ‘src/test/java’. Otherwise, the ‘common-test’ Jar will be empty.

---

<div class="post-metadata">

**Author:** ![ari](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/ari/32/878_2.png) [@ari](https://discuss.gradle.org/u/ari)\
**Post date:** [October 17, 2012, 9:28am UTC](https://discuss.gradle.org/t/transitive-libraries-not-included-through-project-dependency/5444/3 "2012-10-17T09:28:00Z")

</div>

Thanks for this reply, that explanation helps a lot. Does that mean the documentation here [http://gradle.org/docs/current/dsl/org.gradle.api.artifacts.dsl.DependencyHandler.html](http://gradle.org/docs/current/dsl/org.gradle.api.artifacts.dsl.DependencyHandler.html) is wrong?

Note that it says ‘By default, when you declare dependency to projectA, you actually declare dependency to the ‘default’ configuration of the projectA.’ That’s not the same thing as the ‘archives’ configuration you suggest.

Since I really want to keep ‘src/test/’ separate from ‘src/main/’ is it possible to write something like

testCompile project(path: ‘:common:common-test’, configuration: ‘testCompile’)

I just tried it and it seems to work the way I expect. Is this a bug or limitation in gradle that the configuration scope doesn’t automatically match in this way? I’d expect that this should be the default behaviour for POLA. Or am I missing something about the way this is expected to work?

---

<div class="post-metadata">

**Author:** ![Peter\_Niederwieser](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@Peter\_Niederwieser](https://discuss.gradle.org/u/Peter_Niederwieser)\
**Post date:** [October 17, 2012, 12:01pm UTC](https://discuss.gradle.org/t/transitive-libraries-not-included-through-project-dependency/5444/4 "2012-10-17T12:01:00Z")

</div>

The docs are right; its ‘default’, not ‘archives’. I’ve corrected my post accordingly.

It’s good to keep ‘src/main’ and ‘src/test’ separate. However, I would argue that ‘common-test’ is a library containing common test utilities, rather than a bunch of tests. As such, ‘src/main’ seems more fitting than ‘src/test’. Typically, ‘src/test’ is the part of a project that’s _not_ exported.

If you want to keep the sources in ‘src/test’, you’ll have to add another Jar task, or reconfigure the one for the ‘main’ source set. In the former case, you’ll also have to add an ‘artifacts {}’ block to export the Jar via a configuration.

The fact that ‘project(’:foo’)’ always refers to the ‘default’ configuration is a limitation that a future version of Gradle will (massively) improve upon. However, it’s not quite as straightforward as simply “matching” the scopes.