But the annotations are part of the code, so no-go still. They should be
removed...

2015-01-22 20:48 GMT+01:00 Reinhard Sandtner <[email protected]>:

> the dependency is compile scoped so if i use tamaya i’ll get this dep to -
> for me, this is an absolute no-go
>
> if we really want to have these checks, we should add the dependency with
> optional
> findbugs-maven-plugin has a dependency to the annotations too so it should
> work
>
> lg
> reini
>
>
> > Am 22.01.2015 um 20:30 schrieb Mark Struberg <[email protected]>:
> >
> > +1 for removing. Our core is really that small that we should not need
> it. And with Java8 this JSR is not only dormant but really obsolete.
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >
> >> On Thursday, 22 January 2015, 20:28, Anatole Tresch <[email protected]>
> wrote:
> >>> If you ask me, I am against adding an additional dependency for tool
> >> support. I would to remove these annotations and the dep completely.
> Other
> >> opinions? Am I the only one?
> >>
> >>
> >> 2015-01-22 20:25 GMT+01:00 Oliver B. Fischer <[email protected]
> >:
> >>
> >>> Hi Reinhard,
> >>>
> >>> FindBugs and similar tools can use these annotations not only to
> suppress
> >>> errors. They use it even for flow analysis.
> >>>
> >>> For example @CheckForNull allows FindBugs do detect what a caller of
> this
> >>> method does not perform a null check and might end in an NPE. Therefor
> >>> these annotations are very usefull for us to improve the quality of our
> >>> code base. Even the users of Tamaya will benefit from it if they also
> use
> >>> FindBugs.
> >>>
> >>>
> >>> Oliver
> >>>
> >>>
> >>> Am 22.01.15 um 12:25 schrieb Reinhard Sandtner:
> >>>
> >>>> whats the benefit of this lib?
> >>>>
> >>>> is it only for findbugs?
> >>>> we use a filter file - i think its better to have all our exclusions
> in
> >>>> the filter file with comments why it is excluded. so all are in one
> >> place
> >>>> and its very easy to find
> >>>>
> >>>> lg
> >>>> reini
> >>>>
> >>>>
> >>>>  Am 22.01.2015 um 12:17 schrieb Mark Struberg
> >> <[email protected]>:
> >>>>>
> >>>>> That is really a grey area and up to the lawyer.
> >>>>>
> >>>>> LGPL is only widely agreed to be non-viral if you have it as
> >> runtime
> >>>>> linked library.For larger work and direct compile inclusion it is
> >> partly
> >>>>> assumed to be viral.
> >>>>>
> >>>>> See our licensing matrix:
> >>>>>
> >>>>> http://www.apache.org/legal/resolved.html
> >>>>>
> >>>>>
> >>>>> LieGrue,
> >>>>> strub
> >>>>>
> >>>>>
> >>>>> On Thursday, 22 January 2015, 12:10, Andres Almiray
> >> <[email protected]>
> >>>>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>> --
> >>> N Oliver B. Fischer
> >>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >>> P +49 30 44793251
> >>> M +49 178 7903538
> >>> E [email protected]
> >>> S oliver.b.fischer
> >>> J [email protected]
> >>> X http://xing.to/obf
> >>>
> >>>
> >>
> >>
> >> --
> >> *Anatole Tresch*
> >> Java Engineer & Architect, JSR Spec Lead
> >> Glärnischweg 10
> >> CH - 8620 Wetzikon
> >>
> >> *Switzerland, Europe Zurich, GMT+1*
> >> *Twitter:  @atsticks*
> >> *Blogs: **http://javaremarkables.blogspot.ch/
> >> <http://javaremarkables.blogspot.ch/>*
> >>
> >> *Google: atsticksMobile  +41-76 344 62 79*
> >>
>
>


-- 
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

*Switzerland, Europe Zurich, GMT+1*
*Twitter:  @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*

*Google: atsticksMobile  +41-76 344 62 79*

Reply via email to