How to delay download of dependencies

Help/Discuss
1

We are working on a multi-project build. One of the projects has some very bulky, multi-gig, dependencies. Even running ‘gradle clean’ will download the latest version of those dependencies! Is there any way to turn off automatic dependency downloading, and trigger it only when a task is run that needs it?

thanks for any help

2

Dependencies are not resolved until they are needed. Something is triggering dependency resolution at configuration time. Typical cases are doing things like configurations.foo.each { } or configurations.foo.files which will trigger dependency resolution. Could you perhaps share some of the buildscript for this particular project to aid in troubleshooting?

3

There are several custom tasks that are configured with a particular artifact with this syntax:
configurations.configName.incoming.files.last()

So that must be the culprit. What alternative would you recommend?

4

There are a couple of options for deferring this until execution time.

  1. Use a “configure task”, that is, a task whose action configures another task.
  2. Set the property in a doFirst { } block. Basically the same as #1 but it isn’t a separate task. The benefit of using option #1 is that any configuration done will be taken into consideration for up-to-date checking.
  3. Modify the task to accept a closure and evaluate it at execution time.

Another option is to accept the entire configuration as an input and then resolve it and grab what you need from it in the task action.

5

Thank you. Here’s a related question. The reason for the configurations…last() language is that the resolved version of the artifact is not known ahead of time - the ‘version’ may be something like ‘8.1-+’ - and many of the non-dependency tasks won’t work with regexes in a file name. We have that same problem come up in several contexts. We’ve found some roundabout ways to hunt up the resolved version, but what is the best/cleanest way?

thanks again

6

The easiest way around this is typically to create a separate configuration for this one dependency. Then you can pass that configuration to the task with the assumption it will contain at most one file. You can then get at the artifact via configurations.foo.singleFile. Again, that should be done in the task action to avoid resolving the configuration eagerly.

7

Those are great suggestions for custom tasks. What do you suggest when the task is a Copy task? In that case, if I put the configure block into doFirst, gradle sees no input for the task and doesn’t run it. Still, I’d like to delay resolving the configuration until execution time.
Here is the kind of thing I’m talking about:

task extract (type:Copy){
// group and description here
from {configurations.aConfig.collect {zipTree(it)}}
into “$buildDir/unpack”
}

thanks,
Joan