6 ms·

> Will hard-core Linux users who used Java migrate when it makes sense? Probably only for mobile/desktop app but less likely for back-end/webservice/infrastruc

> Will hard-core Linux users who used Java migrate when it makes sense? Probably only for mobile/desktop app but less likely for back-end/webservice/infrastructure stuff. Take MSBuild. This is pretty much Ant. Sure, there's NuGet but Ant+Ivy or MSBuild+NuGet combo isn't anywhere close to Maven (despite the XML hate). Libraries, communities, tools, frameworks of .NET ecosystem is still behind Java. Unfortunately language features and syntatic sugar alone probably not enough to sway these users. Besides, Java and C# are very similar, technically there's less reward in learning a very similar language.

manigandham 11y ago
Can you/someone give a quick rundown of why maven is really so much better than everything else?
- edwinnathaniel 11y ago
  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.
- balefrost 11y ago
  Maven love is far from universal: http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html http://kent.spillner.org/blog/work/2009/11/14/java-build-too...
  - frankzinger 11y ago
    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/Incremental+Builds 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.
    - brianwawok 11y ago
      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)
- lmm 11y ago
  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.
- h_r 11y ago
  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.
snuxoll 11y ago
.Net has F# though, which I adore to no end. Can even avoid MSBuild with FAKE.
- edwinnathaniel 11y ago
  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.
  - zeckalpha 11y ago
    And Frege. Much closer to F# than Scala / JRuby / Clojure.
- wluu 11y ago
  And there's Cake for C# peeps - http://cakebuild.net http://cakebuild.net
  - xanadohnt 11y ago
    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?
    - wluu 11y ago
      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 http://cakebuild.net/dsl/build-system Note: I've never used Cake myself, but have seen it recommended alongside Fake.

manigandham 11y ago

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

edwinnathaniel 11y ago
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.
balefrost 11y ago
Maven love is far from universal: http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html http://kent.spillner.org/blog/work/2009/11/14/java-build-too...
- frankzinger 11y ago
  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/Incremental+Builds 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.
  - brianwawok 11y ago
    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)
lmm 11y ago
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.
h_r 11y ago
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.

snuxoll 11y ago

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

edwinnathaniel 11y ago
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.
- zeckalpha 11y ago
  And Frege. Much closer to F# than Scala / JRuby / Clojure.
wluu 11y ago
And there's Cake for C# peeps - http://cakebuild.net http://cakebuild.net
- xanadohnt 11y ago
  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?
  - wluu 11y ago
    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 http://cakebuild.net/dsl/build-system Note: I've never used Cake myself, but have seen it recommended alongside Fake.