Public SBT Plugin Repo seems to be broken - scala

Currently all our builds are failing because that are not able to resolve plugins from the public SBT Plugin Repo. We get the following error:
[warn] Note: Some unresolved dependencies have extra attributes. Check that these dependencies exist with the requested attributes.
[warn] com.typesafe.play:sbt-plugin:2.4.0 (scalaVersion=2.10, sbtVersion=0.13)
[warn] com.github.gseitz:sbt-release:1.0.0 (scalaVersion=2.10, sbtVersion=0.13)
The SBT docs list the predefined repos. The link for the sbt plugins results in a 404. I think some kind of redirect mechanism is broken.
I know that the actual artifacts are hosted on bintray. Therefore i tried to point my build directly to this repo, but this does seem to help. I added following to my project/plugins.sbt:
resolvers += Resolver.url(
"fix-sbt-plugin-releases",
url("http://dl.bintray.com/sbt/sbt-plugin-releases"))(
Resolver.ivyStylePatterns)
Does anyone know a fix how to circumvent this?

Will not help you right now, but you might want to consider it for the future:
You could use something like Artifactory to mirror all of your dependencies in your local network.
You can than configure Artifactory as a proxy and would only be disappointed when you try to download a new dependency during down time (which should be pretty unlikely).
Makes dependency resolving faster, too.

Related

Using berkeley hardfloat

I am using Chisel3 in my project. I tried to import hard float library as folow:
import chisel3._
import hardfloat._
but unfortunately, I am getting:
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: UNRESOLVED DEPENDENCIES ::
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: edu.berkeley.cs#hardfloat_2.11;1.2: not found
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn]
I went through couple of repositories that used hardfloat and found out that I was missing this line in my build.sbt:
libraryDependencies ++= Seq("edu.berkeley.cs" %% "hardfloat" % "1.2")
but unfortunately I am still getting the error. I then tried to compile projects that use hardfloat without any modification (for example soundkit) but I still get the same error. I used both terminal and InteliJ to compile my project and got the same result. For some reason, the hardfloat library is not even shows up in the External Libraries in IntelliJ .
I would really appreciate it if someone let me know what might be the issue.
pedrofurla was right. After talking to folks at RISC-V, I got to know that, as you said, the hardfloat is not published to somewhere that sbt can download it. In order to use the library, one has to build and publish it locally:
git clone https://github.com/ucb-bar/berkeley-hardfloat.git hardfloat
cd hardfloat
sbt publish-local
Note: the library works with chisel2

SBT plugins not using custom resolvers

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

Why IntelliJ can't find SBT snapshot dependencies?

I have a Play 2.3 Scala project which runs perfectly when started with the activator run command. However, if I try to start it in IntelliJ 13 from the Run/Debug Configurations option there's a problem with resolving snapshot dependencies.
According to logs following repositories has been checked in order to find dependencies:
[warn] module not found: org.package#my-dep;1.0-SNAPSHOT
[warn] ==== local: tried
[warn] C:\Users\MyUser\.ivy2\local\org.package\my-dep\1.0-SNAPSHOT\ivys\ivy.xml
[warn] ==== public: tried
[warn] http://repo1.maven.org/maven2/org/package/my-dep/1.0-SNAPSHOT/my-dep-1.0-SNAPSHOT.pom
[warn] ==== Typesafe Releases Repository: tried
[warn] http://repo.typesafe.com/typesafe/releases/org/package/my-dep/1.0-SNAPSHOT/my-dep-1.0-SNAPSHOT.pom
Dependencies are present at my ~/.ivy2/cache directory. I also have there other dependencies which aren't marked as snapshots and it looks like IntelliJ doesn't have a problem with finding them. It only applies to snapshots.
Update
It looks like IDEA ignores my ~/.sbt/repositories file where snapshot repository is defined and uses default SBT plugin configuration.
Is it actually possible to configure IDEA so it would use my custom repository definition?
I tried without success to set custom sbt-launcher in Settings -> SBT -> Launcher -> Custom.
After I run my application with Run configuration I could see in the logs that for some reason launcher that I specified was overridden by another which was part of the Scala plugin.
-Dsbt.global.base=C:\Users\User\AppData\Local\Temp\sbt-global-plugin3401565420094215394stub -classpath C:\Users\User\.IntelliJIdea13\config\plugins\Scala\launcher\sbt-launch.jar
Finally I managed to force IDEA to use my ~/.sbt/repositories by adding -Dsbt.repository.config=C:\Users\User\.sbt\repositories to the Run Configuration JVM Options.
I have also set -Dsbt.override.build.repos=true to make sure that only repositories listed in my custom configuration are used.

