i would also favor switchting to the findbugs nullable annotations (now
repackaged and maintained as spotbugs annotations).
we should remove the jsr 305 dependency from our parent pom, and probably add
instead:
<dependency>
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-annotations</artifactId>
<version>3.1.5</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>com.google.code.findbugs</groupId>
<artifactId>jsr305</artifactId>
</exclusion>
</exclusions>
</dependency>
in recent eclipse versions it's possible to configure multiple
nullable-annotations - so it's possible to support both the javax.annotation
and the findbugs annotations - making it easy working with already released
sling artifacts still using the javax.annotation annotations. on the long run
we should migrate away from those.
and we have to update [1] then. not we sure if we still need to support only
"CheckForNull" - it would be nice to also support "Nullable" (in eclipse it's
possible to configure both). the related jackrabbit ticket is [2].
should we do a vote on this?
stefan
[1] https://sling.apache.org/documentation/development/jsr-305.html
[2] https://issues.apache.org/jira/browse/OAK-7511
>-----Original Message-----
>From: Konrad Windszus [mailto:konra...@gmx.de]
>Sent: Tuesday, May 15, 2018 5:17 PM
>To: dev@sling.apache.org
>Cc: stilla...@apache.org
>Subject: Re: JSR 305 annotations (nullability)
>
>IMHO migration from JSR-305 to
>https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-
>annotations/src/main/java/edu/umd/cs/findbugs/annotations
><https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-
>annotations/src/main/java/edu/umd/cs/findbugs/annotations> is very
>painless, because the former evolved from the latter. You only need to
>adjust the package name but the semantics of the annotations are the same.
>Also it has most probably the best tooling/IDE support because those are by
>far the oldest nullability annotations (invented by FindBugs before JSR-305
>has even been started). Now they are actively maintained by the spotbugs
>community. I currently fail to see a better alternative, but I am open to
>other suggestions.
>Konrad
>
>> On 15. May 2018, at 17:12, Julian Reschke <julian.resc...@gmx.de> wrote:
>>
>> On 2018-05-15 16:39, Konrad Windszus wrote:
>>> There are some ideas in https://issues.apache.org/jira/browse/SLING-7312
><https://issues.apache.org/jira/browse/SLING-7312> but not yet a solution,
>as even the proposed alternative spotbugs-annotations is not yet JSR-305
>free (which might be problematic from a licensing point of view). But IMHO
>the spotbugs annotations are the best alternative:
>https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-
>annotations/src/main/java/edu/umd/cs/findbugs/annotations
><https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-
>annotations/src/main/java/edu/umd/cs/findbugs/annotations>, because they
>are not bound to a specific IDE and are still supported by
>spotbugs/findbugs. The only thing I am not sure about is whether SonarQube
>natively supports spotbugs-annotations.
>>> Konrad
>>
>> It seems everybody agrees on the goal to move away, however it's not
>clear what to move to (see for instance,
><https://github.com/google/guava/issues/2960>).
>>
>> Best regards, Julian
>>
