Not sure if we do an "exclusive" or "inclusive" vote now, but for substantial components like API or core I certainly say +1 to avoid these dependencies (or -1 on using them;-)
Depending on particular modules or extensions, there could be a bit of freedom, let's say a "reporting" or "analytics" module may use additional artifacts like Asciidoc(tor) or similar while other modules don't require it. If there's just a single user or class that requires it, I'd say that never justifies the extra baggage. Should there be a wide-spread use by some specific module, then maybe, but it should be applied with care. Werner On Wed, Feb 11, 2015 at 1:47 PM, Anatole Tresch <[email protected]> wrote: > Then you should ask users if they really use that tool. I really do not > know one person (beside you obviously ;) ), that uses it in that way... > > 2015-02-11 13:44 GMT+01:00 Oliver B. Fischer <[email protected]>: > > > The advantage is the value you provide to your users. If your users use > > FindBugs and similar tools they would be able to detect possible NPE > before. > > > > Oliver > > > > Am 11.02.15 um 13:00 schrieb Anatole Tresch: > > > >> maybe that's ok for Google, but not for me. We should really minimize > the > >> deps, and as I said adding deps just of a tool, then the tool is broken > >> IMO. > >> And adding a production dependency is quite a harsh thing, it must be > well > >> legitimated IMO, which in our case I do not see it. We can use FindBugs > >> plugin and the other quality tools (e.g. Sonar), from my experience this > >> is > >> far enough. Finally most of the checks can be covered by writing tests > as > >> well... > >> > >> 2015-02-11 12:47 GMT+01:00 Oliver B. Fischer <[email protected] > >: > >> > >> For Google Guava it works quite well... Why not for us? > >>> > >>> Am 11.02.15 um 12:15 schrieb Anatole Tresch: > >>> > >>> -- > >>> 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 > >>> > >>> > >>> > >> > > -- > > 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* >