How to download sbt plugin source jars in a common sbt project?

It's nature to download the dependencies source jars in a sbt project, using sbt gen-idea or idea's autoimport feature
but how can I download the sbt plugin source jars which I declared in project/plugins.sbt
IDEA
IDEA should already do this*.
When you import a project and have Download sbt sources checked in Preferences > Build, Execution, Deployment > Build Tools > sbt then it will run the updateSbtClassifiers sbt task.
* Read the Troubleshooting section as there are several known issues with this.
sbt
As mentioned above, you can run the following sbt task:
sbt> updateSbtClassifiers
This command is somewhat special in that it knows to resolve the classifiers for the plugins. It also uses settings that are scoped to that task. See the caveat about sbt/sbt#3432.
Longer way
It is important to understand that sbt is recursive.
Dependencies declared in build.sbt will be for the proper build.
Dependencies declared in project/plugins.sbt will be for the meta-build.
When you just run updateSbtClassifiers it is running this on the proper build, however the dependencies are actually for the meta-build. That is why I said that this task is a little special.
Another way (which can achieve different results) is to run the updateClassifiers task directly on the meta-build.
First switch over to the meta-build:
sbt> reload plugins
Now that you are in the meta-build run:
sbt:project> updateClassifiers
This will retrieve the src and doc for your dependencies (it may not actually do this for some plugins). Run libraryDependencies to see the dependencies of the meta-build.
To get back to the proper
sbt:project> reload return build run:
Troubleshooting
Download failed
You may see in the sbt logs that it failed to download either the src or doc. For example:
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: FAILED DOWNLOADS ::
[warn] :: ^ see resolution messages for details ^ ::
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: rocks.muki#sbt-graphql;0.5.0!sbt-graphql.jar(doc)
[warn] :: rocks.muki#sbt-graphql;0.5.0!sbt-graphql.jar(src)
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
If you look just above you will see all the resolvers that it tried. You should see one for sbt-plugin-releases which is where most sbt plugins are published to. See predefined resolvers for more details.
If you do not see that it tried sbt-plugin-releases then chances are you have encountered sbt/sbt#3432.
updateSbtClassifiers does not use the correct resolvers. Add the following to your build.sbt file:
updateSbtClassifiers / dependencyResolution := IvyDependencyResolution((updateSbtClassifiers / ivyConfiguration).value)
Sources not attaching
Even if the updateSbtClassifiers successfully downloads and resolves the src and doc IDEA may not attach them.
This seems to be a bug in the sbt-structure plugin. See SCL-13619 for details.
No attempt at downloading
If for some reason this doesn't download the sources (there is no failed download message) then have a look in your .ivy2/exclude_classifiers file. I'm not entirely sure what this file is for but I do know that sbt will exclude anything that is in here.
In my case it had a whole lot of things that I didn't want excluded so I deleted it and then it worked. Delete at your own risk.
You can use reload plugins to go into the project that contains the plugins. If you type libraryDependencies you can (for example) see the list of plugin dependencies. Use reload return to return to your normal sbt console.
More information here: Commands for managing the build definition

How to use scala-time?

