3 ms·

I disagree. I migrated a multi-project build from Maven to SBT. From thousands of lines of XML to 50 or less in SBT. So much redundancy was removed, and the pro

I disagree. I migrated a multi-project build from Maven to SBT. From thousands of lines of XML to 50 or less in SBT. So much redundancy was removed, and the project is much easier to maintain now because of it. SBT has a learning curve, yes, but once you get there I believe the maintenance cost is actually lower than with Maven, at least for more complicated projects.

lmm 10y ago
Any rewrite simplifies things. What redundancy did you have in Maven that you couldn't remove? You know about parent poms and profiles, right?
agentgt 10y ago
I completely disagree that SBT or any non declarative build system is that much superior long term over Maven. Maven is not a really like any of the other build systems. I would say most build systems are glorified Make. Maven is not. SBT, Gradle, and even old school Ant seem far less verbose than Maven but Maven really shines when you have hundreds of projects in an organization. You can get extreme consistency. You don't have to have everything checked in one gigantic source tree which makes open sourcing projects subsets of your code base easier. Yeah Gradle and SBT can sort of do this but not nearly as decoupled as Maven does it (generally with Gradle and SBT you have to do some path magic). Just about every PL and editor can readily edit Maven pom files. That means with out loosing comments or spaces you can have scripts go and rewrite hundreds of pom files or even just do a sanity check to make sure that they are consistent. This is the complete opposite with build systems where basically the build system is turing complete scripting language. Projects have major drift and you loose lots of consistency.
- premium-concern 10y ago
  > That means with out loosing comments or spaces you can have scripts go and rewrite hundreds of pom files or even just do a sanity check to make sure that they are consistent. I'd rather just change a single file instead.
- jbooth 10y ago
  Yeah, the hilarious part of scala hyperpartisans (and i like scala) insisting that SBT is great is when you point out that Maven is declarative and SBT is imperative.. in other words the exact opposite of scala dogma. It's a good way to differentiate football-team partisanship from actual principles (not that any principle applies 100% of the time).
- vorg 10y ago
  > build systems where basically the build system is turing complete scripting language Not only that, but virtually no-one uses this Turing-Complete facility. In Gradle at least, I never see if- and for-statements. By using dynamically-typed Groovy in Gradle, you not only lose the ability for massive rewrites, but often also don't get any of the TC benefits. Perhaps it's different using statically-typed Scala in SBT, or Kotlin in Gradle 3.

lmm 10y ago

Any rewrite simplifies things. What redundancy did you have in Maven that you couldn't remove? You know about parent poms and profiles, right?

agentgt 10y ago

I completely disagree that SBT or any non declarative build system is that much superior long term over Maven. Maven is not a really like any of the other build systems. I would say most build systems are glorified Make. Maven is not. SBT, Gradle, and even old school Ant seem far less verbose than Maven but Maven really shines when you have hundreds of projects in an organization. You can get extreme consistency. You don't have to have everything checked in one gigantic source tree which makes open sourcing projects subsets of your code base easier. Yeah Gradle and SBT can sort of do this but not nearly as decoupled as Maven does it (generally with Gradle and SBT you have to do some path magic). Just about every PL and editor can readily edit Maven pom files. That means with out loosing comments or spaces you can have scripts go and rewrite hundreds of pom files or even just do a sanity check to make sure that they are consistent. This is the complete opposite with build systems where basically the build system is turing complete scripting language. Projects have major drift and you loose lots of consistency.

premium-concern 10y ago
> That means with out loosing comments or spaces you can have scripts go and rewrite hundreds of pom files or even just do a sanity check to make sure that they are consistent. I'd rather just change a single file instead.
jbooth 10y ago
Yeah, the hilarious part of scala hyperpartisans (and i like scala) insisting that SBT is great is when you point out that Maven is declarative and SBT is imperative.. in other words the exact opposite of scala dogma. It's a good way to differentiate football-team partisanship from actual principles (not that any principle applies 100% of the time).
vorg 10y ago
> build systems where basically the build system is turing complete scripting language Not only that, but virtually no-one uses this Turing-Complete facility. In Gradle at least, I never see if- and for-statements. By using dynamically-typed Groovy in Gradle, you not only lose the ability for massive rewrites, but often also don't get any of the TC benefits. Perhaps it's different using statically-typed Scala in SBT, or Kotlin in Gradle 3.