Additional source set

[sharpplayer]

I was led to this plugin (rgoldberg.experimental-jigsaw) as it was based on the gradle wiki version, and had carried on from that (it was also the most recently modified jigsaw plugin).

I have an additional test source, which I called sharedTest, but what seems to be happening is that the plugin did not seem to be updating the compileShareTestJava task with all the javac options. I took the original groovy tasks and modified it for my needs:

compileSharedTestJava {
    doFirst {
        options.compilerArgs = [
            '--module-path', classpath.asPath, // <1>
            '--add-modules', 'junit,org.mockito',  // <2>
            '--add-reads', "mymodule=junit,org.mockito", // <3>
            '--patch-module', "mymodule=" + files(sourceSets.sharedTest.java.srcDirs + sourceSets.test.java.srcDirs).asPath, // <4>
        ]
        classpath = files()
    }
}

Unfortunately I am not so expert in actually developing Gradle plugins, so I couldn't really see from the code if I need to do something special to generate this via your plugin, or there is a genuine bug. If you could advise if that is the case.

Also, there is obviously the chainsaw project and I wondered if we should put effort into improving that, or if plan to continue working on this plugin (which I would consider helping on too if I can get my head around plugin dev).

For context, we are trying to move to Java11 and, in fact, we have had to jump to a nightly release build of Gradle 5 to actually make any sort of progress.

Thank you for any help/advice.

[rgoldberg]

Can you provide your build.gradle & your settings.gradle?

I've tested using the Gradle Kotlin DSL, which is better than the Gradle Groovy DSL.

[rgoldberg]

Regarding Chainsaw: it's broken in many ways, so I'd avoid using that. The maintainer didn't respond when I & others filed bugs, so I don't think it's maintained much anymore…

[rgoldberg]

The plugin only sets up a non-modular source set as test code with modular access to the modular source sets in the project if the name of the non-modular source set is test. The name of your shared test source set, however, is sharedTest.

How do you specify in your build.gradle that sharedTest contains test code?

Once I know that, I can modify the plugin to automatically modularize each registered test source set for modular access to all of the modular source sets in the project.

I imagine that you might create a Test task, and set its testClassesDir to the output.classesDir of the additional test source set, but I'm not 100% sure if that's what you use, or if that's the "Gradle-approved®" way to do it…

[rgoldberg]

Also, I've been using the most recent stable Gradle (currently 4.10.2) & the most recent Oracle JDK (currently 11+28) with my plugin. I've never needed to try any builds of Gradle 5.0. Was that necessary for my plugin, or for other parts of your build? If the former, can you try with Gradle 4.10.2, and pass along whatever problems you encounter?

[sharpplayer]

Wow, thanks for the quick reply. Moving to Gradle 5 was not an issue with this plugin, I think it was just a Java11 issue in combination with other stuff.

Hmm, I don't explicitly say sharedTest has test code...I declare it in sourceSets:

sourceSets {
	sharedTest {
		compileClasspath += sourceSets.main.output + sourceSets.test.compileClasspath
	}
}

But the configurations may hint that it is a test config by the following:

configurations {
        sharedTestCompile.extendsFrom compile, testCompile
        sharedTestRuntime.extendsFrom runtime, testRuntime, sharedTestCompile
		integrationTestCompile.extendsFrom compile, sharedTestCompile
		integrationTestRuntime.extendsFrom runtime, sharedTestRuntime

}

My build structure is pretty much based on what I gleaned from:
https://discuss.gradle.org/t/add-the-compile-runtime-classpath-of-a-source-set-as-a-dependency/5030

[rgoldberg]

You might be able to modularize sharedTest & integrationTest by creating the correct module-info.java for each of them. If javac options provide functionality that isn't available in module-info.java, or if you'd rather that your test code work without having to bother writing a module-info.java for each test source set, then, before I can support your setup, I must ask a few questions to understand it:

1. How do you get Gradle to run the tests that aren't part of the standard test source set? (e.g., tests that are part of integrationTest)
2. Why do sharedTest* extend from test*? Shouldn't test* extend from sharedTest*? This could be achieved by following configurations block:

configurations {
    sharedTestCompile     .extendsFrom compile
    sharedTestRuntime     .extendsFrom runtime
    testCompile           .extendsFrom sharedTestCompile
    testRuntime           .extendsFrom sharedTestRuntime
    integrationTestCompile.extendsFrom sharedTestCompile
    integrationTestRuntime.extendsFrom sharedTestRuntime
}

Or the following block, if your sharedTest source set doesn't depend on your main source set:

