Does the Scala version that sbt uses to run matters? Can it be changed?
p.s. I'm not asking about changing the Scala version against which your project is build.
In regards to the current version, looking at the changelogs for sbt, there are several updates that mention a new version of scala, the most recent of which is:
Scala version is bumped to 2.10.5. [...]
As for changing it, I don't believe that's possible, unless you want to build it (and any plugins you are using) from source yourself.
Does it really matter? Not really! Your project itself will use whatever version of scala you specify. There are only two ways I can see that it might matter - if you want to write a custom sbt plugin to us in your project that relies on a feature of a newer scala version, or if you want to use one of those features in your build build files (which are just scala scripts). However, I really can't imagine what you would need to do for a build that you couldn't accomplish with the features of 2.10.x.
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.
scala-2.11 folder appeared after recent update of IDEA and Scala plugin.
What should it be used for?
Usually such directories are used for binary version-dependent code. For example, macros in 2.10 are not source-compatible with macros in 2.11, so if you're building your project for different binary versions and you're using macros, it makes sense to put code which is only valid for the specific version in different source roots. SBT then will use the appropriate directory when compiling for 2.10 or 2.11.
If you're using SBT, though, you would need to set such thing up manually in the build definition. If you're not using SBT, then probably IDEA plugin was updated to handle such things by itself.
I have a Scala Play project and currently I show the current application version at some location in my main template. The version I can easily define in the conf/messages file. However, since I have an automated build for creating releases, the release iterations will update the build.sbt increasing the version according to the release there e.g. version := "1.0.6-SNAPSHOT"
I could use the same mechanics during the release to update my conf/messages file as well but instead I would prefer to have my conf/messages file including the version information from build.sbt e.g. alla application.version=${sbt.application.version}.
How can I accomplish this? is it possible at all?
UPDATE: it is worth mentioning that in Maven these build settings become Java system properties and can be easily used.
You can use sbt-buildinfo plugin to generate a Scala source based on the build.sbt.
The plugin generates a BuildInfo object, which contains information you can then use to display the application version.
Otherwise I don't think you can access sbt information from your configuration.
You can use the xsbt-filter plugin to achieve this. It basically works like Maven's resource filtering mechanism, and exposes the project's name, version, etc. by default. You can further configure it to expose other properties.
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.
The question says it all. I couldn't find an example on the web how to use the Scaladoc 2, especially on a Maven Project.
I'm using Maven, Scala 2.8 and some Java classes, and the Maven Scala Plugin to build the project.
But as it seems i cannot use the Maven Scala Plugin (where i could run mvn scala:doc) to create the docs because it uses VScaladoc - which has an issue on Scala 2.8/Scaladoc 2, resulting in an java.lang.reflect.InvocationTargetException
How can i build the Scaladoc for my project?
We're working on a fix, however I know DavidB and I are very short on free time, so patches are welcome! ;)
My guess (without looking into it) is that we don't have special handling for scaladoc vs. scaladoc2. The maven-scala-plugin attempts to handle Scala versions 2.6 (and less) -> 2.8 which is a pretty broad range. I'm guessing the special handling for 2.8+ versions is slightly off..
Since version 2.14.2 of maven-scala-plugin, the plugin use Scaladoc2 for project based on scala 2.8+