Good news! I duplicated it.
Bad news! I’d classify this as primarily a bug in the accumulo build,
but Yetus should probably handle it better when it sees that the patch size is
significantly smaller than the calculated size. (An early bail out that
something is very very wrong.) Let’s get into the details!
Yetus, as you pointed out, does a build to see the before picture. It
uses mvn clean, git clean, etc, to wipe the directory. The patch gets applied
and uses the git commands again to figure out what the real line numbers are.
(The values in the patch file itself generally aren't trustworthy because of
drift between when the patch was generated and the current state of the source
tree. Those +/- line numbers when one applies a patch have to be taken into
consideration…)
Augh! I forgot we still did this :). It's likely a holdover from
old-days. Completely agree the generated docs should be under target/
I've been trying to rerun it myself, happy to see you beat me to the
punch. I appreciate you looking into it, Allen.
One other thing I noticed is that findbugs, checkstyle, mvn site, etc,
etc, run on *every* invocation. That’s either good or bad, depending upon how
much control one wants over the build. For Yetus, it definitely has a
significant run time cost.
A follow-on question I was going to ask you :).
It seems to me that the mvninstall "invocation" (sorry, still learning
terminology) should also include "-Dfindbugs.skip=true
-Dcheckstyle.skip=true". My understanding of Maven convention is that is
it expected that these sorts of checks would run as a part of `mvn
verify` (I forget the exact lifecycle phase they bind to, just that it's
included invoking something at-or-after verify). Would it make sense to
also add these arguments for the pre-patch and patch install?
