On Tue, 10 Oct 2023 at 13:05, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Mon, Oct 9, 2023 at 7:50 PM sebb <seb...@gmail.com> wrote: > > > > On Sun, 8 Oct 2023 at 18:52, Gary Gregory <garydgreg...@gmail.com> wrote: > > > > > > The default goal is always used by GitHub builds > > > > Are you sure about that? > > Yes, UNLESS, someone has decided to circumvent the default goal with a > custom goal list in a .github file.
I agree with you inasmuch as the default goal is used by Maven if no other goals are provided. But this is true of any Maven invocation; there is nothing special about the GitHub builds. Note however, that most of the Commons GH workflows don't use a bare 'mvn' command; they generally include additional options which are more suited to non-interactive, automated use. The problem here is that the options can easily obscure the fact that a goal has also been used. For example, which (if any) of the following override the default goal? mvn -V --batch-mode -Ddoclint=all --file pom.xml --no-transfer-progress mvn -V --file pom.xml --no-transfer-progress -Ddoclint=none -Darguments=-Xdoclint:none mvn -V --file pom.xml --no-transfer-progress -DtrimStackTrace=false '-Djdk.tls.client.protocols=TLSv1.2' mvn -V --batch-mode --no-transfer-progress install -D"maven.javadoc.skip=true" -D"org.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn" As an aside, I don't see the point of cluttering up the command line with '--file pom.xml', as that is the default. For options that are common for batch jobs I think the convention should be to use the short names to avoid clutter, eg. mvn -V -B -ntp instead of mvn -V --batch-mode --file pom.xml --no-transfer-progress > Gary > > > > > GH does not automatically know how to call Maven. > > We have to configure the calls in the workflows. > > Not all workflows rely on the default goal, though most do. > > > > > and it is nice to use as a dev before you push. > > > This lets us avoid putting some custom mvn call in the > > > GH build definition. We can also document to users that calling 'mvn' is a > > > all you need to do to validate a PR or push. > > > > But only if the defaultGoal is suitably configured. > > AFAICT that is not the case for all components at present. > > > > > Gary > > > > > > On Sun, Oct 8, 2023, 1:25 PM Phil Steitz <phil.ste...@gmail.com> wrote: > > > > > > > What exactly is the point of the default goal? I mean when is it > > > > expected > > > > to be used? Automations? Pipes of some kind? It’s not always > > > > executed, > > > > right? So if I say “clean” was the default, “mvn test” would not mean > > > > “mvn > > > > clean test”, right? > > > > > > > > Phil > > > > > > > > > On Oct 8, 2023, at 7:11 AM, sebb <seb...@gmail.com> wrote: > > > > > > > > > > There are currently lots of variations of the defaultGoal in > > > > > different > > > > > components. > > > > > > > > > > It may be sensible to establish a standard setting which components > > > > > should adopt (unless there is a good reason to do otherwise). > > > > > > > > > > If so, what should that be, and where does it get documented? > > > > > > > > > > Personally, I don't think install should ever be a default goal as it > > > > > changes the environment outside the component. > > > > > > > > > > Main goals seen: > > > > > clean > > > > > install > > > > > package > > > > > site > > > > > test > > > > > verify > > > > > > > > > > Other goals seen: > > > > > apache-rat:check > > > > > checkstyle:check > > > > > clirr:check > > > > > findbugs:check > > > > > japicmp:cmp > > > > > javadoc:javadoc > > > > > pmd:check > > > > > pmd:cpd-check > > > > > spotbugs:check > > > > > > > > > > Sebb > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