somebody know scala-time? (https://github.com/jorgeortiz85/scala-time)
Have no idea how to use it. I can download it (on linux) and run sbt but theres always the same errormessage:
git clone git://github.com/jorgeortiz85/scala-time
cd scala-time
sbt
Getting org.scala-tools.sbt sbt_2.9.1 0.7.4 ...
:: problems summary ::
:::: WARNINGS
module not found: org.scala-tools.sbt#sbt_2.9.1;0.7.4
==== local: tried
/home/ll/.ivy2/local/org.scala-tools.sbt/sbt_2.9.1/0.7.4/ivys/ivy.xml
-- artifact org.scala-tools.sbt#sbt_2.9.1;0.7.4!sbt_2.9.1.jar:
/home/ll/.ivy2/local/org.scala-tools.sbt/sbt_2.9.1/0.7.4/jars/sbt_2.9.1.jar
==== Maven2 Local: tried
file:///home/ll/.m2/repository/org/scala-tools/sbt/sbt_2.9.1/0.7.4/sbt_2.9.1-0.7.4.pom
-- artifact org.scala-tools.sbt#sbt_2.9.1;0.7.4!sbt_2.9.1.jar:
file:///home/ll/.m2/repository/org/scala-tools/sbt/sbt_2.9.1/0.7.4/sbt_2.9.1-0.7.4.jar
==== typesafe-ivy-releases: tried
http://repo.typesafe.com/typesafe/ivy-releases/org.scala-tools.sbt/sbt_2.9.1/0.7.4/ivys/ivy.xml
-- artifact org.scala-tools.sbt#sbt_2.9.1;0.7.4!sbt_2.9.1.jar:
http://repo.typesafe.com/typesafe/ivy-releases/org.scala-tools.sbt/sbt_2.9.1/0.7.4/jars/sbt_2.9.1.jar
==== Maven Central: tried
http://repo1.maven.org/maven2/org/scala-tools/sbt/sbt_2.9.1/0.7.4/sbt_2.9.1-0.7.4.pom
-- artifact org.scala-tools.sbt#sbt_2.9.1;0.7.4!sbt_2.9.1.jar:
http://repo1.maven.org/maven2/org/scala-tools/sbt/sbt_2.9.1/0.7.4/sbt_2.9.1-0.7.4.jar
==== Scala-Tools Maven2 Repository: tried
http://scala-tools.org/repo-releases/org/scala-tools/sbt/sbt_2.9.1/0.7.4/sbt_2.9.1-0.7.4.pom
-- artifact org.scala-tools.sbt#sbt_2.9.1;0.7.4!sbt_2.9.1.jar:
http://scala-tools.org/repo-releases/org/scala-tools/sbt/sbt_2.9.1/0.7.4/sbt_2.9.1-0.7.4.jar
==== Scala-Tools Maven2 Snapshots Repository: tried
http://scala-tools.org/repo-snapshots/org/scala-tools/sbt/sbt_2.9.1/0.7.4/sbt_2.9.1-0.7.4.pom
-- artifact org.scala-tools.sbt#sbt_2.9.1;0.7.4!sbt_2.9.1.jar:
http://scala-tools.org/repo-snapshots/org/scala-tools/sbt/sbt_2.9.1/0.7.4/sbt_2.9.1-0.7.4.jar
::::::::::::::::::::::::::::::::::::::::::::::
:: UNRESOLVED DEPENDENCIES ::
::::::::::::::::::::::::::::::::::::::::::::::
:: org.scala-tools.sbt#sbt_2.9.1;0.7.4: not found
::::::::::::::::::::::::::::::::::::::::::::::
huh? Any other options?
To actually use it (as compared to building scala-time yourself), just add
libraryDependencies += "org.scala-tools.time" % "time_2.9.1" % "0.5"
to the build.sbt of the project you want to use it in.
Addition:
Current versions may want to use
libraryDependencies += "org.scalaj" %% "scalaj-time" % "0.6"
This is an sbt version problem, and you might be able to work around it by using a different sbt-launch or by changing the build a bit. I get a similar error if I use sbt-launch-0.10.1.jar for this code, but it works fine if I use sbt-launch-0.7.7.jar.
I'd suspect you're using sbt-launch-0.11.0, and this is causing sbt to look for a compiled version of sbt that doesn't in fact exist.
Possible fixes are:
Just use sbt-launch-0.7.7 for this code.
Edit the build.properties file to use a different version of sbt.
Get source for sbt-0.7.4, compile with scala 2.9.1 and stash the result in your local ivy repository with the name and location that's being searched.
Options 1 and 2 worked for me.
I haven't done #3 for this, but have done similar things for other code. It can be a bit painful...
You can have multiple versions of sbt-launch and flip between them depending on the needs of a particular codebase.
Perhaps someone who knows sbt better than I will post a real solution, but I'm hoping this is at least a little helpful.
Update or remove the sbt version(0.7.4) line from build.properties
That means there's no public version of SBT 0.7.4 compiled against Scala 2.9.1 by the looks of it.