On 15/01/2012, at 3:12 AM, Luke Daley wrote:

> I would have expected this to work:
> 
> apply plugin: "java"
> 
> repositories {
> mavenCentral()
> }
> 
> dependencies {
> compile 'junit:junit:4.9'
> }
> 
> task doIt {
> dependsOn configurations.compile
> doFirst {
> assert configurations.compile.state == Configuration.State.RESOLVED
> }
> }
> 
> Instead it fails because the configuration is not resolved when the task 
> executes.
> 
> Using dependsOn configurations.compile.buildDependencies does not work 
> either, same problem.
> 
> I also tried dependsOn configurations.compile.files, which does trigger a 
> resolve but then explodes because it tries to find a task with a name 
> matching the absolute path of each dependency file.
> 
> I stumbled upon this when answering a forum question that lead to me writing 
> and trying the following:
> 
> task unpack(type: Copy, dependsOn: configurations.compile) { task ->
> into "sdks"
> assert configurations.compile.state == Configuration.State.UNRESOLVED
> configurations.compile.incoming.afterResolve { ResolvableDependencies 
> incoming ->
> incoming.files.each { File file ->
> if (file.name.endsWith(".zip")) {
> from (zipTree(file)) {
> into file.name - ".zip"
> }
> 

I don't think trying to do configuration in response to a resolve event is a 
good approach to configuration - it doesn't describe the dependency between the 
task and its configuration logic very well. I think the solution to the above 
problem would be to use a (regular) configuration task that executes before the 
unpack task:

task configureSdks {
    dependsOn configurations.compile
    doLast { 
        configurations.compile.each {
            if (it.name.endsWith(".zip") {
                unpackSdks.from(zipTree(it) { into it.name - ".zip" }
            }
        }
    }
}

task unpackSdks(type: Copy, dependsOn: configureSdks)

Given that such logic is so common, we should add some convenience methods to 
the DSL for this. We've discussed this a bunch of times on this list.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply via email to