Hacker News Reader

Comment by lmm | Hacker News Reader

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"

View on HN

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