rakutentech / android-buildconfig

Shared (gradle) build configurations for Android and Java libraries
MIT License
21 stars 26 forks source link

[FingBugs] Annotations being compile-only is probably a mistake #45

Closed jcayzac closed 6 years ago

jcayzac commented 6 years ago

https://github.com/rakutentech/android-buildconfig/blob/8cc3dc638cceb3efcf74cb0fdc1355fdd31e3c51/quality/findbugs/android.gradle#L45

The annotations should be a transitive dependency, otherwise proguard on the client side will complain. Silencing the proguard warnings in the libraries' consumer proguard is also not very nice since it's going to silence them for everything in the client project.

NemoOudeis commented 6 years ago

the reason I opted for compile only was to not package the annotations, because they are not needed at runtime. Looking at it now I see that that's a mistake because many of the annotations in javax.annotation have runtime retention and even edu.umd.cs.findbugs.CreatesObligation,edu.umd.cs.findbugs.CleanupObligationand edu.umd.cs.findbugs.DischargesObligation annotations have runtime retention.

jcayzac commented 6 years ago

the reason I opted for compile only was to not package the annotations, because they are not needed at runtime

Notwithstanding the comment on javax.annotations that would be a valid reason only for an application project. Not retaining the annotations in the final .aar of the library means you will raise tons of warnings in the client projects.

NemoOudeis commented 6 years ago

You are right about the warnings, they are a pain (and proguard is not a good solution for this).

NemoOudeis commented 6 years ago

reverted the merge because the findbug annotations pom is broken - the jar includes the annotations in package javax.annotation and net.jcip.annotations and at the same time pulls in the artifacts net.jcip:jcip-annotations and com.google.code.findbugs:jsr305 - which contain the same classes. complieOnly is appropriate for such silliness...