Are custom tasks always configured before dependency resolution?

Using M6 and gradle-artifactory plugin, custom tasks appear to be evaluated (in the configuration phase) before custom configuration/artifact dependencies are resolved. As a result, gradle --dependencies is failing. If somehow I hide the custom task under a gradle.taskgraph.whenReady {} block then it does not fail. Also, using maven plugin + nexus repo (ie, artifactory {} block commented out) dependency resolution does not fail.

I have a custom task (JavaExec) that uses a configuration block and I need the pass full-path to a jar file in my local repo as one of it’s arguments. Here’s my task -

task solBuilder(type:JavaExec) {

main ‘com.company.module.component.builders.Builder’

classpath sourceSets.main.runtimeClasspath, configurations.compile

args = ["$projectDir", configurations.rhinoJs.asPath, ‘…/log4j.xml’] }

And, here’s my configuration/dependencies block - configurations.add(‘rhinoJs’) dependencies {

rhinoJs group:‘rhino’, name:‘js’, version:‘1.6R1’ }

I’ve tried to move the custom task to the execution phase (using <<) but I got a “no main class found” error and I still don’t know why… the main class was specified correctly, the jar was there, the main class file was inside it… nothing stands out. Any pointers on how I could workaround this one? In a nutshell, I just need to pass the full-path to a jar file in my local repo as one of the arguments to the JavaExec task. I’ll appreciate the help.

In a nutshell, I need to pass the full-path to a jar file in my local repo as one of the arguments to the JavaExec task. It appears it can’t resolve rhinoJs when it gets to the configurations.rhinoJs.asPath. What other methods can I try?

It’s not usually a good idea to rely on dependency resolution in the configuration phase, if you can avoid it. You could avoid this with something like:

task solBuilder(type:JavaExec) {
     main 'com.company.module.component.builders.Builder'
     classpath sourceSets.main.runtimeClasspath, configurations.compile
    doFirst {
        args = ["$projectDir", configurations.rhinoJs.asPath, '../log4j.xml']
     }
}

This may or may not fix your problem. Without an error message or stacktrace or any other information, it’s pretty hard to tell what’s going wrong with dependency resolution.

Yeah, that works! The doFirst {} block pushes it out to the execution phase, I suppose. I should’ve thought about it. Many thanks!