My typical mvn session after a month of not touching maven:
% mvn
[ERROR] No goals have been specified for this build.
Uh.
% mvn build
[ERROR] Unknown lifecycle phase "build".
Uh, nope, that wasn't it....
% mvn compile
BUILD SUCCESS
Now trying to run the app... Error: app jar not found.
Reading the README.md. Aha! So I need to install it!
% mvn install
16:59:35,075 [INFO] Building <blahblahblah> [1/32]
...
16:59:38,483 [INFO] -------------------------------------------------------
16:59:38,483 [INFO] T E S T S
16:59:38,483 [INFO] -------------------------------------------------------
^C
// me searching on google how to not run tests
% mvn install -DskipTests=true
// now good...
Ok, let's run some tests. The FlakyTest broke again in CI. Let me run it locally:
% mvn test FlakyTest
17:02:19,481 [ERROR] Unknown lifecycle phase "FlakyTest".
Aaargh, ok, googling it again:
% mvn test -Dtest=FlakyTest
17:03:16,102 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.3.0:test (default-test) on project blah blah: No tests matching pattern "FlakyTest" were executed! (Set -Dsurefire.failIfNoSpecifiedTests=false to ignore this error.)
The original idea behind maven is nice.
But the defaults are so bad, that the whole experience of convention over configuration has been ruined.
Cargo and go build systems took the original maven philosophy and implemented them right, with good UX.
Gradle, SBT and friends took a step back to the times before maven, and went fully the Ant way, doubling down on "configuration over convention". Where "configuration" is actually "programming in a DSL on top of another language on top of Java".
I'm not trying to ignore your point, but FWIW the next line after the one you specified includes presumably what a normal person would want to see
[ERROR] No goals have been specified for this build. You must specify a valid lifecycle phase or a goal in the format <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>. Available lifecycle phases are: pre-clean, clean, post-clean, validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy, pre-site, site, post-site, site-deploy. -> [Help 1]
> [ERROR] No goals have been specified for this build.
> [ERROR] Unknown lifecycle phase "build".
And somehow missed that the error message also lists the valid lifecycle phases. (could have instead complained that it list all lifecycle phases which is a lot)
> // me searching on google how to not run tests
How do I know for other build tools how to skip tests? Skipping tests should not be necessary and is done to regularly. I would not consider a tool which immediately points out how to ignore those stupid tests as good UX.
When I want to run tests, I tell it to run the tests. When I want to install, I tell it to install. I don’t want it to run tests when I tell it to install. I don’t want tools who know better what I want to do than me.
Cargo and go build systems took the original maven philosophy and implemented them right, with good UX.
Gradle, SBT and friends took a step back to the times before maven, and went fully the Ant way, doubling down on "configuration over convention". Where "configuration" is actually "programming in a DSL on top of another language on top of Java".