> On Apr 6, 2020, at 11:29 AM, Nick Dimiduk <[email protected]> wrote:
> I qualify as someone who's neck-deep in Java projects (though maven
> exclusively, not gradle or sbt), let me see how I can help. I'm not sure if
> it's been reported, but I think there some similar issue with
> ErrorProne's output not being stable, we had to disable it for patch
> testing in HBase.
ErrorProne is an Hbase special/was never upstreamed. Not much to be
done from a Yetus perspective.
In the case of checkstyle, the thing that has me suspicion is that
gradle generated a different output format when I played with it back a few
months. The output is supposed to be build tool agnostic, which makes me think
that maven, ant, etc, are also different depending upon the version. So to
check this, it's pretty much:
1) run old version of mvn checkstyle outside of test-patch on horribly broken
code (e.g., Hadoop), catching the output
2) run new version of mvn checkstyle outside of test-patch on horribly broken
code (e.g., Hadoop), catching the output
If the output has changed, then checkstyle.sh is going to need some surgery and
we might need to make a call on the minimum version of checkstyle supported.
But be careful: I seem to recall that not only has the field separator
changed, but how columns were represented changed too.
> While we're on the subject, I'd love some help getting multijdk fixed; it's
> not reporting unit runs correctly, at least it wasn't while I was adding
> JDK11 support to HBase's build.
Maybe surefire's junit output is different now?