On 8/3/18 11:33 AM, Allen Wittenauer wrote:
On Aug 2, 2018, at 12:55 PM, Josh Elser <[email protected]> wrote: A related point is that Ratis' personality just enqueues all modules, not the ones modified. I think that's why compile and unit end up pulling from the reactor instead of the installed copy.For a precommit run, the mvn commands are generally, by default: Un-patched: mvn exec mvn install from root <— shaded jar should be in the repo mvn compile in impacted modules <— shaded jar rebuilt in the target dirs mvn test-compile in impacted modules <— shaded jar rebuilt in the target dirs (Source tree is cleaned, via mvn and via git) Patched: mvn install in impacted modules <— shaded jar should be in the repo and in the target dirs mvn compile in impacted modules <— shaded jar rebuilt in the target dirs mvn test-compile in impacted modules <— shaded jar rebuilt in the target dirs impacted modules = root, based upon what you said. What’s interesting is that if I don’t do a clean between runs, mvn throws a compilation error while building the shaded jar. That would definitely cause Yetus to throw up. I take the stance that a clean shouldn’t be required and if it is, then the pom is responsible for doing it. This is looking less like a yetus problem and more like a maven build problem.
Yeah, the repeatability/stability of the Ratis build has been dodgy for me too. I _think_ the changes that I've made will help with this.
FWIW, rebinding maven-jar-plugin and telling maven-shade-plugin to both run at process-classes have my normal Maven "workflow" functioning and PreCommit (as-is) happy.
Thanks for your input, Allen.
