3 ms·

I maintain 2 semi-big Play 2 web services (written in Java, not Scala) at work, and I just hate it. - SBT is super slow compared to maven - Compiling a pla

by Sphax 12y ago

I maintain 2 semi-big Play 2 web services (written in Java, not Scala) at work, and I just hate it. - SBT is super slow compared to maven - Compiling a play 2 app is slow - IDE integration is quite bad After a year, I would definitely not recommend Play 2, or SBT on a Java project. My choice when using Java today would be Dropwizard, although I haven't deployed anything in production using it, I tested it for a couple hours, and I think it's the best combination of libraries. One thing I definitely agree on, is to use Docker if possible. We use it for almost everything at work, and it improves our deployment speed, it gives us more flexibility and local/CI testing is now super easy. In case you deploy with Docker, using only environment variables for configuration is great, that way you can control the configuration directly via the docker command line. With Java a good library for this use case is Typesafe's config, which can automatically use environment variables.

danieldk 12y ago
In the previous project I worked in, we switched to Dropwizard for a lot of services that now run in production. We were already using Jersey, Guava, etc., but Dropwizard gives some nice extra glue and standardized our configuration and gave us a standardized way to instrument services (via metrics). It can really recommend it for RESTful services. Also, there is a nice Maven plugin that creates Ubuntu packages from Dropwizard projects: https://github.com/reines/dropwizard-debpkg-maven-plugin https://github.com/reines/dropwizard-debpkg-maven-plugin
jbooth 12y ago
SBT is probably the best example of the total immaturity of the Scala community in terms of real-world engineering. Hey, we're building for the JVM, we've got Maven, it's arguably the best solution in any language for a very difficult problem that has stopped entire language ecosystems in their tracks. Let's rewrite it, from scratch, using unproven concepts! And put 'simple' in the title! Afterwards, we'll call XML ugly and claim to be more 'functional', without even noticing that Maven's pom format is actually a nested s-expression structure that happens to use angle brackets.
- frowaway001 12y ago
  > we've got Maven, it's arguably the best solution in any language for a very difficult problem that has stopped entire language ecosystems in their tracks Wait wut? Are you drunk? :-) My experience is that SBT works great, while Maven tries to fight you at every step. SBT developers try to help you get you work done, while questions in the Maven community are usually answered with bullshit responses. Maven (like Eclipse) are a great example of what's wrong in the Java community.
  - jbooth 12y ago
    Not yet. You wanna show me the better solution than Maven? Something that manages multi-module projects, with various versions of dependencies, and packaging as war/jar/tgz/whatever? I've probably spent way more time cursing Maven than praising it, but that's the nature of a build/packaging/dependency tool, it's like a sysadmin, you're either not noticing it's there or cursing its parental lineage. What's SBT offer over maven? Lack of XML, with more trendy markup and new bugs? Like I said, immature.
    - frowaway001 12y ago
      > What's SBT offer over maven? Lack of XML, with more trendy markup and new bugs? Like I said, immature. Maybe you should do some research and figure out the answer for yourself, then you wouldn't jump to weird conclusions.
      - jbooth 12y ago
        If you're motivated to wade this far down the thread, but can't be bothered to explain one concrete benefit in one sentence, I've gotta assume it's pretty difficult to come up with one.
        frowaway001 12y ago
        It's pretty easy to come up with multiple ones. Just one, to not prevent you from doing your own research: Type-checked build definitions. I lost days to debugging broken Maven setups were some tags were misspelled or placed at the wrong position, and Maven just gave a shit about it. SBT immediately tells you what's the issue. Another one: It's completely painless to introduce new settings/keys/commands/tasks. Want to have a deployment step which moves some files to the right place after compilation? 3 lines of code. 3 lines, not a god damn Maven plugin.
ww520 12y ago
Play 2 really is a different framework than Play 1, which was what brought Play its fame. If you like Play 1, try the Ninja Framework. It has a cheesy name but it has the super fast development cycle that Play 1 used to have.
eeperson 12y ago
Your experience around the performance of SBT (and possibly, by extension, Play compilation) runs very much counter to my experience. I have found SBT to be much faster than Maven (thanks largely to the console). There may be something wrong with your project that is causing it to build so slowly. Are you seeing the compilation go very slowly or is it more issues with artifact resolution?
- Sphax 12y ago
  I've used SBT with and without Play 2, and it was a pain every time. On a standalone app, resolving dependencies was the big time consuming part, but compilation was slow too. I'm not talking like 3x slower than Maven, but it feels slower. We've had around 7 different projects using SBT at one point (most are now using Maven), and it was always that painful for us. We've mitigated the issue with resolution by using our Nexus server as a proxy, it helped a bit. But other than performance, over the year we've had a lot of random issues with caching. Things like a dependency not found in the ivy cache which required us to completely remove the cache for that artifact. A "test" run which found no tests to run, which required us to remove the target directory for some reason. Play 2 was just the icing on the cake: it has a lot of dependencies, and the routes in Scala takes what feels like forever to compile, not joking it feels like that single route file takes as much time to compile as 30 java files. I'm sure it's not the experience of everyone, seeing how many people enjoy using Play 2/SBT but for our organization it wasn't a good choice.
  - eeperson 12y ago
    Yeah, historically the artifact resolution has been kind of slow if you have several sub projects. However, there was just a new release of SBT that added a bunch of improvements for this[1]. [1] http://typesafe.com/blog/improved-dependency-management-with-sbt-0137 http://typesafe.com/blog/improved-dependency-management-with...

