When is it needed to add extra dependsOn relation when adding artifacts to a configuration?

Old Forum Archive
1

Hi!

I have some questions about proper project artifact referencing. Given the following code sample, what is the recommended way to declare artifacts?

subprojects {
 apply plugin: 'java'
}
  project('project-a') {
 configurations {
  tests
 }
   task packageTests(type: Jar) {
  from sourceSets.main.output
  classifier 'tests'
 }
   artifacts {
  tests packageTests
 }
   assemble.dependsOn packageTests
// Question 1. When do I need this line?
}
  project('project-b') {
 dependencies {
  testCompile project(path: ':project-a', configuration: 'tests')
 }
   task debug {
  dependsOn ":project-a:assemble"
// Question 2. Does this line cause project coupling?
  doLast {
   configurations.testCompile.files.each {
    println it
    println it.size()
   }
  }
 }
}

The Gradle In Action book suggests that it is better to use an artifacts block to put jars into a configuration, rather than adding a dependsOn releation to a task to let it be called.

It works fine if I add the jar to the ‘archives’ configuration, but if I use a custom configuration (like ‘tests’), the test jar is not created, even at the time of printing the file size in the ‘debug’ task of the second project.

In the ‘debug’ task, I can print out the path of the tests jar, but the jar is still not created until I add the dependsOn method to the ‘debug’ task. Is it normal that I can correctly print the path of a jar as if it exists while not? It coused me some headache during debugging, until I realized that some jars are not actually created yet.

So here are my 2 questions: 1. When is it enough to use the artifacts block without explicitly adding the assemble.dependsOn line? It seems to me that it is needed if I use a custom configuration. But auto-wired with Java configurations. Am I right? 2. If I add the dependsOn method call to the debug task, can it cause unwanted “project coupling” and result in parallel problems later? Because my tasks usually depend on other tasks in the same project, but this one points a bit farther.

Thanks,

Akos

2

The purpose of the ‘assemble’ task is to build the ‘archives’ configuration. The suggestion in the book is likely about something different, namely that adding a project dependency on another project’s configuration will automatically infer the necessary task dependencies. (The task(s) consuming the configuration will depend on the task(s) producing the configuration’s artifacts.)

Declaring a task dependency on a task in another project is fine where needed.