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