And, included with a "provided" scope we're not forcing these
annotations on anyone. But they do give marvelous IDE support :)

Kristian


2014-09-22 18:32 GMT+02:00 Kristian Rosenvold <kristian.rosenv...@gmail.com>:
> Yeah, it seems to me like they just abandoned the JCP but kept the
> name. So "dormant" refers to the JCP project, not the actual findbugs
> module we're talking about here, which has a decent release frequency.
>
> Kristian
>
>
> 2014-09-22 18:19 GMT+02:00 Paul Benedict <pbened...@apache.org>:
>> Just so everyone knows, JSR 305 is in "dormant" status. Whatever
>> annotations you use aren't "standard" annotations since the JSR never
>> completed.
>>
>>
>> Cheers,
>> Paul
>>
>> On Mon, Sep 22, 2014 at 11:14 AM, Kristian Rosenvold <
>> kristian.rosenv...@gmail.com> wrote:
>>
>>>  <dependency>
>>>           <groupId>com.google.code.findbugs</groupId>
>>>           <artifactId>jsr305</artifactId>
>>>           <version>3.0.0</version>
>>>           <scope>provided</scope>
>>>     </dependency>
>>>
>>> The reason for this is that the findbugs project has been evolving
>>> these annotations at a pace, and I would now also like to use
>>> @CheckForNull, @CheckReturnValue, @OverridingMethodsMustInvokeSuper,
>>> @WillClose and @WillNotClose.
>>>
>>> (CheckReturnValue makes it an error NOT to check the return value,
>>> which is good for immutable classes...)
>>>
>>> I think these annotations are particularly valuable in shared code
>>> (maven-shared and all of plexus).
>>>
>>> Kristian
>>>
>>>
>>> 2014-09-22 18:10 GMT+02:00 Kristian Rosenvold <
>>> kristian.rosenv...@gmail.com>:
>>> > Some time ago, we discussed using the JSR305 annotations. At the time we
>>> > discussed @Nonnull and @Nullable, and it turned out that those two
>>> > annotations are "named based" in most analysis-tools; you can make your
>>> own
>>> > org.apache.maven.annotations.Nonnull/Nullable and have a reasonable
>>> chance
>>> > of having tools pick them up. Both findbugs and IntelliJ support this
>>> > approach. We sort-of concluded that this would be the optimal approach,
>>> and
>>> > since then we promptly did nothing about it :)
>>> >
>>> > I'm very happy that we didn't do anything about it, since I'd now like to
>>> > re-propose that we actually use
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to