Skip to end of metadata
Go to start of metadata

Tricks and Tipps

check java compiler for the n00bs

Adding sourceSets

too simple (wink)

Adding expanding SourceSets

see discussion in http://stackoverflow.com/a/37882006/529977

apply plugin: 'java'

// apply the runtimeClasspath from "test" sourceSet to the new one
// to include any needed assets: test, main, test-dependencies and main-dependencies
sourceSets {
    integrationTest {
        // not necessary but nice for IDEa's
        java
        resources

        compileClasspath += sourceSets.test.runtimeClasspath
        // somehow this redeclaration is needed, but should be irrelevant
        // since runtimeClasspath always expands compileClasspath
        runtimeClasspath += sourceSets.test.runtimeClasspath
    }
}

// define custom test task for running integration tests
task integrationTest(type: Test) {
    testClassesDir = sourceSets.integrationTest.output.classesDir
    classpath = sourceSets.integrationTest.runtimeClasspath
}
integrationTest.dependsOn test

 

I'm still not sure, it's 100% correct ... I expect there are side effects of this solution

Expanding (test) SourceSets in Multi-Project configuration

You:

  • have a multi-project gradle configuration
  • have a some sort "library"
  • can include the "library" in your other subproject by simply add this dependency:

    dependencies {
      compile project(':library-subproject-name')
    }

    which automatically adds the compileOutput from this project library to your project

  • can't use the same bechanism for testCompile, so this won't work:

    dependencies {
      testCompile project(path: ':library-subproject-name', configuration: 'testCompile')
    }

    but just adds all dependencies from library-subproject-name.testCompile to your testCompile, missing the testOutput / classes themself.
    so: you can't define some sort of "base test classes" or "JUnit Categories"

 

Reading https://docs.gradle.org/current/userguide/java_plugin.html you might think, compile project(':library-subproject-name') is the same as compile … configuration: 'default') i.e. … configuration: 'runtime'

So: testCompile … configuration: 'testCompile' or even testCompile … configuration: 'testRuntime' should do the same.

And you're totally right!

Except the fact: testCompile doesn't provide an artifact so you just get the dependencies on test* but not test* artifact itself!!!

 

This is where some tricks come in:

referring to:

Open Problems

Open Questions

 

Links

  • No labels