Is there an event/or action I can hook up to, in order to do something when Gradle downloads a dependency? I see the listeners on the project for things like DependencyResolution… but I don’t see a dependencydownloaded or anything like that.
I know that I can access all the dependencies in a configuration, and I know I can access all the files of a configuration, Is there an easy way a to know which file came from which dependency?
Thank you.
For any given configuration you can ask it for the files of any given dependency. So getting the information I believe you want would simply involve iterating over this information. Try adding the following task
task dependencyFiles << {
configurations.compile.dependencies.all {
println "${it}: "
println configurations.compile.files(it).collect { it.name }
}
}
It should produce output that looks something like:
DefaultExternalModuleDependency{group=‘org.codehaus.jackson’, name=‘jackson-mapper-asl’, version=‘1.9.12’, configuration=‘default’}:
[jackson-mapper-asl-1.9.12.jar, jackson-core-asl-1.9.12.jar]
Thanks for the information… While it is useful, its not quite what I’m looking for. The method you just described will give me all of the (transitive) files from a dependency, but not the group of these dependencies, you still also only have the group of the first level dependency.
What I really want to do is to process a downloaded dependency file a single time (the first time its is downloaded into the cache). So, the second time you run a build, there would be no processing since the artifact was already local.
example: I have a really large archive file as a dependency, and I need to access the contents of that file in a build. I don’t want to have to unarchive it every build… I want to unarchive it once and put the contents into a local cache. If I could attach a listener to the act of downloading a dependency, it would solve this problem for me.
It seems like this kind of thing is more appropriately solved using incremental build support. I would simply add a task that did the unpacking of this artifact. The only issue I see with this approach is that your “cache” would be wiped out whenever you did a ‘clean’ but you could probably avoid that by putting the output of your task outside your build directory.