4

After upgrading my project to Play Framework 2.3.0 (and as a result sbt 0.13.5) I have encountered multiple "URI has an authority component" errors when sbt attempts to resolve dependencies for the first time on a fresh Debian install. For example:

[error] (*:update) sbt.ResolveException: unresolved dependency: org.slf4j#slf4j-api;1.7.6: several problems occurred while resolving dependency: org.slf4j#slf4j-api;1.7.6 {compile=[compile(*), master(*)], runtime=[runtime(*)]}:
[error]     several problems occurred while resolving dependency: org.slf4j#slf4j-parent;1.7.6 {}:
[error]     URI has an authority component
[error]     URI has an authority component
[error]     URI has an authority component
[error]     URI has an authority component
[error]     URI has an authority component
at sbt.IvyActions$.sbt$IvyActions$$resolve(IvyActions.scala:217)
    at sbt.IvyActions$$anonfun$update$1.apply(IvyActions.scala:126)
    at sbt.IvyActions$$anonfun$update$1.apply(IvyActions.scala:125)
    at sbt.IvySbt$Module$$anonfun$withModule$1.apply(Ivy.scala:115)
    at sbt.IvySbt$Module$$anonfun$withModule$1.apply(Ivy.scala:115)
    at sbt.IvySbt$$anonfun$withIvy$1.apply(Ivy.scala:103)
    at sbt.IvySbt.sbt$IvySbt$$action$1(Ivy.scala:48)
    at sbt.IvySbt$$anon$3.call(Ivy.scala:57)
    at xsbt.boot.Locks$GlobalLock.withChannel$1(Locks.scala:98)
    at xsbt.boot.Locks$GlobalLock.xsbt$boot$Locks$GlobalLock$$withChannelRetries$1(Locks.scala:81)
    at xsbt.boot.Locks$GlobalLock$$anonfun$withFileLock$1.apply(Locks.scala:102)
    at xsbt.boot.Using$.withResource(Using.scala:11)
    at xsbt.boot.Using$.apply(Using.scala:10)
    at xsbt.boot.Locks$GlobalLock.ignoringDeadlockAvoided(Locks.scala:62)
    at xsbt.boot.Locks$GlobalLock.withLock(Locks.scala:52)
    at xsbt.boot.Locks$.apply0(Locks.scala:31)
    at xsbt.boot.Locks$.apply(Locks.scala:28)
    at sbt.IvySbt.withDefaultLogger(Ivy.scala:57)
    at sbt.IvySbt.withIvy(Ivy.scala:98)
    at sbt.IvySbt.withIvy(Ivy.scala:94)
    at sbt.IvySbt$Module.withModule(Ivy.scala:115)
    at sbt.IvyActions$.update(IvyActions.scala:125)
    at sbt.Classpaths$$anonfun$sbt$Classpaths$$work$1$1.apply(Defaults.scala:1223)
    at sbt.Classpaths$$anonfun$sbt$Classpaths$$work$1$1.apply(Defaults.scala:1221)
    at sbt.Classpaths$$anonfun$doWork$1$1$$anonfun$74.apply(Defaults.scala:1244)
    at sbt.Classpaths$$anonfun$doWork$1$1$$anonfun$74.apply(Defaults.scala:1242)
    at sbt.Tracked$$anonfun$lastOutput$1.apply(Tracked.scala:35)
    at sbt.Classpaths$$anonfun$doWork$1$1.apply(Defaults.scala:1246)
    at sbt.Classpaths$$anonfun$doWork$1$1.apply(Defaults.scala:1241)
    at sbt.Tracked$$anonfun$inputChanged$1.apply(Tracked.scala:45)
    at sbt.Classpaths$.cachedUpdate(Defaults.scala:1249)
    at sbt.Classpaths$$anonfun$updateTask$1.apply(Defaults.scala:1214)
    at sbt.Classpaths$$anonfun$updateTask$1.apply(Defaults.scala:1192)
    at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
    at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:42)
    at sbt.std.Transform$$anon$4.work(System.scala:64)
    at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:237)
    at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:237)
    at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:18)
    at sbt.Execute.work(Execute.scala:244)
    at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:237)
    at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:237)
    at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:160)
    at sbt.CompletionService$$anon$2.call(CompletionService.scala:30)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

It seems to be an issue with only *-parent dependencies, and did not manifest itself on earlier versions of play and sbt. I been able to reproduce on three separate servers in three separate locations, both using the provided .deb and placing the launcher jar manually.

Any guidance would be greatly appreciated.

kc_
  • 57
  • 1
  • 3
  • See [What does 'URI has an authority component' mean?](http://stackoverflow.com/questions/2366270/what-does-uri-has-an-authority-component-mean) – Andrzej Jozwik Jun 03 '14 at 20:41
  • Yeah I saw that earlier, this issue appears to be with how sbt attempts to retrieve certain files from the repository. Have updated the question with the stack trace. – kc_ Jun 03 '14 at 21:02
  • 1
    Do you use sbt or activator to execute the build? – Jacek Laskowski Jun 04 '14 at 09:57

1 Answers1

6

In my case the issue was related to one of the resolvers configured:

  val projectResolvers = Seq[Resolver](
    "Local Maven Repository" at "file://"+Path.userHome.asFile.toURI.toURL+".m2/repository/",
    ...
  )

After looking at the details of last command (failing with the error) I saw the following in the resolvers list:

[debug]     Local Maven Repository: file://file:/Users/aldo/.m2/repository

Removing the hardcoded 'file://' resolved the issue:

  val projectResolvers = Seq[Resolver](
    "Local Maven Repository" at ""+Path.userHome.asFile.toURI.toURL+".m2/repository/",
    ...
  )
Adalbert W.
  • 103
  • 4