Say I want to include a dependency on the play-json library in my sbt file. How and where can I find that information?
I tried searching central repo, play git repository -- couldn't find anything.
First of all, when you want to include a dependency, you've somehow been told about it - about the required version and where to find it. Ask the person this question and you're done. The official source should always be the home page of a dependency.
I'd use http://search.maven.org/ or http://mvnrepository.com/ and pick whatever version is the most current. In your case, however, esp. after the comment where you pointed at Adding Play JSON Library to sbt the answer was right there - in the answers - see https://stackoverflow.com/a/20475410/1305344:
Play 2.2 is out and can be added separately from rest of Play
Framework. in build.sbt:
resolvers += "Typesafe Repo" at "http://repo.typesafe.com/typesafe/releases/"
libraryDependencies += "com.typesafe.play" %% "play-json" % "2.2.1"
The trick is to set up resolvers properly and using the above resolver gives http://repo.typesafe.com/typesafe/releases/com/typesafe/play/play-json_2.10.
When you've got resolvers and any version in your build configuration, you may want to use sbt-updates that's (quoting the plugin's headline) "SBT plugin that can check maven repositories for dependency updates". Quite handy to have it installed as a global plugin, i.e. .sbt/0.13/plugins/sbt-updates.sbt with the following:
resolvers += Classpaths.sbtPluginSnapshots
addSbtPlugin("com.timushev.sbt" % "sbt-updates" % "0.1.6-SNAPSHOT")
When you execute dependencyUpdates you're told what needs version update.
> dependencyUpdates
[info] Found 1 dependency update for superapp
[info] org.jacoco:org.jacoco.agent:jacoco : 0.6.4.201312101107 -> 0.6.5.201403032054 -> 0.7.0.201403182114
[success] Total time: 1 s, completed 2014-03-28 18:30:12
As you can see, I need to upgrade jacoco.
If the project you depend on releases to some known repositories, running sbt-updates regularly will ultimately tell you about the update. I'd strongly recommend reading RELEASE_NOTES for an update before upgrading since it may be introducing some breaking changes you'd rather know about before going to production.
Related
My project has few snapshot dependencies in the build.sbt file like this:
Seq("com.asr.project.myproject.urproject" %% "asr-app" % "0.0.0+")
I am executing sbt update to get the latest dependencies.
Prior to this, I have recently published artifacts with latest SNAPSHOT versions for few dependencies.
By the definition sbt update should have checked for the latest dependencies versions on the repository but it doesn't seem to be working like that.
sbt uses coursier plugin to manage the dependency tree and the coursier plugin maintains the lifetime of the artifacts in the cache.
When a dependency is downloaded, it is not going to be checked for any updates for next 24 hours(Default).
This behavior can be altered by setting COURSIER_TTL as an environment variable (e.g export COURSIER_TTL=0s). Running sbt update alone will not have any effect without it. https://get-coursier.io/docs/ttl
Probably what you need is:
libraryDependencies ++= Seq(
"com.asr.project.myproject.urproject" %% "asr-app" % "0.0.+"
)
as described in Ivy revisions, or at Fixed and dynamic revisions with more details.
I have been asked by my developers to have scodec libraries installed on a linux server and I'm lost as I can't find any documentation that points about installing the scodec library!
scodec has 11 repositories in github. This is scodec.org, the official documentation. Seems like the releases page on the docs, is not very updated. So I am going to elaborate on the repositories based on github:
scodec-bits
Provides persistent datatypes for working with bits and bytes.
Add the following into your build.sbt file:
libraryDependencies += "org.scodec" %% "scodec-bits" % "1.1.23"
Maven link. Github link.
scodec-stream
Scodec-stream is a library for streaming binary encoding and decoding. It is built atop scodec and fs2.
Add the following into your build.sbt file:
libraryDependencies += "org.scodec" %% "scodec-stream" % "2.0.0"
Maven link. Github link.
scodec-protocols
Provides models of common binary protocols using the scodec library.
Add the following into your build.sbt file:
libraryDependencies += "org.scodec" %% "scodec-protocols" % "2.0.0"
Maven link. Github link.
scodec
Github link. This package DO NOT publish to Maven central/Sonatype. Hence you cannot fetch it this way. You can try to download one of the releases and read How can I add unmanaged JARs in sbt-assembly to the final fat JAR?
scodec-cats
Integration between scodec and cats.
Add the following into your build.sbt:
libraryDependencies += "org.scodec" %% "scodec-cats" % "1.0.0"
Maven link. Github link.
scodec-build
This repository contains an SBT plugin that is used by the SBT builds of the other scodec modules. It is not intended for direct use.
I will not elaborate about this one. If there is a need for that please comment and I'll add details.
scodec.github.io
No releases yet. Skipping as well. Github link.
scodec-website
Source for scodec.org website. Hence skipping.
scodec-spire
Integration between scodec and spire. This package last publish was at 2016, and it was for Scala 2.11. But you can add it with:
libraryDependencies += "org.scodec" %% "scodec-spire" % "0.4.0"
Maven link. Github link.
I skipped scodec-scalaz and scodec-akka which are archived.
I hope this will give you an idea where to start.
I am trying to add sbt-native-packager plugin to my sbt build. For a number of reasons, I do not want my build to rely on default sbt repositories, I have blocked access to them on the network and added a resolver to my <project_home>/project/plugins.sbt in the following way:
resolvers += "local-repo-plugins" at "file:///" + baseDirectory.value + "/libs/repo/"
resolvers += Resolver.url("my-ivy-proxy-plugins", url("http://fullURLForRepo/"))(Patterns("[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]") )
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "0.7.4")
I can confirm the plugin it is hosted in my ivy proxy, but that is not even the issue, because sbt is still trying to go to default repos:
[info] Resolving com.typesafe.sbt#sbt-native-packager;0.7.4 ...
[error] Server access Error: Connection timed out url=https://repo.typesafe.com/typesafe/ivy-releases/com.typesafe.sbt/sbt-native-packager/scala_2.10/sbt_0.13/0.7.4/ivys/ivy.xml
[error] Server access Error: Connection timed out url=https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.sbt/sbt-native-packager/scala_2.10/sbt_0.13/0.7.4/ivys/ivy.xml
[error] Server access Error: Connection timed out url=https://repo1.maven.org/maven2/com/typesafe/sbt/sbt-native-packager_2.10_0.13/0.7.4/sbt-native-packager-0.7.4.pom
Also, this very same custom resolver works just fine (together with a couple of other ones, including one based on local filesystem) on my <project_home>/build.sbt when resolving library dependencies.
While I understand why the resolvers used in my project build are not the same used in my <project_home>/project/plugins.sbt, I have several questions regarding the issue I just described:
Is this the right way to define resolvers for plugins? just adding them to the <project_home>/project/plugins.sbt with that syntax?
If the answer to question 1) is yes: is there any way to avoid redundancy when defining these resolvers? e.g. I have defined exactly the very same ones in <project_home>/build.sbt
And the most important: why is the sbt build not using my ivy proxy, as specified in the resolver, to retrieve the sbt-native-packager plugin?
Yes this is a correct way to define your resolvers for plugins
This is actually quite tricky : you are trying to share settings between the plugins build and the build. These are "separate" projects from sbt's perspective. There are solutions using a project ref to gain access to the plugins build settings from the build but they are quite tricky. If this is a corporate environment where you will never have access to the default repositories anyways, it might be easier to use a custom sbt.boot.properties. You can start from the default file for 0.13.x
Changing the sbt.boot.properties should deliver you from the Server access errors.
There is nothing in the logs you provide which indicates that the plugin failed to be resolved from your proxy, only that it timedout trying to reach the official repositories. With the default sbt.boot.properties, sbt will try to resolve artefacts in the order the resolvers are defined :
local
typesafe-ivy-releases: https://repo.typesafe.com/typesafe/ivy-releases/, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext]
maven-central
sonatype-snapshots: https://oss.sonatype.org/content/repositories/snapshots
Then any resolver found in any .sbt files in the <project_home>/project/directory. As far as I am aware, sbt files are evaluated in the alphabetical order and resolvers are added in the order they appear in each file.
It seems the documents are not updated yet which ask you to put resolvers in plugins.sbt. Moving resolvers ++= Seq("Artima Maven Repository" at "http://repo.artima.com/releases") to build.sbt fixes the issue.
I think that you guys got it all wrong, it should be like this:
my_project/project/plugins.sbt should have:
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "0.7.4")
and my_project/project/project/build.sbt should have:
resolvers += ...
They are 2 different build definitions ...
In my project I want to use the sbinary library to (de)serialize some case classes to a binary form. I also want to use the latest Scala in the project. Typesafe offers a version of sbinary in their repositories, and they seem to be the only one who are doing so.
So I add the repository and dependency to my build.sbt like so:
scalaVersion := "2.11.2"
resolvers += "Typesafe Repository" at "http://repo.typesafe.com/typesafe/releases/"
libraryDependencies += "org.scala-tools.sbinary" %% "sbinary" % "0.4.2"
Surprisingly, this fails. With a dependency defined like this, SBT tries to find the dependency at the url http://repo.typesafe.com/typesafe/releases/org/scala-tools/sbinary/sbinary_2.11.0 whereas it is really located at http://repo.typesafe.com/typesafe/releases/org.scala-tools.sbinary/sbinary_2.11.0. Because SBT replaces the dots in the dependency group id with slashes, it is not able to find the dependency in the place it's in.
I've tried some tricks for building the string in other ways, but they are all useless since SBT replaces the .s by /s in the string after it is evaluated. How can I get SBT to find the dependency at this URL?
Please note that I'm aware that I could simply make this an offline dependency, but I'd prefer to have this build script work out of the box on any computer with SBT installed.
http://repo.typesafe.com/typesafe/releases/org.scala-tools.sbinary/sbinary_2.11.0 is in ivy style. The default style of sbt is maven2 so your resolver doesn't work.
try
resolvers += Resolver.url("Typesafe Repository (ivy)", url("http://repo.typesafe.com/typesafe/releases/"))(Resolver.ivyStylePatterns)
Source: https://groups.google.com/forum/#!topic/simple-build-tool/TY1AoYYvB4k
I've written an sbt plugin called sbt-jumi which implements sbt integration for Jumi. Right now the sbt-jumi plugin depends on the current Jumi release.
Here is the relevant line from the plugin's build.sbt:
libraryDependencies += "fi.jumi" % "jumi-launcher" % "0.5.376"
And a user of the plugin would add this to his project/plugins.sbt file:
addSbtPlugin("fi.jumi.sbt" % "sbt-jumi" % "0.1.0")
Now let's say that Jumi 0.6.400 is released and it's backward compatible. How can a user of the sbt-jumi plugin configure it to use Jumi 0.6.400, without me having to release a new version of the plugin?
Here is how to do it in Maven. But how to do it in sbt?
Overriding the dependencies of plugins happens the same way as overriding normal dependencies, except that the configuration must be entered into project/plugins.sbt. Overriding dependencies is explained in Library Management. Here is a summary:
If the version you wish to use is greater than the dependency that you would get transitively, sbt will use the larger version by default. You may change the conflict manager to change the default behavior - for example this will create an error on conflict:
conflictManager := ConflictManager.strict
In other words, this in project/plugins.sbt would work:
libraryDependencies += "fi.jumi" % "jumi-launcher" % "0.6.400"
You may check your plugin dependencies using reload plugins and then show update. It should now show the older version as "(EVICTED)".
If the version you wish to use is lower than the default dependency, then you will need to override differently. One way is to force the dependency:
libraryDependencies += "fi.jumi" % "jumi-launcher" % "0.4.350" force()
Another way is to use the dependencyOverrides setting:
dependencyOverrides += "fi.jumi" % "jumi-launcher" % "0.4.350"
The difference between the two methods is that overriding doesn't introduce a direct dependency. I don't think the difference matters for plugins, but for published artifacts it has some differences.