fix: Use Classpath normalization for auxClassPaths
#314
Conversation
bigdaz
changed the title
Classpath normalization for auxClassPathsClasspath normalization for auxClassPaths
Declaring `auxClassPaths` as a `Classpath` property allows Gradle to perform additional normalization, so that functionally-identical jar files do not trigger a re-execution of the SpotBugsTask. A re-generated jar containing identical classes will have different entry timestamps for each class entry, and as such is not bitwise identical even though it is functionally identical. Without this fix, changing an input jar file will change the input cache key, leading to consistent misses from the local build cache. See https://docs.gradle.org/6.0/userguide/more_about_tasks.html#sec:task_input_using_classpath_annotations
|
Yes, this is great. Thanks @bigdaz for fixing it! |
| @@ -235,7 +236,7 @@ class SpotBugsTask extends DefaultTask implements VerificationTask { | |||
| * Default value is the compile-scope dependencies of the target sourceSet. | |||
| */ | |||
| @InputFiles | |||
There was a problem hiding this comment.
nit: we can remove @InputFiles as it's replaced by @Classpath
There was a problem hiding this comment.
That's correct, unless there is a goal to remain compatible with Gradle < 3.2.
|
🎉 This PR is included in version 4.4.5 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
|
Is it correct, that v4.5.0 has both annotations (@InputFiles AND @classpath)? Currently I am searching for changes of auxClassPaths fingerprints in my project... |
It's safe to remove the |
|
This plugin does not support Gradle < 3.2, so we can remove |
we don't support Gradle < 3.2, so the InputFiles annotation is needless for fields which is already annotated with the Classpath annotation. refs #314
we don't support Gradle < 3.2, so the InputFiles annotation is needless for fields which is already annotated with the Classpath annotation. refs #314
Declaring
auxClassPathsas aClasspathproperty allows Gradle to perform additional normalization,so that functionally-identical jar files do not trigger a re-execution of the SpotBugsTask.
A re-generated jar containing identical classes will have different entry timestamps for each class entry,
and as such is not bitwise identical even though it is functionally identical.
Without this fix, changing an input jar file will change the input cache key, leading to consistent misses from the local build cache.
See https://docs.gradle.org/6.0/userguide/more_about_tasks.html#sec:task_input_using_classpath_annotations
Note that I have tested this change locally, but not added any specific test coverage for this use case.