> On Jan 10, 2016, at 8:18 PM, Josh Elser <[email protected]> wrote:
> Assuming I'm not just wrong, any direction on where to start looking for
> this? I have a general idea of how I think the functionality would fit in,
> but I'm not sure where to start looking in the code. Maybe the
> maven_modules_worker function in maven.sh? (Also, have I missed any docs that
> might have already covered this?)
if integration tests are expected to provide some sort of test output
to be analyzed similar to the unit tests, then I’d probably start with the unit
test code and go from there. While this is a more difficult path, the benefit
is that you’ll likely end up with automatic test format support.
> On Jan 11, 2016, at 9:20 AM, Sean Busbey <[email protected]> wrote:
>
>
> https://github.com/apache/yetus/blob/master/precommit/test-patch.d/checkstyle.sh#L164
>
> https://github.com/apache/yetus/blob/master/precommit/test-patch.d/findbugs.sh#L100
>
> They take different approaches, with findbugs using
> maven_modules_worker. It looks much simpler to base your test on the
> findbugs plugin, IMHO.
Using modules_workers is *definitely* the way to go. I think at this
point all of the build tool specific plug-ins except for checkstyle use it.
There was a reason why I couldn’t do that with checkstyle, but I can’t remember
what it was now. It might have been because ant required the console output
setting, but we didn’t have a way to do that at the time. (We do now and this
could should probably get cleaned up to use the standard bits.)