4 ms·

Totally agree on first point, especially since 0.13.5. Yeah I think native-packager is great [1]. I wish they didn't bork the template of the docs, it looks t

Totally agree on first point, especially since 0.13.5. Yeah I think native-packager is great [1]. I wish they didn't bork the template of the docs, it looks terrible. The content is better though for sure [2]. [1] https://github.com/sbt/sbt-native-packager https://github.com/sbt/sbt-native-packager [2] http://www.scala-sbt.org/0.13/docs/index.html http://www.scala-sbt.org/0.13/docs/index.html

saryant 12y ago
Yeah, of the things wrong with SBT, the template for the website was not something anyone needed to spend time on. And sbt-native-packager is definitely awesome. We have an SBT task that uses native packager to build a distributable for our Akka cluster and then build it into a Docker image, pushing it to our private repo on Docker Hub.
w4tson 12y ago
I've just spent the last couple of years investing my time in Gradle. I'm in a position where I've become productive with the tool. But as is the way of the freelance software guy (or gal) the decisions that influence the tech. stack are not in your control. So I'm being pushed to use the Play! Framework for micro services style arch. Which I'm happy enough about but afaik that means I'm tied into SBT. Could you guys give advice for smoothing the learning curve to Sbt? Any hints/time sucks/resources appreciated
- orrsella 12y ago
  Really just read the docs, they are very thorough. Most important thing to understand IMO is settings/tasks, their scoping, and runtime evaluation. You can check out this [1] template I made for play apps with multi-module config in SBT which could be relevant. [1] https://github.com/orrsella/play-template https://github.com/orrsella/play-template
- vorg 12y ago
  In http://forums.gradle.org/gradle/topics/revolutionary_new_gradle_features_on_the_2014_roadmap http://forums.gradle.org/gradle/topics/revolutionary_new_gra... , the Gradle founder writes "what is ultimately needed is a fundamental solution within Gradle that eliminates the overhead in the IDE-to-Gradle communication". That solution would be to enable any JVM language to be used with Gradle, not just Groovy. Then you wouldn't be tied to SBT as you then could use Scala to configure Gradle.

saryant 12y ago

Yeah, of the things wrong with SBT, the template for the website was not something anyone needed to spend time on. And sbt-native-packager is definitely awesome. We have an SBT task that uses native packager to build a distributable for our Akka cluster and then build it into a Docker image, pushing it to our private repo on Docker Hub.

w4tson 12y ago

I've just spent the last couple of years investing my time in Gradle. I'm in a position where I've become productive with the tool. But as is the way of the freelance software guy (or gal) the decisions that influence the tech. stack are not in your control. So I'm being pushed to use the Play! Framework for micro services style arch. Which I'm happy enough about but afaik that means I'm tied into SBT. Could you guys give advice for smoothing the learning curve to Sbt? Any hints/time sucks/resources appreciated

orrsella 12y ago
Really just read the docs, they are very thorough. Most important thing to understand IMO is settings/tasks, their scoping, and runtime evaluation. You can check out this [1] template I made for play apps with multi-module config in SBT which could be relevant. [1] https://github.com/orrsella/play-template https://github.com/orrsella/play-template
vorg 12y ago
In http://forums.gradle.org/gradle/topics/revolutionary_new_gradle_features_on_the_2014_roadmap http://forums.gradle.org/gradle/topics/revolutionary_new_gra... , the Gradle founder writes "what is ultimately needed is a fundamental solution within Gradle that eliminates the overhead in the IDE-to-Gradle communication". That solution would be to enable any JVM language to be used with Gradle, not just Groovy. Then you wouldn't be tied to SBT as you then could use Scala to configure Gradle.