Hacker News new | ask | show | jobs
by rdubz 3356 days 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.1...

and its parent POM:

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

Spark's POMs (e.g. 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) 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 :)

2 comments

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.
On the contrary, I believe the out-of-the-box experience is where SBT shines. Even for a relatively simple project with a few sub-modules, the amount of boilerplate is simply insane with Maven.
I just ran `cloc` on my own codebase:

~35 LOC per module for .sbt files plus classes in /project

300+ XML lines per module in Maven projects

And we do a lot more with SBT.