> 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?

Reply via email to