In the documentation https://docs.gradle.org/current/userguide/building_java_projects.html#sec:java_packaging
I saw this line dependsOn configurations.runtimeClasspath
what does it mean that a task depends on configurations.runtimeClassPath?
I could be wrong about this, and would love to hear from some with more insights into the dependency model. But here is my understanding of it.
The types you can feed into dependsOn are documented here (note that I think the RegularFileProperty and DirectoryProperty types are not possible, so let’s ignore those.)
A configuration consists of a set of dependencies, and a dependency is a “Buildable” object, which is one of the types that can be passed to dependsOn. In most cases, a dependency is pretty much just a Maven coordinate to a jar file in some external repository, and that case is not of interest here. But in a multi-project model, it may also be that a dependency is a reference to a different Gradle project, and is built by a task in that project.
So by using dependsOn with a configuration, you are implicitly creating dependencies to any tasks that is used for producing/building those dependencies.
In the uberJar example, I am pretty sure it doesn’t matter if you take away the dependsOn line as there are no (locally) buildable dependencies. However, if the runtime classpath referenced any project dependencies, you might either get wrong up-to-date checking since those tasks won’t get put into the dependency tree for the uberJar task, or Gradle will fail if you have run clean as the files will be missing.
Besides the dependsOn(configuration) declaration, it is also sometimes necessary to do a inputs.files(configurations) declaration to make the individual dependencies of a configuration part of the up-to-date check. The reason it is not needed here is that the from method implicitly adds the files to the inputs. But I do wonder why Gradle don’t do the same and pass the elements to the from method on to the task dependencies, for those elements with supported types, as that would make the CopySpec tasks (jar, zip, copy, sync, etc.) more correct by default.