6 ms·

Just use Maven. It will be the lowest maintenance cost over time for your project. Nothing else matters, it's a frickin build system -- get it working and mov

by jbooth 10y ago

Just use Maven. It will be the lowest maintenance cost over time for your project. Nothing else matters, it's a frickin build system -- get it working and move on.

heartsucker 10y ago
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")
paulddraper 10y ago
I replaced a 500 line buggy maven nightmare with a 50 line SBT file that caches build targets. I won't go back.
- lmm 10y ago
  What was the functionality? If you stick to defining dependencies maven works perfectly. If you encapsulate whatever other crap you want to do as proper maven plugins maven works perfectly. It's the people who decide they absolutely need to output to a different folder on Tuesdays but can't be bothered to write a proper tested plugin for doing that who get themselves in trouble.
  - paulddraper 10y ago
    It was an Atlassian plugin, written in Scala. I also wanted to download the JS Closure Library and minify JS with the Closure Compiler. Your comment is accurate. If you want to do a very specific set of things, Maven works fine. If you want anything outside that, it gets much harder.
pyrophane 10y ago
I disagree. I migrated a multi-project build from Maven to SBT. From thousands of lines of XML to 50 or less in SBT. So much redundancy was removed, and the project is much easier to maintain now because of it. SBT has a learning curve, yes, but once you get there I believe the maintenance cost is actually lower than with Maven, at least for more complicated projects.
- lmm 10y ago
  Any rewrite simplifies things. What redundancy did you have in Maven that you couldn't remove? You know about parent poms and profiles, right?
- agentgt 10y ago
  I completely disagree that SBT or any non declarative build system is that much superior long term over Maven. Maven is not a really like any of the other build systems. I would say most build systems are glorified Make. Maven is not. SBT, Gradle, and even old school Ant seem far less verbose than Maven but Maven really shines when you have hundreds of projects in an organization. You can get extreme consistency. You don't have to have everything checked in one gigantic source tree which makes open sourcing projects subsets of your code base easier. Yeah Gradle and SBT can sort of do this but not nearly as decoupled as Maven does it (generally with Gradle and SBT you have to do some path magic). Just about every PL and editor can readily edit Maven pom files. That means with out loosing comments or spaces you can have scripts go and rewrite hundreds of pom files or even just do a sanity check to make sure that they are consistent. This is the complete opposite with build systems where basically the build system is turing complete scripting language. Projects have major drift and you loose lots of consistency.
  - premium-concern 10y ago
    > That means with out loosing comments or spaces you can have scripts go and rewrite hundreds of pom files or even just do a sanity check to make sure that they are consistent. I'd rather just change a single file instead.
  - jbooth 10y ago

by jbooth 10y ago

Just use Maven. It will be the lowest maintenance cost over time for your project. Nothing else matters, it's a frickin build system -- get it working and move on.

heartsucker 10y ago

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")

paulddraper 10y ago

I replaced a 500 line buggy maven nightmare with a 50 line SBT file that caches build targets. I won't go back.

lmm 10y ago
What was the functionality? If you stick to defining dependencies maven works perfectly. If you encapsulate whatever other crap you want to do as proper maven plugins maven works perfectly. It's the people who decide they absolutely need to output to a different folder on Tuesdays but can't be bothered to write a proper tested plugin for doing that who get themselves in trouble.
- paulddraper 10y ago
  It was an Atlassian plugin, written in Scala. I also wanted to download the JS Closure Library and minify JS with the Closure Compiler. Your comment is accurate. If you want to do a very specific set of things, Maven works fine. If you want anything outside that, it gets much harder.

pyrophane 10y ago

I disagree. I migrated a multi-project build from Maven to SBT. From thousands of lines of XML to 50 or less in SBT. So much redundancy was removed, and the project is much easier to maintain now because of it. SBT has a learning curve, yes, but once you get there I believe the maintenance cost is actually lower than with Maven, at least for more complicated projects.

lmm 10y ago
Any rewrite simplifies things. What redundancy did you have in Maven that you couldn't remove? You know about parent poms and profiles, right?
agentgt 10y ago
I completely disagree that SBT or any non declarative build system is that much superior long term over Maven. Maven is not a really like any of the other build systems. I would say most build systems are glorified Make. Maven is not. SBT, Gradle, and even old school Ant seem far less verbose than Maven but Maven really shines when you have hundreds of projects in an organization. You can get extreme consistency. You don't have to have everything checked in one gigantic source tree which makes open sourcing projects subsets of your code base easier. Yeah Gradle and SBT can sort of do this but not nearly as decoupled as Maven does it (generally with Gradle and SBT you have to do some path magic). Just about every PL and editor can readily edit Maven pom files. That means with out loosing comments or spaces you can have scripts go and rewrite hundreds of pom files or even just do a sanity check to make sure that they are consistent. This is the complete opposite with build systems where basically the build system is turing complete scripting language. Projects have major drift and you loose lots of consistency.
- premium-concern 10y ago
  > That means with out loosing comments or spaces you can have scripts go and rewrite hundreds of pom files or even just do a sanity check to make sure that they are consistent. I'd rather just change a single file instead.
- jbooth 10y ago