Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SBT plugins not using custom resolvers

Tags:

scala

sbt

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:

  1. Is this the right way to define resolvers for plugins? just adding them to the <project_home>/project/plugins.sbt with that syntax?
  2. 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
  3. 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?
like image 539
djsecilla Avatar asked Dec 02 '15 13:12

djsecilla


People also ask

What are resolvers in sbt?

sbt resolver is the configuration for repository that contains jars and their dependencies. for example the below is a resolver definition for a repository called Sonatype and it points at snapshot releases (dev versions) resolvers += "Sonatype OSS Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots"

Where are sbt plugins stored?

Plugins can be installed for all your projects at once by declaring them in $HOME/. sbt/1.0/plugins/ . $HOME/. sbt/1.0/plugins/ is an sbt project whose classpath is exported to all sbt build definition projects.

What are sbt plugins?

A plugin can define a sequence of sbt settings that are automatically added to all projects or that are explicitly declared for selected projects. For example, a plugin might add a proguard task and associated (overridable) settings. Finally, a plugin can define new commands (via the commands setting).

What does sbt build do?

sbt is a popular tool for compiling, running, and testing Scala projects of any size. Using a build tool such as sbt (or Maven/Gradle) becomes essential once you create projects with dependencies or more than one code file.


1 Answers

  1. Yes this is a correct way to define your resolvers for plugins

  2. 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.

  3. 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.

like image 135
Jean Avatar answered Oct 25 '22 07:10

Jean