6 ms·

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 compil

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.

deleted 10y ago
[deleted]
lmm 10y ago
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"
- pfn 10y ago
  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.
  - harveywi 10y ago
    Unfortunately, we have things like this in the mix... libraryDependencies += "com.lihaoyi" %% "scalatags" % "0.4.3" libraryDependencies += "com.lihaoyi" %%% "scalatags" % "0.4.3"
    - virtualwhys 10y ago
      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...
      - lmm 10y ago
        A build definition format that allows arbitrary code anywhere is always going to have less-good IDE support than one based on declarative documents.
        kmiroslav 10y ago
        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.
        lmm 10y ago
        The IDE would need to run it to understand the build definition, which then gets into halting-problem issues.
- premium-concern 10y ago
  I'd just use ModuleID(organization = "com.foocorp", name = "foo", revision = "1.2")

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.

deleted 10y ago

[deleted]

lmm 10y ago

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"

pfn 10y ago
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.
- harveywi 10y ago
  Unfortunately, we have things like this in the mix... libraryDependencies += "com.lihaoyi" %% "scalatags" % "0.4.3" libraryDependencies += "com.lihaoyi" %%% "scalatags" % "0.4.3"
  - virtualwhys 10y ago
    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...
    - lmm 10y ago
      A build definition format that allows arbitrary code anywhere is always going to have less-good IDE support than one based on declarative documents.
      - kmiroslav 10y ago
        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.
        lmm 10y ago
        The IDE would need to run it to understand the build definition, which then gets into halting-problem issues.
premium-concern 10y ago
I'd just use ModuleID(organization = "com.foocorp", name = "foo", revision = "1.2")