Chisel: Resolvers Key in build.sbt - sbt

Although it's a fundamental question, what resolver key do in build.sbt. I have just started learning chisel3
for example.
resolvers ++= Seq(
Resolver.sonatypeRepo("snapshots"),
Resolver.sonatypeRepo("releases")
)
If you suggest any link to read the build.sbt for chisel projects or in general. Thanks

Resolvers tell sbt where to look for things specified in libraryDependencies.
Resolver.sonatypeRepo("snapshots") is a predefined repository at Sonatype OSS Maven, under the "snapshots" directory.
Google 'sbt Resolvers' and you will find plenty of information.
For example the manual at Resolvers Page at SBT documentation site

Related

how do I put sbt-assembly in artifactory and have sbt retrieve it

For some reason I am having trouble downloading the sbt-assembly plugin using
addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.14.7")
from plugins.sbt. It says the pom is not found. I'm using scala 2.12.10 at the moment but this has been an irritation with 2.13.1, too. As an alternative, I tossed it in an artifactory repository. When sbt concocts the URL to retrieve the pom, it comes up with
http:/.../com/eed3si9n/sbt-assembly_2.12_1.0/0.14.7/sbt-assembly-0.14.7.pom
as opposed to
http:/.../com/eed3si9n/sbt-assembly/0.14.7/sbt-assembly-0.14.7.pom
which will actually retrieve it. Any insight would be appreciated.
Looking under custom resolvers in the sbt reference manual tells you to match relevant values from the build. Maybe something like:
resolvers += Resolver.url("red angus", new java.net.URL(
"http:/..."))(
Patterns("[organisation]/[module]/[revision]/[artifact]-[revision].[ext]") ).
withAllowInsecureProtocol(true)

Why two different versions of sbt in the project

In my Play project I notice that build.properties has sbt version addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.6.12")
and build.properties has sbt.version=0.13.15.
1) Why are there two enteries?
2) What is the difference between them
3) Should their versions be different?
There is a difference between SBT proper and SBT plugin. Play Framework is an SBT plugin. The version of SBT is specified in project/build.properties:
sbt.version=0.13.15
whilst the version of Play SBT plugin is specified in project/plugins.sbt:
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.6.12")
Scala Play SBT plugin (PlayScala) is enabled in build.sbt like so:
lazy val root = (project in file(".")).enablePlugins(PlayScala)
SBT plugins enrich build definitions with additional useful tasks, commands, settings, and dependencies. Here are some examples from Play SBT plugin:
object PlayKeys {
val playDefaultPort = SettingKey[Int]("playDefaultPort", "The default port that Play runs on")
val playDefaultAddress = SettingKey[String]("playDefaultAddress", "The default address that Play runs on")
val playRunHooks = TaskKey[Seq[PlayRunHook]]("playRunHooks", "Hooks to run additional behaviour before/after the run task")
...
So for example to change the default port that Play runs on we can define in build.sbt:
PlayKeys.playDefaultPort := 9009
Note when upgrading SBT version we need to make sure it is compatible with corresponding Play SBT plugin. For example, to use Play with SBT 1 we need to update Play sbt-plugin to 2.6.6.
SBT plugin best practice artifact naming convention encurages the following naming scheme:
sbt-$projectname
For example, sbt-scoverage, sbt-buildinfo, sbt-release, sbt-assembly, however Play named it sbt-plugin, which arguably can be confusing.

How to show all config scope axis?

From the document of sbt, I see there are 3 scope axis in sbt:
project
config
task
For project and task, I can use command:
projects
tasks
to see the list of them of the project.
But how to see the configs?
It'd be ivyConfigurations.
> help ivyConfigurations
The defined configurations for dependency management. This may be different
from the configurations for Project settings.
> ivyConfigurations
[info] List(compile, runtime, test, provided, optional, compile-internal,
runtime-internal, test-internal, plugin, sources, docs, pom, scala-tool)

Downloading source jars in sbt?

I pulled down the sources and build/published it locally. I want to debug into sources jars. When I publish it locally, I clearly see it also publishes source jars.
[info] published securesocial-testkit_2.10 to local\ws.securesocial\securesocial-testkit_2.10\master-SNAPSHOT\srcs\securesocial-testkit_2.10-sources.jar
I don't know how to reference this jar.
Changing "ws.securesocial" %% "securesocial" % "master-SNAPSHOT" to "ws.securesocial" %% "securesocial" % "master-SNAPSHOT-sources" doesn't work.
Add withSources() to the dependency definition.
From Download Sources in the official documentation of sbt:
Downloading source and API documentation jars is usually handled by an
IDE plugin. These plugins use the updateClassifiers and
updateSbtClassifiers tasks, which produce an Update Report referencing
these jars.
To have sbt download the dependency's sources without using an IDE
plugin, add withSources() to the dependency definition. For API jars,
add withJavadoc(). For example:
libraryDependencies += "org.apache.felix" % "org.apache.felix.framework" % "1.8.0" withSources() withJavadoc()
Note that this is not transitive. Use the update-*classifiers tasks
for that.
You can also run sbt update-classifiers to download sources and javadoc jars for all project dependencies at once
For sbt 1.0, command is sbt updateClassifiers
For me, it worked better with
sbt ';reload plugins; updateClassifiers'

How can SBT project import library from GitHub cloned to local directory?

I forked a Scala library from GitHub, and I want to import it to another project.
How can I tell sbt where to find this package?
For example, I'm writing a program in ~/code/scala/myProgram, and I want to import a library from ~/code/scala/otherlib.
If it is supported by the project you have cloned (that is, if it supports SBT and is configured to publish to a repository), you can publish it locally with the sbt command sbt publish-local. For example:
cd ~/code/scala/otherlib
sbt publish-local
This will build and publish this library in your local Ivy repository (typically ~/.ivy2/local). Note that you will need to repeat this each time you modify the otherlib sources.
After the project's published locally to the local Ivy repository, you can specify otherlib as a dependency in your SBT project, using the regular SBT dependency for the original version of the forked library (assuming that you haven't changed its ID, version, group ID, etc.). For example, by adding:
libraryDependencies += "com.some_company" % "otherlib" % "1.0.0"
to your build.sbt file.
Now, when you build your project, it will find otherlib in your local Ivy repository (as if it'd been pulled down from a regular repository) and will use your custom version of it.
If otherlib doesn't support SBT, or isn't configured to publish to a repository, and you do not want to modify it to do so, then you can simply copy its .jar file(s) to the /lib directory (~/code/scala/myProgram/lib) of your project.
SBT supports git repositories out of the box. The support is for clone and checkout. See my answer to Can SBT refresh git uri dependency (always or on demand)? or Using Git local repository as dependency in SBT project?, that boil down to the following in build.sbt:
lazy val gitRepo = "git:file:///Users/jacek/sandbox/so/sbt-git/git-repo/#master"
lazy val g = RootProject(uri(gitRepo))
lazy val root = project in file(".") dependsOn g
Once you define the dependency (between projects) you can use it - the git-hosted project - with no other configuration.

Resources