Unable onfigure tasks from external .gradle file


(Matthew Rusinak) #1

Hello,

We’ve broken up our base build.gradle into multiple gradle files for ease of maintenance. The general setup is this:

build.gradle
subproject-all.gradle
subproject-java.gradle
(etc etc)

In build.gradle, there is then a section that looks like so:

project.ext.nonJavaProjects = [/* names */]
// ...
subprojects {
    apply from: '../master/subproject-all.gradle'
}
configure(subprojects.findAll { !nonJavaProjects.contains(it.name)}) {
    apply from: '../master/subproject-java.gradle'
}

We moved to gradle from an older code base, and we haven’t had an opportunity to update the directory layout for easy configuration. Anyway, I’ve tried to add the javascript plugin, so I’ve added a new “js.gradle” file:

apply plugin: 'js'
  project.ext.jsBuildDir = "build/js"
project.ext.jsReportDir = "build/reports/js/"
project.ext.jsHintOptions = [ ... ]
  jshint.options = jsHintOptions
// Try to apply some configuration across all tasks of jsHint type
tasks.withType(com.eriwen.gradle.js.tasks.JsHintTask) {
    outputToStdOut = true
}

Every project that “applies from: ‘js.gradle’” then gets common configuration. Now, here’s the funny part I can’t explain - configuring the tasks to turn on “outputToStdOut” works without error, but the tasks declared in the project never get this setting. But if I move that block in the main build.gradle file (under subproject configuration) or the project itself, then it works correctly.

So alternatively, this works:

subprojects {
    apply from: '../master/subproject-all.gradle'
    apply from: '../master/js.gradle'
      // Moved from js.gradle
    tasks.withType(com.eriwen.gradle.js.tasks.JsHintTask) {
        outputToStdOut = true
    }
}

I’m wondering why the task configuration doesn’t work inside js.gradle? I should note that, as a 3rd party plugin, I needed to import the plugin in buildscript; js.gradle needed it’s own buildscript block for importing as well, so I suspect it has something to do with scoping, but I’m scratching my head.


(Peter Niederwieser) #2

Might be a class loading issue. I’d try to keep just a single ‘buildscript’ block in the root project’s build script.


(Matthew Rusinak) #3

Ah, so basically - if something requires adding to the classpath in the buildscript, then you need to have all configuration in the same file?


(Matthew Rusinak) #4

Ah, so basically - if something requires adding to the classpath in the buildscript, then you need to have all configuration in the same file?


(Peter Niederwieser) #5

There are some issues with build script blocks of script plugins, and rather than adding their dependencies to all scripts that apply the script plugins, I’d just add them to the root script.