Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am diving into Scala and noticed sbt. I have been quite happy with Gradle in java/groovy projects, and I know there's a scala plugin for Gradle.
What could be good reasons to favour sbt over Gradle in a Scala project?
Note that one key difference between SBT and Gradle is its dependency management:
SBT: Ivy, with a a revision which can be given as a fixed one (1.5.2, for instance) or as latest (or dynamic) one.
See "Ivy Dependency"
That means the "-SNAPSHOT" mechanism support can be problematic, even though Mark Harrah details in this thread:
It is true the cache can get confused, but it is not true that Ivy doesn't understand resolving snapshots. Eugene explained this point in another thread, perhaps on the admin list. There is an issue with sbt's auto-update that was addressed in 0.12.
What Ivy does not support, as far as I know, is publishing snapshots in the manner Maven does. I believe I have stated this elsewhere, but if anyone wants to improve the situation, my opinion is that effort is best spent working with the Gradle team to reuse their dependency management code.
Gradle: This thread mentions (Peter Niederwieser):
Just to let you know, problems with Ivy and Maven snapshot dependencies were one of the reasons why Gradle eventually replaced Ivy with its own dependency management code. It was a big task, but brought us a lot of goodness.
This tweet mentions that the all situation could evolve in the future:
Mark said in the past that he was interested in using Gradle instead of Ivy for SBT.
(both tools can learn from each other)
For me the key features of SBT are:
Fast compilation (faster than fsc).
Continuous compilation/testing: the command ~test will recompile and test you project everytime you save a modification.
Cross-compilation and cross-publishing, across several scala versions.
Automatically retrieving dependencies with the correct scala version compatibility.
The downsides are:
A hieroglyphic syntax that tends to discourage new users (especially if they come from Java)
No easy way to define a "task": if you need a special build procedure, you will need to either find a plugin, or write a plugin yourself.
sbt is a Scala DSL and for it Scala is a first class citizen, so in principal it seems to be a good fit.
But sbt suffers from major incompatible changes between versions, which makes it hard to find the correct working plugin for a task and get it to work.
I personally gave up on sbt, since it was causing more problems than it solved. I actually switched to gradle.
Go figure.
I'm fairly new to gradle, and very new to sbt - what I really like about sbt so far is the interactive console. It allows me to use commands like 'inspect' to get a better idea of what's going on. AFAIK gradle does not provide something like this atm.
Sbt and gradle, both are based on statically typed languages....but sbt has few advantages:
better plugin support, specially autoplugins
task creation and dependency management between tasks
sbt specially suits scala projects in the sense that it supports incremental builds and most of the sbt itself is written in scala and sbt build definitions is written in scala
sbt has interative shell support with many useful built-in tasks
sbt default lifecycle is pretty useful and can get novice started with pretty less effort
Related
So Im learning Scala and using the Intellj IDE to make my projects with. When I click on New Project and then Scala I get the choice of
Scala
SBT
when i hoover the mouse over them I get additional info
Sample module with attached Scala SDK
SBT based Scala Project
Now I have played around with SBT before I downloaded Intellij and used it to compile and run some Scala code, so i kind of know what it is.
But I just don't know which one I should be choosing 1 or 2 and why someone would choose 1 over 2 or vise-versa?
Use SBT project . This will lead to Intellij doing the autobuild using SBT wityhout you having to rework the build each time.
The first time Intellij runs the sbt it will take some time to set itself up but eventually it will be far more rewarding.
Also as mentioned by Boris for portability you would want a standard build/compile tool.
I think there is not the solution to your problem. If you just want to try out Scala and the Scala SDK, the first choice is fine because you don't have any needs for an automated build. In my opinion is this your choice if you want to play around a bit without any overhead.
If you want to do a more real project I suggest to use sbt because it will build your project and manage your dependencies. This makes your project more flexible, easy to build for somebody else.
Currently all our project builds with Maven on Windows. We were not successful with making incrementally compiled code to work in run time (50% of the cases it was failing with some kind of error), so to benefit from warm compiler and (maybe?) properly working incremental compilation we think about moving to SBT. However currently I have only one sprint to work on it, and I'm afraid to put all the eggs in a single basket and try to migrate whole project in a sprint. I need to find a way to make this change gradual, so I could advance one module at a time. So here are the main questions:
How can I include SBT modules in Maven build (or maybe vise versa, having my "parent" in SBT, yet part of the modules still building with Maven)?
How can we still benefit from IDE support (currently IntelliJ 13), like updated indices on changes in pom / Build.scala, task & goals invocation and so on?
Any advises on subject are highly appreciated.
Eventually we did the switch and don't regret it. Writing SBT tasks is easier, because it's plain Scala. Incremental compilation works now (used to fail in Maven with java.lang.InternalError: Enclosing method not found when deployed to JBoss) and build time is significantly faster. Unfortunately we did not find a way to make a gradual switch, so we had to take the risk. Incremental compiled jars still didn't work, yet Typesafe are about to fix this issue in 2.11.6
I have recently completed the Scala course on Coursera, and since then I have been looking forward to getting my hands dirty with Scala again. I have written code for some years but I neither educated to be nor work as a programmer, so it took me a while to get a good opportunity but now that I have some time to invest and a good project to work on it's time...
Except I can't seem to get things set up properly, which I find really frustrating. I have OpenJDK 1.7.0_25 running on my Linux machine. I have downloaded and installed the Bundle Scala IDE build for Eclipse (just like we used in the course). And I got ScalaTest both as a jar file and the Eclipse plug-in.
I have a simple project (so far) and no matter what I do I can't seem to get my builds and tests in order. First off how exactly am I supposed to set up my project so that my classes and tests are actually run properly? All the assignments we got were projects that had the same structure, so do I have to have:
project
|--src
|--main
|--scala
|--test
|--scala
structure? If so why is it not the default way the project is setup when I create a new project? Do I create these folders manually, as packages or as source folders? The whole thing gets pretty murky..
I should mention that I tried to "Mavenize" the project using the contextual menu in Eclipse, added my ScalaTest dependency. The first thing that happens is that I get compile errors, at every point of dependency in my code. So clearly the library is not visible, in other words Maven does not seem to be doing much of management. I thought the whole point of Maven was to get and maintain dependencies as the project evolves. I concluded that I do not fully understand the way Maven works and thus I eventually gave up on Maven, once again, and went back to doing things manually.
Secondly, I can't seem to run my tests; the Run As... menu item does not include ScalaTest as it's mentioned in the documentation of ScalaTest Eclipse Plug-in. I have double checked that the plugin is installed. If I instead try to run using JUnitRunner then my tests are not recognized as valid tests. I have JUnit and ScalaTest on my build path, so it's got to be something else.
I suppose my overarching question is as follows:
given the Scala IDE build of Eclipse and ScalaTest, just exactly how am I supposed to set up my project (in Eclipse) so that I can just focus on writing my code and testing it, and hopefully not have any other headaches?
I work alone, and this project is not a product I need to deliver to some client. In other words I do not need to adhere to strict professionalism here. Honestly I just want to be able to code, get better acquainted with Scala and hopefully build a small data analysis tool that I will be using from time to time.
Thanks in advance!
Try using the sbt eclipse plugin:
https://github.com/typesafehub/sbteclipse
This is of course assumes that you use sbt as you build tool. If you don't at the moment you can find instructions on installation and usage here: http://www.scala-sbt.org/
Personally I've been using typesafe giter8 template (https://github.com/typesafehub/scala-sbt.g8) to setup my Scala projects, and then I use the sbt plugin mentioned above to generate eclipse project files.
Scala is somewhat Maven-based (sometimes implicitly), that's why you use that structure.
The easiest way I think is to create a simple Sbt/Maven POM and create the Eclipse project configurations (like with sbt eclipse). There you can set the dependencies (like the actual version of JUnit, Scalatest to use), so you can use the ScalaTest plugin easily.
In case of other issues, feel free to ask at the ScalaTest mailing list, Chee Seng and Bill Venners can help you a lot there.
The Scala IDE website has a full documentation on how to run unit testing frameworks with the IDE, have a look ! If you find missing elements, the bug tracker of the scala-IDE project is here.
I am trying to generate some boilerplate with SBT (tool which is totally new to me). I am using shapeless sbt files as my main reference for the task. I have seen that this project uses code generation from scratch, but my case is slightly different, since I would like to generate some classes from another ones. I pretend to use the new Scala 2.10.0-M4 reflection capabilities for doing so. What basic configuration is needed to have reflection available from a SBT build?
By now, the sbt is unable to find the scala.reflect.runtime.universe package, and I do not know if the problem comes either from the new Scala jar division or from a bad configuration. Besides, my sbt about says:
[info] This is sbt 0.13.0-20120530-052139
[info] The current project is {file:/home/jlg/sandbox/abc/}abc
[info] The current project is built against Scala 2.10.0-SNAPSHOT
[info]
[info] sbt, sbt plugins, and build definitions are using Scala 2.9.2
By the way, does anybody know other projects using SBT to generate source code?
Current SBT releases are based on Scala 2.9, and source code generation runs together with SBT with the same libraries. There are basically two choices:
be extremely bleeding-edge: get an SBT release running on Scala 2.10 (not even the 0.13 branch does), or waiting for it. The biggest problem is not just that you'd have to recompile SBT yourself, it's recompiling every single SBT plugin you'll need for Scala 2.10. In the long-term, this is maybe the best strategy to do what you ask, but it might be a lot of effort for now. However, beware that you cannot use reflection on your compiled code without evil tricks, since code generation is supposed to happen before compilation. If you need to do that, consider instead generating code at compile-time within the program using macros. This excludes SBT and is much more standard, but I'm not sure if you can generate complete classes in this release (this is I think planned for the future).
go with the old: stick with Scala 2.9 and use scalap's capabilities (ScalaSigParser) for compile-time reflection. The problem is that the API is different (not sure how deeply) and not really supported for public use, although various people have been using it for ages. For a project I'm running, a colleague implemented approach and I integrated it within SBT for my project (https://github.com/ps-mr/LinqOnSteroids/); on top of that, I use Scalate to write the templates to use for code generation, which is quite powerful.
See in particular build.sbt, which invokes
project/Generator.scala and project/src/main/scala/ivm/generation/ScalaSigHelpers.scala (some non-fully-generic wrappers for ScalaSigParser). Scalate Templates for generated code are in
src/main/resources, the most relevant here is src/main/resources/WrappedClassInlined.ssp.
Even more stuff is involved, I fear you'll pratically need a checkout and playing with it to see what it does exactly—but feel free to ask questions.
Please note that the code is protected by a BSD license, so you need to keep the original copyright if you copy the code.
Note: all the links (except the license) are to the current HEAD for stability, so that they won't disappear so easily even if the files are moved/removed in future versions.
If you're using 2.10.0-SNAPSHOT, then you should go for scala.reflect.runtime.universe. Take a look at http://dcsobral.blogspot.ch/2012/07/json-serialization-with-reflection-in.html for more information.
My goal is to reduce Scala compilation times. I'm using Intellij IDEA 10 with Scala 2.8.1-RC1.
I've read that using SBT will reduce compilation times because it is clever about re-building only the files/classes that have changed since the last build.
I understand that JRebel has a very similar purpose. Is there any point in using JRebel instead of, or in addition to, SBT?
They do different things. SBT has a pretty speedy continuous incremental build system. JRebel dynamically reloads classes into a running program as they are rebuilt. It's something like a Java debugger's ability to modify a running program but with far fewer annoying limitations. SBT and JRebel are complementary.
You might also say that SBT obviates Hudson or other CI tools. Or that it obviates the red squiggly lines your IDE generates when you enter code that won't compile. But those tools are still useful even with SBT, and SBT offers lots of great features beyond CI and hot deployment.
It does obviate Maven.
SBT overlaps with JRebel for me a bit - like when I use SBT to continuously compile and redeploy a web application to jetty (~prepare-webapp). That feels quite a lot like using JRebel to continuously push changes out to a Java application container.
It offers "poor mans continuous integration" with quick code change detection and testing: http://devblog.point2.com/2009/07/27/scala-continuous-testing-with-sbt/
In general, SBT is the make/ant/maven replacement you should use for Scala. I'm constantly impressed with how it streamlines development, and I miss it when I go back to Java/Maven (even with JRebel). You should use it regardless of what other tools and frameworks you find useful.
Hope that helps :)