configurations {
    testCompile           .extendsFrom sharedTestCompile
    testRuntime           .extendsFrom sharedTestRuntime
    integrationTestCompile.extendsFrom sharedTestCompile, compile
    integrationTestRuntime.extendsFrom sharedTestRuntime, runtime
}

This way, the shared test code is shared between test & integrationTest.

If you really want sharedTest* to extend from test*, then it seems like test is really your shared source set, and sharedTest should be renamed to something more accurate.

FYI: you should use implementation & runtimeOnly instead of compile & runtime, respectively, since the former are the new, improved names for the latter, which are both deprecated.

[sharpplayer]

Good spot on my extensions...I remember I had it the other way round and then changed it back without thinking for some reason.

Re: running the shared test, we don't run them (I didn't realise that until you asked - but there is only 1 test there anyway). The idea of shared test is really hold test support objects that are common for integration and test. But they are dependent on junit and Mockito. I have now added a task to run them!

/** Shared test task. */
task sharedTest(type: Test) {
	description "Runs shared tests"
	group = "verification"
    dependsOn sharedTestClasses
	testClassesDirs = sourceSets.sharedTest.output.classesDirs
    classpath = sourceSets.sharedTest.runtimeClasspath + sourceSets.main.output
	reports.junitXml.destination = file("${buildDir}/test-results")
	reports.html.destination = file("${buildDir}/reports/shared")
}

I have also been able to do away with my groovy compileSharedTestJava! So I guess it was my dodgy configurations that messed it up!

Thanks for the help!

[rgoldberg]

I imagine that you need to use equivalent setups for both sharedTest & integrationTest. Let me know if I'm wrong.

I imagine that compileSharedTestJava isn't actually using the module path, rather it's just using the class path. To verify this, you can debug the Gradle build with a breakpoint at the beginning of JavaCompileTaskConfigurer#configureTask(JavaCompile, JigsawPlugin). (warning: the source in my github fork might be out of date relative to the published plugin, or vice versa)

In order to make it use the module path, I'd have to change the plugin as per my earlier post: treat as test code all source sets whose output.classesDir is a Test#testClassesDir, and configure all such source sets to use modules if they depend on any source set that defines a module.

I might not have time to implement this right away.

[sharpplayer]

Yes, I did already have an integrationTest task and integration tests are running nicely in the build, I just hadn't spotted the 1 shared test wasn't running (which is actually a test for checking some functionality of another object that is shared across several projects)!

So now I have done a bit more research:

• the task sharedTest does not actually work and I think it is a Gradle issue that is not related to this plugin. I tried v4.10.2 and I get a "failed to read oneOfMyProject.class". It seems this is an occurring issue with gradle, but didn't know the exact solution, but moving to 5.x got past this. Using the nightly build I still could not run this task, with the following exception org.gradle.api.internal.tasks.testing.detection.TestFrameworkDetector.processTestClass(Ljava/io/File;)Z. So I just ignored that, as I couldn't get to the bottom of what might cause that (perhaps I should get more serious Gradle!). This may come back to haunt me on running the integrationTest task!

• your plugin does not seem to work with apply plugin: "org.springframework.boot" as this plugin, it seems, mangles the compiler options back to only having a classpath. I am using the latest 2.0.5-Release version. I am not sure if there is anything we can do about that!

[rgoldberg]

Can you:

1. switch to the Gradle Kotlin DSL instead of the Groovy DSL (if it won’t take too much time for you; it should be beneficial to you longterm besides the shortterm benefit of ensuring that Groovy isn’t causing problems that don’t occur in Kotlin)

2. share your Gradle build & settings files

3. provide the exact version number for the Gradle version experiencing the problems

4. verify problems from the command line (if you haven’t already done so), not just in an IDE or CI, etc. Plus, provide your command line to me

[rgoldberg]

Can you also try the sharedTest task on 5.0 without my plugin, to isolate if that problem is from my plugin or elsewhere?

[rgoldberg]

I've figured out the org.springframework.boot problem.

That plugin creates a bootJar Jar task.

My plugin expected every Jar task to have created a corresponding source set, but bootJar didn't, so I got an exception when I looked for a source set named boot. I've fixed it. I'll deploy the fix soon.

[rgoldberg]

I've pushed the code to github, and published the binary to the Gradle Plugin Portal as version 0.4-SNAPSHOT (since I couldn't delete or overwrite 0.3-SNAPSHOT).

So, once you change the version of the plugin, apply plugin: "org.springframework.boot" should work.

[rgoldberg]

FYI: I tested with org.springframework.boot version 2.0.6.RELEASE, as that was just released. Shouldn't make a difference, but you might want to update that, too.

[sharpplayer]

Thank you very much, I'll take a look into this when I return to my spring projects...I was able to skip using the spring plugin for some of my projects, but it will return to it soon.