For JENKINS-51247 I am trying to use a variant of the tip shown here: using flatten-maven-plugin with a generated POM file in the target directory. This works fine in almost all cases, since the plugin calls MavenProject.setPomFile, which leaves the basedir untouched.
Unfortunately it fails for mojos which rely on the basedir that are run inside a forked execution, as I found when accidentally using source:jar when source:jar-no-fork was what I wanted. (Ditto when using findbugs:check.) This seems to be because deepCopy still calls setFile, so the basedir of a cloned project is not the same as the original—it is always the parent directory of the POM file.
Fixing this should be trivial
but I am unsure what the best approach is to validate the fix. A unit test in MavenProjectTest? An IT which calls flatten-maven-plugin, source:jar, and some other mojo TBD which is sensitive to project basedir? Both?