4 ms·

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

by dikei 2y ago

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...

dcminter 2y ago
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...
- switchbak 2y ago
  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.
  - dcminter 2y ago
    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! Like I say, I'm a curmudgeon...
pkolaczk 2y ago
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".
- mdaniel 2y ago
  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] I am open to the fact that maybe catastrophically old versions of Maven did not include that help text, but certainly since 3.0 from 14 years ago https://github.com/apache/maven/blob/maven-3.0/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleStarter.java#L104-L107 https://github.com/apache/maven/blob/maven-3.0/maven-core/sr...

by dikei 2y ago

dcminter 2y ago

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...

switchbak 2y ago
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.
- dcminter 2y ago
  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! Like I say, I'm a curmudgeon...

pkolaczk 2y ago

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".

mdaniel 2y ago
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] I am open to the fact that maybe catastrophically old versions of Maven did not include that help text, but certainly since 3.0 from 14 years ago https://github.com/apache/maven/blob/maven-3.0/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleStarter.java#L104-L107 https://github.com/apache/maven/blob/maven-3.0/maven-core/sr...