Yeah... at the same time, if someone wants to develop with Java 11 (I
don't, but it's doable now),
and run the QA builds locally, they'll have the failures. I guess I'll
disable it for now, as other projects
using SpotBugs have done.
There are still so many checks the tool can do, we don't die for
If all the checks work on Java 8, then moving them to only run on Java 8
seoms fine to me.
Torben
On Fri, Mar 1, 2019 at 1:30 AM Andrea Aime
wrote:
> Or just turn off this particular check
>
> Cheers
> Andrea
>
> On Fri, Mar 1, 2019 at 10:19 AM Andrea Aime
> wrote:
>
>> Doh, found the reason,
Or just turn off this particular check
Cheers
Andrea
On Fri, Mar 1, 2019 at 10:19 AM Andrea Aime
wrote:
> Doh, found the reason, Spotbugs reports false positives with java 11:
>
> https://github.com/spotbugs/spotbugs/issues/878
>
> Hmm... so what to do? Move the checks to use java 8, would that
Doh, found the reason, Spotbugs reports false positives with java 11:
https://github.com/spotbugs/spotbugs/issues/878
Hmm... so what to do? Move the checks to use java 8, would that be
acceptable?
Cheers
Andrea
On Fri, Mar 1, 2019 at 9:52 AM Andrea Aime
wrote:
> Ah, for reference, the PR is t
Ah, for reference, the PR is this one:
https://github.com/geotools/geotools/pull/2283
Cheers
Andrea
On Thu, Feb 28, 2019 at 10:18 PM Andrea Aime
wrote:
> Hi,
> I have this pull request that's behaving in a bizzarre way... on Travis
> spotbugs fails in the gt-referencing
> module with this outpu
Hi,
I have this pull request that's behaving in a bizzarre way... on Travis
spotbugs fails in the gt-referencing
module with this output:
[ERROR] Nullcheck of statement at line 357 of value previously
dereferenced in
org.geotools.referencing.factory.epsg.AbstractEpsgFactory.getAuthority()
[org.geo
