# Adding a project as default configuration dependency does not trigger building of project

**URL:** <https://discuss.gradle.org/t/adding-a-project-as-default-configuration-dependency-does-not-trigger-building-of-project/12113>\
**Category:** Bugs\
**Tags:** gradle-3347, issue-acknowledged\
**Created:** [October 9, 2015, 11:48am UTC](https://discuss.gradle.org/t/adding-a-project-as-default-configuration-dependency-does-not-trigger-building-of-project/12113 "2015-10-09T11:48:05Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![carstenlenz](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/carstenlenz/32/593_2.png) [@carstenlenz](https://discuss.gradle.org/u/carstenlenz)\
**Post date:** [October 9, 2015, 11:48am UTC](https://discuss.gradle.org/t/adding-a-project-as-default-configuration-dependency-does-not-trigger-building-of-project/12113/1 "2015-10-09T11:48:05Z")

</div>

In a multi-project I have created a plugin in buildSrc that sets up a new configuration and adds one project of this multi-project build as a default dependency

```gradle
project.configurations {
  newconf {
    defaultDependencies { deps ->
      deps.add(project.dependencies.create(project.project(":myproject")))
    }
  }
}

```

Then I create a JavaExec Task that uses this configuration as classpath:

```gradle
def myTask = project.tasks.create("mytask", JavaExec)
myTask.classpath = configurations.newconf

```

When I run this tasks a change in the project `myproject` is not considered and it is not rebuilt. When I change the default dependency to fixed one:

```gradle
project.configurations {
  newconf
}
        
project.dependencies {
  newconf project.project(':myproject')
}

```

It works as desired (project `myproject` is rebuilt before `mytask` runs).

I think I can live with the latter for my concrete use case but is this working as designed?

Cheers  
Carsten

---

<div class="post-metadata">

**Author:** ![sterling](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/sterling/32/5395_2.png) [@sterling](https://discuss.gradle.org/u/sterling)\
**Post date:** [October 9, 2015, 1:36pm UTC](https://discuss.gradle.org/t/adding-a-project-as-default-configuration-dependency-does-not-trigger-building-of-project/12113/2 "2015-10-09T13:36:44Z")

</div>

I raised GRADLE-3347. I think this may just be an oversight. What’s your use case?

Either we should support project dependencies as default dependencies or prevent it.

---

<div class="post-metadata">

**Author:** ![carstenlenz](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/carstenlenz/32/593_2.png) [@carstenlenz](https://discuss.gradle.org/u/carstenlenz)\
**Post date:** [October 9, 2015, 2:27pm UTC](https://discuss.gradle.org/t/adding-a-project-as-default-configuration-dependency-does-not-trigger-building-of-project/12113/3 "2015-10-09T14:27:13Z")

</div>

We run a custom test tool as JavaExec - the code for it is currently in the project itself and has it’s own dependencies. Therefore the custom configuration for defining the basic classpath of the tool.

I wanted to define a default but allow for the individual projects using this tool to change the classpath of it.

Hm - but actually I don’t think you would want exchange the project dependency itself but only add to the configuration if needed. That would not need the default dependency mechanism.

I would agree that it should be supported or prevented. Currently I can not give a useful use case so preventing might be easier?

---

<div class="post-metadata">

**Author:** ![sterling](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/sterling/32/5395_2.png) [@sterling](https://discuss.gradle.org/u/sterling)\
**Post date:** [October 9, 2015, 2:43pm UTC](https://discuss.gradle.org/t/adding-a-project-as-default-configuration-dependency-does-not-trigger-building-of-project/12113/4 "2015-10-09T14:43:49Z")

</div>

Thanks. I couldn’t come up with a good use case either. I think the `defaultDependencies` case is going to be mostly used for tools, like you’re saying, instead of `compile` or `testCompile` dependencies (or similar).

The best I can come up with is a situation where:

- A plugin exists to configure a tool
- Published versions of a tool exist
- A local subproject produces a modified version of the tool
- All projects in the multi-project build should use the local subproject’s version
  - Except a few projects should still use the published version

In that case, using the plugin to define a default dependency for the local project maybe makes sense. It would probably be clearer to use dependency substitution instead or directly put the dependency in each project.

---

<div class="post-metadata">

**Author:** ![carstenlenz](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/carstenlenz/32/593_2.png) [@carstenlenz](https://discuss.gradle.org/u/carstenlenz)\
**Post date:** [October 9, 2015, 5:27pm UTC](https://discuss.gradle.org/t/adding-a-project-as-default-configuration-dependency-does-not-trigger-building-of-project/12113/5 "2015-10-09T17:27:26Z")

</div>

Yes - I’m sure someone somewhere will have that exact requirements - but it sounds somehow far fetched and as you said there are other ways to make it work (and that’s why I love Gradle).

Thanks for your time. I think it should simply be prohibited to make it explicit and to prevent confusing people like me 😉