Support for Gradle 4.x for Clover plugin

[piotrgajow]

I am running grails 3 project with only groovy source code.

After adding and configuring gradle-clover-plugin the test gradle task fails with message

Directory does not exist: (...)\build\classes\java\main

As I have no *.java source files in the project, this directory is not created during gradle build. Only \build\classes\groovy\main is present.

As a workaround I can create an empty directory in this path, but each clean will remove it.

I did not find any configuration option to fix this... Is there any? Or is it some kind of bug?

[Alex-Vol]

This is caused by running Grails with Gradle 4. As far as I know Grails 3 does not yet support Gradle 4 and this plug in has not been converted to support gradle 4.It may take some time before I can fix all the issues that were caused by the changes in Gradle 4.

[piotrgajow]

Correct. I have tested it on another computer with Gradle 3.5 and the problem does not exist.

Thank you for help!

[TomUdr]

Hi, I would like to push this Feature Request further. I think the problem is as stated in issue title, clover does not support gradle 4.1.

If I run gradle project with clover, the following message appears: Gradle now uses separate output directories for each JVM language, but this build assumes a single directory for all classes from a source set. This behaviour has been deprecated and is scheduled to be removed in Gradle 5.0 However if I remove the clover, the message has gone.

Looking into source code to InstrumentCodeAction.groovy and CloverPlugin.groovy it's obvious that plugin works only with single output directory. Look into Gradle 4.0 doc: https://docs.gradle.org/4.0/release-notes.html#multiple-class-directories-for-a-single-source-set.

I have project with java main classes with groovy test classes. Impact of this problem is that groovy test classes gets compiled by plugin to classes/java folder and all those tests are therefore executed twice (because they are also compiled correctly under classes/groovy by gradle itself).

[Alex-Vol]

I fully understand how this would affect you, but I have not had time to get back to this. Day job commitments and life take over. To solve this correctly first we need to capture the difference between sources that get compiled as java/groovy mixed together in a src/main/groovy directory outputting both into classes/groovy and sources separated in src/main/java side by side with src/main/groovy outputting in separate directories each.

The internal structure of this plugin currently makes a simple logic decision when it is applied to either compile groovy/java combined or just compile java. The logic is based on having the groovy plugin applied and not based on the sources existing in the segregated source locations. As a result this causes the sometimes incorrect compilation of pure java sources by the Groovyc task when the default Gradle java/groovy combination would compile src/main/java with javac and src/main/groovy with groovyc.

The additional complexity of the segregated output directories will now have to enter this task and be addressed correctly.

My intent is to refactor the logic to use the contents of the source sets and the declared output directories as hints for the compilation and reconstruct the exact matching compilation units as they would be had the sources been compiled by the bundled java/groovy plugins.

[TomUdr]

Awesome! Thanks for the reply.

[ghost]

@Alex-Vol if you can throw down some TODOs on a branch, I can pick it up.

[Alex-Vol]

I will try to find some time to document where I think we can make changes to get this done. I have not had any time to get back into it.

One issue that I alluded to in the previous comment is that we compile Java and Groovy together even if they are setup in separate src/main/java and src/main/groovy directories. The Gradle 4.x approach is to compile each language source set into a separate directory.

I will see about opening a branch and annotating the code with TODO where we can make changes to address this.

[ghost]

I took a stab at getting the project itself to run on Gradle 4.3.1 and found the only hurdle to be the exotic integrationTests setup. Thank you for any guidance you can provide on the work mentioned above.

[ghost]

A holiday present! Thanks for getting this support out. I'm updating some of our projects to use it today :)

[ghost]

I've switched over the projects at my organization and can verify everything is working perfectly with Gradle 4.4 :+1:

[bmuschko]

@influenza Noice!

[TomUdr]

Confirming this works! Many thanks to all.