The Apache Aurora project is trying to upgrade from Gradle 2.7 to a newer release. However upgrading to gradle 2.8, 2.9 or 2.10 results in false positives from the pmd plugin with nothing else changed.
The output on gradle 2.7 shows the pmd check passing:
With any newer version gradle the output is:
/Users/zmanji/code/aurora/src/main/java/org/apache/aurora/scheduler/app/SchedulerMain.java:224: Avoid unused private methods such as 'exit(String,Exception)'.
/Users/zmanji/code/aurora/src/main/java/org/apache/aurora/scheduler/cron/quartz/CronLifecycle.java:76: Avoid unused private methods such as 'logLaunchFailure(IJobConfiguration,Exception)'.
/Users/zmanji/code/aurora/src/main/java/org/apache/aurora/scheduler/thrift/aop/AopModule.java:114: Avoid unused private methods such as 'bindThriftDecorator(MethodInterceptor)'.
FAILURE: Build failed with an exception.
In both cases gradle was configured to use the latest version of 5.4.1:
toolVersion = '5.4.1'
consoleOutput = true
This issue was also reported on the pmd bug tracker on sourceforge.
I think this is a gradle issue more than a pmd issue because it appears that changing the gradle version and not the pmd version triggers the false positives. This signals to me that something changed in gradle or the gradle pmd plugin that causes the false positives.
The changes to the Pmd plugin in Gradle 2.8 are specifically noted in two sections of the release notes:
As of Gradle 2.8, Gradle is now providing additional information for PMD to use by default, but that’s not really an issue to fix in Gradle. This additional information should be provided, and has the effect that PMD can find additional issues, but by the same principal, additional false positives.
The ultimate fix will likely be a PMD rule change to address the specific cases that are causing the false positive. It’s probably best to add as much data as you can gather about the failure in the PMD issue, although with an open source project, what you provided here might be good enough if they can just download the source and recreate.
On the Gradle side, if you want to upgrade to Gradle 2.8 or higher before PMD fixes the rule, you can just configure your build not to provide the additional auxclasspath parameter to PMD, which is what was added in Gradle 2.8. Just set the classpath on all
Pmd tasks to null.
classpath = null
Thanks @jjustinic - nulling out classpath (auxClasspath) does the trick for us. I will note that I was able to reduce ~6 errors down to 2 by ammending the default auxClasspath to include the classes of the project pmd was being applied to (
classpath = sourcesets.main.output + sourceSets.main.compileClasspath) … not fully sure though of all my work there. I’ll propose a classpath tweak if further investigation solidifies this was the correcting factor in my hacking on this problem.