Understanding the additivity of the buildscript dependencies

Old Forum
1

All,

I have a simple multi project build that I want to add the “license” plugin to. Here is my main build.gradle file:

buildscript {
  repositories {
    mavenLocal()
    mavenCentral()
  }
     }
  allprojects {
  version = 0.1
     repositories {
    mavenCentral()
  }
 }
  subprojects {
  ext.configDir = new File(rootDir, 'config')
      apply plugin: 'java'
  apply plugin: 'eclipse'
  apply plugin: 'idea'
      apply from: "$rootDir/gradle/cobertura.gradle"
  apply from: "$rootDir/gradle/checkstyle.gradle"
  apply from: "$rootDir/gradle/pmd.gradle"
  apply from: "$rootDir/gradle/findbugs.gradle"
  apply from: "$rootDir/gradle/license.gradle"
      sourceCompatibility = 1.6
    configurations {
    provided {
      description = 'similar to the maven provided scope'
      transitive = true;
      visible = true;
    }
    }
    project.sourceSets {
    main.compileClasspath += project.configurations.provided
    main.runtimeClasspath += project.configurations.provided
    test.compileClasspath += project.configurations.provided
    test.runtimeClasspath += project.configurations.provided
   }
      group = 'com.mycompany.incubator'
      sourceSets.test.java.srcDir 'src/main/java'
      tasks.withType(Javadoc).each {
    it.classpath = sourceSets.main.compileClasspath
   }
}

Because there is not any actual code in the parent project, only the child projects need to have the additional java/eclipse/idea etc. plugins. I have tried to separate some of the additional tools into their own files. I’d like you to focus in on the license.gradle file:

buildscript {
    repositories {
    mavenLocal()
    mavenCentral()
    }
         dependencies {
        classpath 'nl.javadude.gradle.plugins:license-gradle-plugin:0.7.0'
    }
      }
  apply plugin: 'license'
  ext.licenseConfigDir = "$configDir/license"
  license {
    header new File(licenseConfigDir, 'HEADER')
    ext.year = Calendar.getInstance().get(Calendar.YEAR)
    skipExistingHeaders true
}

When I run “gradle tasks”, the build complains that “Plugin with id ‘license’ not found.”. Looking at the license.gradle file above, I am correctly adding it to the classpath of the build script, but it doesn’t seem to be working as expected. If I add the same buildscript/dependency to the main gradle file, everything works. Can someone help me understand why this doesn’t work the way I have it configured above?

Thanks,

Joe

2

I don’t quite understand why this isn’t working for you, it actually should by design.

Could you try cutting this down to a small sample that also has the problem? I’ll use that to debug what’s going on.

3

Luke,

Thanks for the reply. I have thinned this out. Given the following directory structure:

gradle-test/
├── build.gradle
├── license.gradle
├── project1
└── settings.gradle

Here is the build.gradle file:

buildscript {
  repositories {
    mavenLocal()
    mavenCentral()
    }
     }
  allprojects {
  repositories {
    mavenCentral()
  }
 }
  subprojects {
    apply plugin: 'java'
      apply from: "$rootDir/license.gradle"
    }

and the settings.gradle file:

include 'project1'

finally, the license.gradle file:

buildscript {
    repositories {
    mavenLocal()
    mavenCentral()
    }
         dependencies {
        classpath 'nl.javadude.gradle.plugins:license-gradle-plugin:0.7.0'
    }
      }
  apply plugin: 'license'

When you run “gradle tasks”, you get the following output:

FAILURE: Build failed with an exception.
  * Where:
Script '/Development/gradle-test/license.gradle' line: 14
  * What went wrong:
A problem occurred evaluating script.
> Plugin with id 'license' not found.
  * Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
  BUILD FAILED

Thanks for looking into this.

4

Luke,

Any thoughts?

5

The ‘buildscript’ block has to be in the “main” build script, not the applied one. It’s a known limitation.

6

Ah right, missed that.

Isn’t the workaround in this case to apply using the class literal?

7

I don’t know if that solves it. My usual solution is to add all build script dependencies to the root project. Easy to maintain and can significantly reduce configuration time.