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

Bugs
,
1

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

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:

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:

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

2

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.

3

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?

4

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.

1 Like
5

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 :wink: