Spotbugs 2.0 breaks if Guava is on the plugin classpath

[isker]

If spotbugs-gradle-plugin 2.0 is used in addition to any other plugin that uses an older Guava on the classpath, the build can fail as this plugin has somehow forced Gradle's Guava off of Gradle's classpath.

I have a reproducer at https://github.com/isker/spotbugs-guava-failure. See build.gradle for all that's needed to trigger this failure.

@oehme notes that this is due to the usage of many internal worker APIs and ClassLoader manipulation in this plugin, for example:

spotbugs-gradle-plugin/src/main/java/com/github/spotbugs/internal/spotbugs/SpotBugsExecutor.java

Lines 14 to 28 in 1a72b92

	final ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
	try {
	final List<String> args = spec.getArguments();
	String[] strArray = args.toArray(new String[0]);
	Thread.currentThread().setContextClassLoader(FindBugs2.class.getClassLoader());
	FindBugs2 findBugs2 = new FindBugs2();
	TextUICommandLine commandLine = new TextUICommandLine();
	FindBugs.processCommandLine(commandLine, strArray, findBugs2);
	findBugs2.execute();
	return createSpotbugsResult(findBugs2);
	} finally {
	Thread.currentThread().setContextClassLoader(contextClassLoader);
	}

spotbugs-gradle-plugin/src/main/java/com/github/spotbugs/internal/spotbugs/SpotBugsWorkerManager.java

Lines 8 to 10 in 1a72b92

	import org.gradle.process.internal.JavaExecHandleBuilder;
	import org.gradle.process.internal.worker.SingleRequestWorkerProcessBuilder;
	import org.gradle.process.internal.worker.WorkerProcessFactory;

This is a blocker to upgrading Gradle to 6.0 in any project that uses spotbugs and an older Guava on the buildscript classpath, as there is a 5.x deprecation warning that is fixed only in version 2.0 of this plugin on this line:

spotbugs-gradle-plugin/src/main/java/com/github/spotbugs/internal/SpotBugsReportsImpl.java

Line 14 in bb58cf3

super(SingleFileReport.class, task);

A potential workaround is to force resolution to a higher version of Guava (ideally the same one used in Gradle itself) on the buildscript classpath.

[oehme]

Instead of working around, the spotbugs plugin should either

• use the public worker API or
• use javaExec

Whichever fits its use case better. Please don't use internals like this.

[KengoTODA]

This classpath issue is reported continuously, such as #119, #120, #128 and #147
And the ideal solution is also known as @oehme mentioned.

What we need is a contribution to realize. This is a volunteer project, have a try if you have time!

[DPUkyle]

IIRC from #57 and #100 , javaExec is the only practical option; that is because the spotbugs tool itself carries stateful information from static initialization that persists in a dormant worker API daemon.

Worker API would be nice but unless the statefulness mentioned by @Vampire in #100 is fixed then Worker API is probably not an option.

[Vampire]

I didn't read the whole history here, just got here because of the mention. As I said in #100 already, I think a combination of worker API with javaExec should be used. That way you get parallelism by usage of the worker API and needed isolation by usage of javaExec.

[KengoTODA]

Please refer #180 and try the new implementation, it should work. If it still faces problem, please share it at here.

[KengoTODA]

I'll close this inactive issue. If you could reproduce this with the latest release, please feel free to reopen.