0

In the buildscript section of a project, which is in the configuration phase - before the task graph has been loaded, I need to somewhat guess if I need to execute a GradeBuild task or not based on if one of a set of tasks is going to be run...

Is there any way to do some guestimate of this given that I don't have access to the task graph yet?

Essentially, I need to check if the task "robospock" will be run, which can be run by the tasks "test" <- "check" <- "build", etc. or anything that dependsOn these tasks...

The relevant code is:

buildscript {
    // Evaluate hasTask in some intelligent way?

    if ( hasTask && !project.hasProperty( 'build_robospock_plugin_init' ) ) {
        project.tasks.create( name: 'build_robospock_plugin', type: GradleBuild ) {
          buildFile = rootProject.buildFile
          tasks = ['gradle-plugin-robospock:publish']
          startParameter.projectProperties = [build_robospock_plugin_init: true]
        }.execute()
    }

    repositories {
        jcenter()
        maven {
            url file( '../../maven-deploy' )
        }
    }
    dependencies {
        classpath 'se.centril.robospock:gradle-plugin-robospock:0.1.0'
    }
}

apply plugin: 'robospock'

An idea is to analyze gradle.startParameter.taskRequests and check for some common names... is there a better strategy? What task names should I look for in this case?

Are there any better ways?

Centril
  • 2,549
  • 1
  • 22
  • 30
  • What are you trying to work around here? Calling `GradleBuild#execute` in `buildscript` is horrible. – Peter Niederwieser Oct 11 '14 at 10:50
  • I'm ensuring that my custom gradle plugin "se.centril.robospock:gradle-plugin-robospock:0.1.0" is built - this is more or less the only way to enable buildscript project dependencies. This is unfortunately a limitation of Gradle which they have discussed resolving by making plugin/buildscript projects, but it is not possible in any other way yet. Edit: I realize this is one big ugly hack, but they are sometimes needed :/ – Centril Oct 11 '14 at 10:52
  • This is too big of a hack. If you must work around this known limitation, consider setting the source dirs of the `buildscript` build to the source dirs of the gradle-plugin-robospock subproject. This creates its own complications (if gradle-plugin-robospock depends on other subprojects), but it's nevertheless cleaner than the attempt above. – Peter Niederwieser Oct 11 '14 at 10:59
  • Essentially classpath "se.centril.robospock:gradle-plugin-robospock:0.1.0" can be replaced by classpath project( ':gradle-plugin-robospock' ) – Centril Oct 11 '14 at 10:59
  • How would I go about doing that? doesn't that duplicate the compilation process? (Which is what I'm trying to avoid...). With my method, the cache will at least kick in and claim UP-TO-DATE on everything more or less - I just need to avoid it being run when not needed now... By the way: As you are eng. @ Gradle, when will the limitation be breached? – Centril Oct 11 '14 at 11:09
  • It will be compiled twice only if not up-to-date. Compilation time is almost never an issue for a Gradle plugin. I don't have any information on when the limitation will be lifted. – Peter Niederwieser Oct 11 '14 at 11:16
  • Ah, I see - could you direct me to how I can do that/show me an example? Cheers! – Centril Oct 11 '14 at 11:23
  • 1
    http://github.spockframework.org is an example (`spock-report` subproject). – Peter Niederwieser Oct 11 '14 at 11:26
  • That worked wonders, if you'd like - add it as an answer so I can accept it =) – Centril Oct 11 '14 at 11:55

0 Answers0