In JVM world, the de factor equivalent to `go build` and `go test` are `mvn compile` and `mvn test`, which works 99% percent of the time.
Other build tools and plugins just compete/fill in for:
* improved build speed / test speed: using background daemon to reduce strtup speed, intelligent caching / task reordering to avoid redoing, etc..
* extra functionalities like code generation, publishing or deployments. As code generation is really big in JVM world, and there are many ways to deploy an application: jar + libs in a zip file, uber jars, container image, etc...
Curmudgeon here: this was true for a relatively brief period of time. Nowadays I'd say that gradle has (inexplicably to me) taken the lead - and everyone adds custom crap to their gradle build making them far less predictable than maven builds used to be.
I guess it's better than the nightmare over in the front-enders' world...
I rarely see Maven files in non-trivial projects that are anything but a confusing mess of XML.
Granted, the constrained abilities do tend to keep folks from writing one-off snowflake build customizations, which is nice. But it still leave a hell of a lot to be desired. It was however, leagues ahead of Ant, which wasn't a high bar.
I saw a lot of that too - I just see more and worse with gradle.
Maven gave us two things; good dependency management and convention driven builds (removing the horrible scripted build stuff in Ant).
Gradle from my point of view took the second one away again and it feels like it was just because people didn't like XML and couldn't be bothered to learn how Maven's build lifecycle actually worked!
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.
Other build tools and plugins just compete/fill in for:
* improved build speed / test speed: using background daemon to reduce strtup speed, intelligent caching / task reordering to avoid redoing, etc..
* extra functionalities like code generation, publishing or deployments. As code generation is really big in JVM world, and there are many ways to deploy an application: jar + libs in a zip file, uber jars, container image, etc...