> On Dec 14, 2015, at 8:18 PM, Allen Wittenauer <[email protected]> wrote:
>
>
>> On Dec 14, 2015, at 7:12 PM, Josh Elser <[email protected]> wrote:
>>
>> Hi,
>>
>> I've been playing around with yetus-0.1.0 RC1 on Accumulo (Maven-based Java
>> project). I started doing something like the following:
>>
>> `cd accumulo.git; test-patch test-patch --jenkins --basedir=.
>> --project=Accumulo --plugins='all' ~/ACCUMULO-XXXX.patch`
>>
>> This was going great, saw lots of plugins running. After my patch was
>> applied, I noticed it that I stopped seeing output and CPU usage went way
>> down. Best as I understand it: Yetus (with things inbetween these steps)
>> built the Javadocs, applied the patch, and then calculated the diff of the
>> patch. This ended up creating +500MB files (when I stopped it) because of
>> the generated Javadocs being included in the diff calculation.
>>
>> I'd like to figure out what went wrong (if it's a bug or user-error) and how
>> to look into this further. Any suggestions?
>
> That is… interesting. Is there a personality to go with the project or
> just using raw settings as on the command line?
>
> I want to see if I can duplicate it.
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…)
This is where the problems start. The javadoc settings in the pom.xml
for Accumulo are configured to write to the ‘docs’ directory (e.g., building
the javadoc in the core directory generates core/docs/apidocs/blah.html) . But
this directory is not in the .gitignore. So when Yetus generates a new diff
with new line numbers based upon ‘git diff’… the results, as one can guess, are
not pretty:
$ wc -l patch gitdiff*
357 patch
247467 gitdiffcontent.txt
247467 gitdifflines.txt
Clearly wrong! That maven clean? Yeah, maven doesn’t know about this
directory either so it happily sticks around.
There are two potential ways to deal with this:
1) Move the docs generation to actually happen in the target/
directory. This is sort of the ‘maven’ way of doing things.
2) Add docs to the .gitignore. But this would have to be done
explicitly on a per directory basis since there is a real docs/ directory that
probably shouldn’t get ignored. ;)
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.