by Sphax 12y ago

danieldk 12y ago

In the previous project I worked in, we switched to Dropwizard for a lot of services that now run in production. We were already using Jersey, Guava, etc., but Dropwizard gives some nice extra glue and standardized our configuration and gave us a standardized way to instrument services (via metrics). It can really recommend it for RESTful services. Also, there is a nice Maven plugin that creates Ubuntu packages from Dropwizard projects: https://github.com/reines/dropwizard-debpkg-maven-plugin https://github.com/reines/dropwizard-debpkg-maven-plugin

jbooth 12y ago

SBT is probably the best example of the total immaturity of the Scala community in terms of real-world engineering. Hey, we're building for the JVM, we've got Maven, it's arguably the best solution in any language for a very difficult problem that has stopped entire language ecosystems in their tracks. Let's rewrite it, from scratch, using unproven concepts! And put 'simple' in the title! Afterwards, we'll call XML ugly and claim to be more 'functional', without even noticing that Maven's pom format is actually a nested s-expression structure that happens to use angle brackets.

frowaway001 12y ago
> we've got Maven, it's arguably the best solution in any language for a very difficult problem that has stopped entire language ecosystems in their tracks Wait wut? Are you drunk? :-) My experience is that SBT works great, while Maven tries to fight you at every step. SBT developers try to help you get you work done, while questions in the Maven community are usually answered with bullshit responses. Maven (like Eclipse) are a great example of what's wrong in the Java community.
- jbooth 12y ago
  Not yet. You wanna show me the better solution than Maven? Something that manages multi-module projects, with various versions of dependencies, and packaging as war/jar/tgz/whatever? I've probably spent way more time cursing Maven than praising it, but that's the nature of a build/packaging/dependency tool, it's like a sysadmin, you're either not noticing it's there or cursing its parental lineage. What's SBT offer over maven? Lack of XML, with more trendy markup and new bugs? Like I said, immature.
  - frowaway001 12y ago
    > What's SBT offer over maven? Lack of XML, with more trendy markup and new bugs? Like I said, immature. Maybe you should do some research and figure out the answer for yourself, then you wouldn't jump to weird conclusions.
    - jbooth 12y ago
      If you're motivated to wade this far down the thread, but can't be bothered to explain one concrete benefit in one sentence, I've gotta assume it's pretty difficult to come up with one.
      - frowaway001 12y ago
        It's pretty easy to come up with multiple ones. Just one, to not prevent you from doing your own research: Type-checked build definitions. I lost days to debugging broken Maven setups were some tags were misspelled or placed at the wrong position, and Maven just gave a shit about it. SBT immediately tells you what's the issue. Another one: It's completely painless to introduce new settings/keys/commands/tasks. Want to have a deployment step which moves some files to the right place after compilation? 3 lines of code. 3 lines, not a god damn Maven plugin.

ww520 12y ago

Play 2 really is a different framework than Play 1, which was what brought Play its fame. If you like Play 1, try the Ninja Framework. It has a cheesy name but it has the super fast development cycle that Play 1 used to have.

eeperson 12y ago

Your experience around the performance of SBT (and possibly, by extension, Play compilation) runs very much counter to my experience. I have found SBT to be much faster than Maven (thanks largely to the console). There may be something wrong with your project that is causing it to build so slowly. Are you seeing the compilation go very slowly or is it more issues with artifact resolution?

Sphax 12y ago
I've used SBT with and without Play 2, and it was a pain every time. On a standalone app, resolving dependencies was the big time consuming part, but compilation was slow too. I'm not talking like 3x slower than Maven, but it feels slower. We've had around 7 different projects using SBT at one point (most are now using Maven), and it was always that painful for us. We've mitigated the issue with resolution by using our Nexus server as a proxy, it helped a bit. But other than performance, over the year we've had a lot of random issues with caching. Things like a dependency not found in the ivy cache which required us to completely remove the cache for that artifact. A "test" run which found no tests to run, which required us to remove the target directory for some reason. Play 2 was just the icing on the cake: it has a lot of dependencies, and the routes in Scala takes what feels like forever to compile, not joking it feels like that single route file takes as much time to compile as 30 java files. I'm sure it's not the experience of everyone, seeing how many people enjoy using Play 2/SBT but for our organization it wasn't a good choice.
- eeperson 12y ago
  Yeah, historically the artifact resolution has been kind of slow if you have several sub projects. However, there was just a new release of SBT that added a bunch of improvements for this[1]. [1] http://typesafe.com/blog/improved-dependency-management-with-sbt-0137 http://typesafe.com/blog/improved-dependency-management-with...