As of Play 2.3, Play is added as an SBT Plugin as follows in my Build.scala as follows:
Project("root", file(".")).enablePlugins(play.PlayScala)
Also have a look at the documentation.
I need a specific dependeny updated, namely Fluentlenium (Play 2.3.9 still uses 0.9.3):
"org.fluentlenium" % "fluentlenium-core" % "0.10.3"
How can I replace the old version and replace it with a newer one? Simply adding the library to the libraryDependencies leaves me with both versions in the class path.
Edit: After digging a bit deeper, it seems as if the (new?) feature of dependencyOverrides that comes with SBT 13.8 could be a solution:
Overriding a version. But also have a look at Conflict Management from the very same documentation.
With this you can override single dependencies, which means that you have to override each transititve dependency manually.
Simply adding the library to the libraryDependencies leaves me with both versions in the class path.
Are you sure about this? sbt (Ivy) should evict the older one if there are multiple versions in the same configuration.
In most cases
libraryDependencies += "org.fluentlenium" % "fluentlenium-core" % "0.10.3"
should be ok, granted that 0.9.x are binary compatible with 0.10.x. If you want to make sure that it is overridden during transitive dependency resolution, dependencyOverrides might be the way to go:
dependencyOverrides += "org.fluentlenium" % "fluentlenium-core" % "0.10.3"
Related
I am using some sbt plugins on a project and I would like to know which are their versions from sbt console.
I can type plugins which list the plugins but do not present their versions.
I want to do it from the sbt console, I do not want to inspect some plugins.sbt file or similar somewhere.
When you use plugins command, you see references to the plugins as they are defined in the Scala code. A single artifact can contain many plugins. Those artifacts with plugins have versions and here's how you can see them.
First load the metaproject: reload plugins
Then check dependencies: libraryDependencies
Go back to your project: reload return
You can define an alias for this in your ~/.sbt/<version>/global.sbt:
addCommandAlias("pluginsVersions", "; reload plugins ; libraryDependencies ; reload return")
It's not perfect, the output is noisy and not formatted nicely, but it's something you can get out of the box.
I use SBT / Console as a prototyping tool and therefore don't want to start with a pre-defined build.sbt file.
What I want to do is to run the sbt tool and then modify the libraryDependencies setting. then run console and go and use my newly imported library. If I need something more. I can exit the console and import more stuff and then come back in the console.
is this possible? or should I always start with a predefined build.sbt file?
set libraryDependencies += group % art % version
I understand ammonite is good at this as well
I want to write a plugin "MyPlugin" that depends on the another plugin
("io.spray" %% "sbt-twirl" % "0.6.0").
Simply adding sbt-twirl in libraryDependencies will not work,
because plugins get published with a different path scheme
than standard libraries.
I also cannot declare sbt-twirl as a plugin dependency to MyPlugin
project, because MyPlugin does not use the sbt-twirl directly,
it is the project using MyPlugin that will indirectly use it.
MyPlugin provides a task that is meant to be run after sbt-twirl
has generated it's sources (in sourceManaged) and after compilation.
A simple but non ideal solution would be to require the project using
MyPlugin to also declare sbt-twirl as a plugin dependency, but it is not
DRY because the two plugins will be sharing some settings (directories, versions, etc),
and they will have to be repeated and compatible.
It should be the same definition as for using a plugin as a plugin, except that it goes in build.sbt or project/Build.scala instead of project/plugins.sbt:
addSbtPlugin("io.spray" % "sbt-twirl" % "0.6.0")
I'm new to SBT, using version 1.0 and a custom repository, and I've set the "retrieveManaged" flag mentioned here, but it seems that SBT only downloads the directly requested JARs, but not any of the JARs upon which those JARs depend. And yes, the repository is using the customary default format described in the answers here (though SBT/Ivy doesn't seem capable of retrieving snapshots, either, but that's a separate problem, I expect). The repository does not require any kind of authentication, FYI.
Here's a slightly generified version of my built.sbt file:
name := "MyProject"
organization := "com.myorg"
version := "0.1"
scalaVersion := "2.9.0"
scalacOptions += "-deprecation"
retrieveManaged := true
resolvers += Resolver.url("myorg", url("http://host.com//content/groups/public"))
libraryDependencies += "com.myorg" % "otherproject" % "1.0"
fork in run := true
The requested "otherproject" JAR file loads fine, but SBT/Ivy seems to have no interest in opening up its POM and downloading the other JARs it needs to operate. This seems like it should be a fairly basic function (Maven does it, for example) but I have no idea how to convince SBT/Ivy to do so. (And the documentation assures us that SBT is, in fact, supposed to do this: "By default, these declarations fetch all project dependencies, transitively".)
I believe I must be doing something wrong, but have no idea -- given how simple and vanilla this basic configuration is -- what it could be.
Standard, Maven-style repositories are declared like:
resolvers += "myorg" at "http://host.com/content/groups/public"
More details are at the Library Management page you linked to and on the Resolvers page.
Typically, one only uses Resolver.url when specifying non-standard layouts.
Is there any way to get sbt (0.10) to declare a jar at some URL (http://foo.com/bar-1.1.jar) as a library dependency?
You can specify an explicit url for a jar. If you use the basic configuration just include it like follows
libraryDependencies += "slinky" % "slinky" % "2.1" from "http://slinky2.googlecode.com/svn/artifacts/2.1/slinky.jar"
As stated in the sbt wiki on GitHub the url is used as a fallback in case the artifact isn't resolved via ivy. For more details see paragraph Explicit URL