If I want to include a plugin for sbt I use addSbtPlugin() in plugins.sbt. So to add the gen-idea plugin I would use the following line:
addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.5.0")
Alas, I've to explicitly specify the version 1.5.0. What if I want to use the latest available version when it becomes available?
When I omit the third parameter I'm getting the following error:
C:\Users\JDearing\Documents\deleteme\LearningScala>sbt gen-idea
C:\Users\JDearing\.sbt\0.13\plugins\build.sbt:1: error: type mismatch;
found : sbt.impl.GroupArtifactID
required: sbt.ModuleID
addSbtPlugin("com.github.mpeltonen" % "sbt-idea" )
^
[error] Type error in expression
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore? q
Is it possible to avoid specifying the version in addSbtPlugin()?
sbt plugin is just another library for your build
https://github.com/sbt/sbt/blob/0.13/main/src/main/scala/sbt/Defaults.scala#L1513
And for a library you have Ivy resolution rules
Ivy revisions
The revision in groupID % artifactID % revision does
not have to be a single fixed version. Ivy can select the latest
revision of a module according to constraints you specify. Instead of
a fixed revision like "1.6.1", you specify "latest.integration",
"2.9.+", or "[1.0,)". See the Ivy revisions documentation for details.
from
http://www.scala-sbt.org/release/docs/Getting-Started/Library-Dependencies.html#ivy-revisions
tl;dr No. There's no way to leave the version off. It's part of sbt.ModuleID.
You can however use latest.integration or latest.milestone to avoid specifying the version explicitly. Ivy and hence SBT will take care of "selecting the latest version being either a milestone or a release".
You may also consult my answer to a similar question about the sbt-idea plugin.
Related
I have started using Berkshelf, it seems to make sense, but I can't wrap my head around how it should work.
First I created a cookbook using berks cookbook mycookbook. Then I added a dependency to only find that it cannot find mycookbook when I run berks install
So it seems that mycookbook (which is version 0.1.0) depends on default on mycookbook version 0.1.0. Why should mycookbook depend on mycookbook?
Unable to satisfy constraints on package java due to solution constraint (mycookbook = 0.1.0). Solution constraints that may result in a constraint on java: [(mycookbook = 0.1.0) -> (java ~> 1.31.1)]
Demand that cannot be met: (mycookbook = 0.1.0)
Artifacts for which there are conflicting dependencies: java = 1.31.0 -> []Unable to find a solution for demands: mycookbook (0.1.0)
It seems you get this message if you create a cookbook that already exists? I'm not sure. But after renaming it the message is gone.
I started with the latest Typesafe Activator download using the play-scala template.
Activator 1.2.10
Akka 2.3.4
Play 2.3.4
Scala 2.11.1
Then I modified build.sbt file to add play2-reactivemongo with
"org.reactivemongo" % "play2-reactivemongo_2.11" % "0.10.5.akka23-SNAPSHOT"
, but it failed with No trace dependencies for Activator.
I removed play2-reactivemongo and tried play-silhouette and received the same error.
"com.mohiva" % "play-silhouette_2.11" % "1.1-SNAPSHOT"
The app builds with neither plugin added.
lazy val root = (project in file(".")).enablePlugins(PlayScala)
scalaVersion := "2.11.1"
resolvers += "Sonatype Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots/"
libraryDependencies ++= Seq(
// "com.mohiva" % "play-silhouette_2.11" % "1.1-SNAPSHOT",
// "org.reactivemongo" % "play2-reactivemongo_2.11" % "0.10.5.akka23-SNAPSHOT",
jdbc,
anorm,
cache,
ws
)
The output from Play Framework tells me nothing beyond that one line as best I can tell. Maybe there is better information leading to a solution, but I have not been able to find it. Any ideas?
CORRECTION: now when I disable the resolver line, disable the play-silhouette line, and disable the reactivemongo line, the same error message appears. Yet, it once compiled successfully.
The error is from the sbt-echo plugin here:
https://github.com/typesafehub/sbt-echo/blob/3f431a9748a45fcb328efe4d5f989a99b5c8f7f2/akka/src/main/scala/com/typesafe/sbt/echo/EchoRun.scala#L95
I improved this error message just the other day, incidentally, but you don't have it yet:
https://github.com/typesafehub/sbt-echo/blob/master/akka/src/main/scala/com/typesafe/sbt/echo/EchoRun.scala#L118
activator's ui mode (activator ui) adds the sbt-echo plugin in order to power the Inspect tab. You can remove the plugin again (by deleting the .sbt file for it in project/) if you are not currently using UI mode, to fix this.
If you are using UI mode, to fix this you need akka and play to have versions which are understood by sbt-echo. This may mean downgrading to 2.3.3 for now, we are a little behind on updating the tracing.
With dependency management tools like rvm, dart's pub, etc, you can specify a dependency without a specific version. I will get the latest versions of each dependency an produce a baseline artifact. This artifact contains each dependency with their latest version at the time you ran the command.
With sbt I find myself doing this step manually by looking at the maven repo. Is their a sbt plugin that does that already ?
For exemple with dart's pub you can do this.
pubspec.yaml
...
dependencies:
args: '>=0.10.0 < 0.11.0'
analyzer: '>=0.13.0 <0.14.0'
barback: '>=0.11.1 <0.14.0'
...
pubspec.lock
packages:
analyzer:
description: analyzer
source: hosted
version: "0.13.6"
args:
description: args
source: hosted
version: "0.10.0+2"
barback:
description: barback
source: hosted
version: "0.12.0"
...
You can specify latest as a revision number. Eg:
libraryDependencies += "org.apache.derby" % "derby" % "latest.release"
For more details check out ivy documentation:
http://ant.apache.org/ivy/history/2.3.0/ivyfile/dependency.html#revision
Building on the answer from #darko-cerdic
You can specify latest as a revision number. Eg:
libraryDependencies += "org.apache.derby" % "derby" % "latest.release"
For more details check out ivy documentation:
http://ant.apache.org/ivy/history/2.3.0/ivyfile/dependency.html#revision
If you want, you can manually specify dependencyOverrides to force a specific library version:
dependencyOverrides ++= Seq( "org.apache.derby" % "derby" % "1.0.0")
Note that in SBT 1.+ the dependencyOverrides are specified as a Seq, whereas in prior versions it was specified as a Set.
Using the sbt-lock plugin, you can lock the current version for all of your dependencies, so that your CI system can use a stable set of dependencies. It generates a set of dependencyOverrides based on the current set of resolved libraryDependencies. This gives you behavior that is similar to a Gemfile.lock.
https://github.com/tkawachi/sbt-lock
I'm trying to use jooq-sbt-plugin to generate some code.
I downloaded the code, compiled it and copied jar into lib directory, but on sbt load i get this error:
[warn] Note: Some unresolved dependencies have extra attributes. Check that th
ese dependencies exist with the requested attributes.
[warn] sean8223:jooq-sbt-plugin:1.4 (sbtVersion=0.13, scalaVersion=2.10
)
in project/plugins.sbt i have this
resolvers += Resolver.file("lib-repo", file("lib")) transactional()
addSbtPlugin("lib-repo" %% "jooq-sbt-plugin" % "1.4")
Is this plugin "detected" and cannot be loaded or sbt does't see it?
P.S.
By default plugin does not work because it depends on jooq-3.2.1 which is not available on maven and I get error - unresolved dependencies. According to plugin readme i could set jooqVersion in build.sbt to other version, but this doesn't seem to work.
In my project/plugins.sbt:
resolvers += "sean8223 Releases" at "https://github.com/sean8223/repository/raw/master/releases"
addSbtPlugin("sean8223" %% "jooq-sbt-plugin" % "1.3")
In my build.sbt:
seq(jooqSettings:_*)
jooqVersion := "3.3.1"
And everything is successfully resolved. I didn't run any tasks, but since you say that the problem is in resolving jooq, show your build.sbt if it still doesn't work for you.
My project uses Scala 2.9.3, and I want to use Spire for 2.9.2. What do I specify in my sbt build file to get Spire for 2.9.2?
I tried
"org.spire-math" %% "spire" % "0.6.0"
but it fails looking for Scala 2.9.3.
One has to append the corresponding library name with an underscore and required scala version and verify the appropriate version number of the library(in my case, 0.3.0)
"org.spire-math" % "spire_2.9.2" % "0.3.0"