Hypothesis: should use getRuntimeClasspath instead of getCompileClasspath

[davidburstromspotify]

In configureForSourceSet, the classpath is mapped as taskMapping.map("classpath", sourceSet::getCompileClasspath);
However, if the compilation depends on multiple layers of module dependencies that only expose their dependencies as implementation, those dependencies do not end up on the compile classpath, thus leading to The following classes needed for analysis were missing: messages.
I'm guessing it should be enough to replace getCompileClasspath with getRuntimeClasspath to rectify this.

[cmuchinsky]

I believe this change is now causing compileOnly items to be left off the spotbugs classpath during analysis resulting in The following classes needed for analysis were missing messages that were not present with v1.6.6.

[KengoTODA]

@cmuchinsky how you use compileOnly? For annotations? I want to know why compile-only dependencies are necessary for static analysis.

BTW we have workaround for this case: set classpath for SpotBugsTask manually.

[cmuchinsky]

I use compileOnly with the shadow plugin to designate which dependencies to relocate and bundle into "uber" jars. Shouldn't both the compile and runtime classpaths be merged together for spotbugs?

[cmuchinsky]

Any thoughts on the above comment @KengoTODA ?

[davidburstromspotify]

If the classpaths should be merged, there must be an ordering so that the runtime classpath comes before the compile classpath, otherwise you might get very weird warnings indeed.

[cmuchinsky]

@KengoTODA Perhaps the configuration name(s) to pull the classpath from should be a config option of the plugin itself, that way the user can choose the behavior that works for their use case?

[fcurts]

just got bitten by the compileOnly problem.

an example for compileOnly is when you write an extension for some other library (or framework). in that case, you don't want to have that library declared as a compile dependency in your pom (but rather as provided or not declared at all), esp. for consumers using gradle, where the highest version of a dependency wins by default. (you want to leave choosing a library version to the users of your extension, and you never, never want to override their choice.)

[KengoTODA]

Sorry for late reply, I was on vacation :)

@cmuchinsky I think your usage of compileOnly isn't natural. I recommend you to create a configuration extending compile or others. It should work as you expected.

[cmuchinsky]

I'm pretty sure my usage of compileOnly is by the book. The gradle provided compileOnly configuration is by design there for dependencies that you need for compilation, but do not want to be included as downstream dependencies.

[KengoTODA]

compileOnly is non-transitive but it's not the core of this dependency. If what you need is the non-transitive dependency, now the implementation dependency is the direct solution.

[fcurts]

implementation is a transitive runtime dependency. As explained in the Gradle docs, compileOnly has other usages such as optional and provided dependencies. It does not make sense to omit compileOnly by default.

[KengoTODA]

OK no other discussion needed, but you can have a try with classpath setting; actually this plugin uses runtime classpass as default, that will be overwritten by the classpath setting in your config :)

[ccrvincent]

I'm running into this with an annotation processor. org.immutables suggests being included at compileOnly scope, but that results in the following:

The following classes needed for analysis were missing:
  org.immutables.value.Value$Immutable
  org.immutables.value.Value$Style
  org.immutables.value.Value
  org.immutables.value.Value$Default
  org.immutables.value.Value$Check

[Vampire]

Just for the record and those still following this.
Since v4.0.0 of the plugin, it uses compileClasspath again by default. :-)

[Vampire]

So yeah, now we are back at adding the runtime dependencies to the preconfigured value instead of the compile dependencies. The plugin should probably really add both by default.