.Net has F# though, which I adore to no end. Can even avoid MSBuild with FAKE.

But then FAKE is just like MAKE which is just like MSBuild or ANT.

IMHO FAKE syntax is not for me.

.NET has F#, nice. JVM has Scala, JRuby, Clojure, etc. But that's a matter of taste/opinions.

And Frege. Much closer to F# than Scala / JRuby / Clojure.

And there's Cake for C# peeps - http://cakebuild.net

Oh, God, thank you! I've been hunting and hunting for something to replace CruiseControl. I had no idea this existed. Is there an easy way to turn this into a CI?

You mean get it working with a CI server? If so, yes it can from what I've read.

I think it works with AppVeyor and Team City: http://cakebuild.net/dsl/build-system

Note: I've never used Cake myself, but have seen it recommended alongside Fake.

Can you/someone give a quick rundown of why maven is really so much better than everything else?

Maven manage your module/projects from building, dependency management, generating project website (if you want to), deals with packaging, and deployment (if you want to), and many more (via plugins).

Maven is essentially NuGet+MSBuild or Ant+Ivy or Bundler+Gem+Rake without having to manage build tasks manually.

Those tasks are: 1. Compile code 2. Compile test code 3. Run unit-test 4. Run integration-test (separately from unit-test) 5. Setup paths for running unit-test (say you want to use different config/resource files for your unit-test) 6. Package your artifacts _without_ the unit-test artifacts

Maven has these built-in and in a non-disruptive manner. Don't have unit-tests? Maven won't run anything for you.

You have unit-tests source code and assets that you don't want to be included in your final build? Maven will handle that out-of-the-box-no-config needed.

While people might prefer to use "one tool that does its jobs beautifully/correctly", the reality is that you need at least 2 things to build the project: tool to manage your dependency and tool to build+package your project.

It's the only build system I've ever seen that's truly declarative. You can't put random turing-complete computation in the middle of a maven project definition; you can only invoke well-defined plugins (if you want a custom build step, you package it up as a plugin - written in ordinary java, unit testable and all the rest of it).

The result is there are no "snowflake builds". One project tends to build exactly the same as any other; virtually every project uses the same source directories etc.. It makes it really easy to be productive straight away when switching projects. And the limited build steps mean the IDE integration can be very complete.

Maven love is far from universal:

http://kent.spillner.org/blog/work/2009/11/14/java-build-too...

Yeah and last time I used it at work (2012-2013) it didn't even support incremental builds. Even the company's best Java developers just accepted this as normal.

See https://cwiki.apache.org/confluence/display/MAVEN/Incrementa... for proof. That may have been implemented in the meantime but the fact is that maven had no support for incremental builds for at least 10 years (released in 2002). Amazing.

I think maven did not push incremental builds because there was not a big need.

Most people code Java in an IDE. Both Idea and Eclipse do incremental builds inside the IDE. So as you are coding, you are incremental building.

Every place I have used maven, maven was used for the build server and the final release. Spinning on a webpage changing some code? You are using your IDE for that.

(Now scala is a little bit different, so we have SBT with incremental support as a pretty ground level thing)

Adding to all the good points that others mentioned, this sort of consistency only grows in importance in large companies where developers support many different projects. It allows you to focus on the business problems rather than spend time getting used to dozens of variations in the build themselves.

We had this problem with Ant many years ago. Everyone did their builds differently and half of them were subtly broken.