On Wed, 14 Jul 2021 at 11:49, Gilles Sadowski <gillese...@gmail.com> wrote:
> Le mer. 14 juil. 2021 à 12:29, Alex Herbert <alex.d.herb...@gmail.com> a > écrit : > > > > The default goal specifies extra targets. Currently it is: > > > > clean verify apache-rat:check checkstyle:check pmd:check spotbugs:check > > javadoc:javadoc > > > > We could change the pom to bind these targets to a lifecycle phase [1] > such > > as 'verify'. > > > > Looking at the pom for CM the checkstyle plugin is configured to use the > > default goal of check. This binds to the 'verify' phase [2]. So the > > 'checkstyle:check' goal is redundant in the default goal. But apache-rat, > > spotbugs and pmd are not configured with execution bindings. > > > > However the site lifecycle is different to the default lifecycle used to > > create and install artifacts. The site lifecycle is to build the project > > documentation. It is not meant to run tests or build a jar package. > > Somewhere in commons-parent or the pom for the project the site goal runs > > tests due to a binding of a plugin for reporting. But it does not run the > > verify phase so will miss checkstyle. > > > > IIRC checkstyle was at one point run in the validate phase. This is early > > in the default lifecycle. It meant you could not run 'mvn test' without > > triggering checkstyle and so could not use System.out for dubugging. So > it > > was moved to verify. This was for Commons RNG but the configuration is > > similar across all projects descended from Math. > > > > Anyway the summary is that using 'mvn site' should not be expected to run > > all the validation checks on the code. It is to build documentation. > > Makes sense (and we were doing it wrong before). > > > If you > > want to check the code then use 'mvn verify'. > > OK. > So now are there any redundant actions in "verify" and "site"? > If you run both phases then maven will eliminate duplicates and only execute them once, i.e. it handles redundancy. Running tests in the site phase is useful as jacoco is also configured and the site report will generate coverage. Otherwise you would have to run 'mvn test site'. At present I do not know what is making this run the test phase so could not turn it off anyway. > > > The pom would have to be > > updated to bind the other plugins from the default goal to this phase > with > > executions. > > Is there something to be changed so [Math] is aligned with [RNG]? > [RNG] also does not have executions specified for spotbugs or pmd. apache-rat and checkstyle have the check goal bound to verify. So we update the plugin configuration to bind to verify and drop these from the default goal as additional targets. I will try this on RNG and check it works as expected. > > Thanks, > Gilles > > > > > Alex > > > > > > [1] > > > https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html > > [2] > https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html > > > > On Wed, 14 Jul 2021 at 10:29, Gilles Sadowski <gillese...@gmail.com> > wrote: > > > > > Le mer. 14 juil. 2021 à 11:16, sebb <seb...@gmail.com> a écrit : > > > > > > > > On Wed, 14 Jul 2021 at 10:03, Gilles Sadowski <gillese...@gmail.com> > > > wrote: > > > > > > > > > > Hi. > > > > > > > > > > Is it correct that > > > > > $ mvn site site:stage > > > > > and > > > > > $ mvn > > > > > behave differently (i.e. that the latter would not run > "CheckStyle" or > > > > > that it generates warnings instead of errors)? > > > > > > > > Depends on what the POM defines as the default target. > > > > > > Sure; but my question was whether the change of behaviour is > > > deemed better (in some way which I've missed). [IOW, why would > > > the "mvn site site:stage" build would be allowed to succeed, while > > > the default targets would make it fail?] > > > > > > > > > > > > In CM, we were used to detect all issues by running the former. > > > > > Is it expected that it's not the case anymore? > > > > > > > > > > > > > > > [...] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
