Hacker News Reader

Comment by heartsucker | Hacker News Reader

Maven is an archaic, verbose nightmare compared to SBT. SBT can be annoyingly esoteric at times, but even for the simplest thing like "add these JARs and compile," SBT wins over Maven, no question.

View on HN

Not true. Maven may be verbose, but

    <groupId>com.foocorp</groupId>
    <artifactId>foo</artifactId>
    <version>1.2</version>

is far less archaic and more understandable than

    "com.foocorp" % "foo" % "1.2"

actually, the latter is far more readable without markup making my eyes bleed.

I generally prefer gradle's method of 'com.foocorp:foo:1.2' but that isn't acceptable statically. scala string interpolators could make it a thing, though.

Unfortunately, we have things like this in the mix...

  libraryDependencies += "com.lihaoyi" %% "scalatags" % "0.4.3"

  libraryDependencies += "com.lihaoyi" %%% "scalatags" % "0.4.3"

To be fair you'd only be using one or the other, `%%` for jvm-only, and `%%%` for cross platform jvm/js builds.

Far and away the biggest blocker to learning sbt is the shaky IDE support for the build project. Apparently that's coming up next in 1.0; will be nice to click through to source from sbt build files and instantly grok what X symbol means. Have wasted a lot of time over the years slogging through documentation...

A build definition format that allows arbitrary code anywhere is always going to have less-good IDE support than one based on declarative documents.

I don't see why, as long as the IDE sees the build file as a genuine source file for the language it's written in.

The IDE would need to run it to understand the build definition, which then gets into halting-problem issues.

I'd just use

  ModuleID(organization = "com.foocorp", name = "foo", revision = "1.2")

Reply on news.ycombinator.com