3 ms·

Just a note to people who are encountering this for the first time: adopting SBT, deciding it was a mistake, and going back to Maven is also a common narrative.

by evdev 9y ago

Just a note to people who are encountering this for the first time: adopting SBT, deciding it was a mistake, and going back to Maven is also a common narrative. "Build/Package/Release logic is complicated, and deserves sophisticated tools and abstractions just as much as the code it builds." This seems correct until you realize that the #1 priority for your build system is to not be spending time screwing around with your build system. The benefits of using Maven to stay with the herd ends up dominating any benefits power you get to come up with clever build mechanisms. Then, yes, maybe you have an ugly shell script you have to run in your CI--but for all the crappiness of that, it's still composed on top of the thing that you basically never touch. I've heard first hand from one big marquee Scala company (you could get it in a couple guesses) that this was basically why they were going to move away from SBT. That was years ago, so do with that what you will.

rdubz 9y ago
Post author here, thanks for your perspective. The "stay with the herd" argument is fair… if you're using/aping projects that have working Maven builds, it might be easier to mimic those than try to use a totally different tool; in fact, this is how my coworkers and I ended up starting on Maven: we effectively inherited the decision from Spark and ADAM. "The herd" is also great for larger tooling/plugin support, but IME Maven folks more often than not think that SBT is less at parity than it is. A related thing you called out is the "years ago" bit; a lot of people I talked to in the course of writing this had a bad experience with SBT N years ago (including myself!), so I think there's probably been a lot of improvement in SBT-land in the last few years, based on my finding it to be much more attractive now than it was last time I looked. Finally, "spending time screwing around with your build system" is not unique to SBT :) in fact, that's partly why I became fed up with Maven ("I can enable these properties with profile A, and these other properties with profile B, now, is there one switch that can turn on both these profiles, which I frequently want to do?" comes to mind). Anyway, we can ofc disagree about which tool to use for a given situation, I just wanted to express that I wish someone had put me on SBT sooner; good to know that others have had the opposite experience!
neeleshs 9y ago
Agree with this. Build tools should remove complexity, not add it. We tried adopting sbt and we found its way too complex and switched back to maven.
- rdubz 9y ago
  There may be some subjectivity around what constitutes added/removed complexity. The ability to factor out repeated logic and configuration in SBT, by dint of using Scala instead of XML, removes a lot of complexity. Of course, arbitrary Scala can get more complex than arbitrary XML. As some points of reference, not saying these clearly argue for one side or the other: Here is the Maven POM for ADAM's core module: https://github.com/bigdatagenomics/adam/blob/adam-parent_2.11-0.22.0/adam-core/pom.xml https://github.com/bigdatagenomics/adam/blob/adam-parent_2.1... and its parent POM: https://github.com/bigdatagenomics/adam/blob/adam-parent_2.11-0.22.0/pom.xml https://github.com/bigdatagenomics/adam/blob/adam-parent_2.1... For comparison, build.sbt from my fork of ADAM: https://github.com/hammerlab/adam/blob/e4bee3227b5979e65a73d7c2051518640545dc36/build.sbt https://github.com/hammerlab/adam/blob/e4bee3227b5979e65a73d... And a plugin that it inherits that factors out a lot of functionality I reuse across projects: https://github.com/hammerlab/sbt-parent/blob/1.7.5/src/main/scala/org/hammerlab/sbt/ParentPlugin.scala https://github.com/hammerlab/sbt-parent/blob/1.7.5/src/main/... Spark's POMs (e.g. https://github.com/apache/spark/blob/v2.1.0/pom.xml https://github.com/apache/spark/blob/v2.1.0/pom.xml) vs. SBT project folder (https://github.com/apache/spark/tree/v2.1.0/project https://github.com/apache/spark/tree/v2.1.0/project) are another point of comparison. It's not hard for me to imagine how someone used to staring at one or the other of these kinds of configs, maybe for years, would feel that it made more sense than the other, but having spent some significant time with both, I think the points about having the option to express more sophisticated logic – that SBT provides – are pretty important, and the lessons extrapolate-able beyond building Scala projects :)
  - neeleshs 9y ago
    Indeed, sbt has its advantages. We found it it too complex for our use cases where maven provided an out-of-the-box build process, and sbt did not.

by evdev 9y ago

rdubz 9y ago

Post author here, thanks for your perspective. The "stay with the herd" argument is fair… if you're using/aping projects that have working Maven builds, it might be easier to mimic those than try to use a totally different tool; in fact, this is how my coworkers and I ended up starting on Maven: we effectively inherited the decision from Spark and ADAM. "The herd" is also great for larger tooling/plugin support, but IME Maven folks more often than not think that SBT is less at parity than it is. A related thing you called out is the "years ago" bit; a lot of people I talked to in the course of writing this had a bad experience with SBT N years ago (including myself!), so I think there's probably been a lot of improvement in SBT-land in the last few years, based on my finding it to be much more attractive now than it was last time I looked. Finally, "spending time screwing around with your build system" is not unique to SBT :) in fact, that's partly why I became fed up with Maven ("I can enable these properties with profile A, and these other properties with profile B, now, is there one switch that can turn on both these profiles, which I frequently want to do?" comes to mind). Anyway, we can ofc disagree about which tool to use for a given situation, I just wanted to express that I wish someone had put me on SBT sooner; good to know that others have had the opposite experience!

neeleshs 9y ago

Agree with this. Build tools should remove complexity, not add it. We tried adopting sbt and we found its way too complex and switched back to maven.

rdubz 9y ago
There may be some subjectivity around what constitutes added/removed complexity. The ability to factor out repeated logic and configuration in SBT, by dint of using Scala instead of XML, removes a lot of complexity. Of course, arbitrary Scala can get more complex than arbitrary XML. As some points of reference, not saying these clearly argue for one side or the other: Here is the Maven POM for ADAM's core module: https://github.com/bigdatagenomics/adam/blob/adam-parent_2.11-0.22.0/adam-core/pom.xml https://github.com/bigdatagenomics/adam/blob/adam-parent_2.1... and its parent POM: https://github.com/bigdatagenomics/adam/blob/adam-parent_2.11-0.22.0/pom.xml https://github.com/bigdatagenomics/adam/blob/adam-parent_2.1... For comparison, build.sbt from my fork of ADAM: https://github.com/hammerlab/adam/blob/e4bee3227b5979e65a73d7c2051518640545dc36/build.sbt https://github.com/hammerlab/adam/blob/e4bee3227b5979e65a73d... And a plugin that it inherits that factors out a lot of functionality I reuse across projects: https://github.com/hammerlab/sbt-parent/blob/1.7.5/src/main/scala/org/hammerlab/sbt/ParentPlugin.scala https://github.com/hammerlab/sbt-parent/blob/1.7.5/src/main/... Spark's POMs (e.g. https://github.com/apache/spark/blob/v2.1.0/pom.xml https://github.com/apache/spark/blob/v2.1.0/pom.xml) vs. SBT project folder (https://github.com/apache/spark/tree/v2.1.0/project https://github.com/apache/spark/tree/v2.1.0/project) are another point of comparison. It's not hard for me to imagine how someone used to staring at one or the other of these kinds of configs, maybe for years, would feel that it made more sense than the other, but having spent some significant time with both, I think the points about having the option to express more sophisticated logic – that SBT provides – are pretty important, and the lessons extrapolate-able beyond building Scala projects :)
- neeleshs 9y ago
  Indeed, sbt has its advantages. We found it it too complex for our use cases where maven provided an out-of-the-box build process, and sbt did not.