首次使用 SBT - 在代理后面检索依赖项的问题 [英] using SBT for first time - issue retrieving dependencies behind proxy

查看:30
本文介绍了首次使用 SBT - 在代理后面检索依赖项的问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经下载了 SBT (sbt-0.13.15.zip) 并解压了它,但是我在运行 sbt.bat 时遇到了问题.

I've downloaded SBT (sbt-0.13.15.zip) and unzipped it, but I'm facing issue when running sbt.bat .

最初,当我发现我需要指定 https 配置,而不是 http 配置时,我遇到了代理问题,但当同时提供两者时,它正在使用 http 并且失败了.

Initially, I had proxy issues that I fixed when I found I needed to specify only the https config, and not the http one - when providing both, it was taking the http one and it was failing.

所以现在我不再有代理问题了,但是在尝试获取 jansi 依赖项时失败了:

So now I don't have proxy issues anymore, but it's failing when trying to fetch the jansi dependencies :

setting 'basedir' to 'C:\Users\vfuchs070114\.sbt\boot'
:: resolving dependencies :: org.scala-sbt#boot-jansi;1.0
    confs: [default]
    validate = true
    refresh = false
resolving dependencies for configuration 'default'
== resolving dependencies for org.scala-sbt#boot-jansi;1.0 [default]
loadData of org.scala-sbt#boot-jansi;1.0 of rootConf=default
== resolving dependencies org.scala-sbt#boot-jansi;1.0->org.fusesource.jansi#jansi;1.11 [default->default(compile)]
loadData of org.fusesource.jansi#jansi;1.11 of rootConf=default
    using redefined-public to resolve org.fusesource.jansi#jansi;1.11
redefined-public: Checking cache for: dependency: org.fusesource.jansi#jansi;1.11 {default=[default(compile)]}
redefined-public: no namespace defined: using system
    no ivy file in cache for org.fusesource.jansi#jansi;1.11: tried C:\Users\vfuchs070114\.ivy2\cache\org.fusesource.jansi\jansi\ivy-1.11.xml
redefined-public: no latest strategy defined: using default
local: no namespace defined: using system
    no ivy file in cache for org.fusesource.jansi#jansi;1.11: tried C:\Users\vfuchs070114\.ivy2\cache\org.fusesource.jansi\jansi\ivy-1.11.xml
     trying C:\Users\vfuchs070114\.ivy2\local\org.fusesource.jansi\jansi\1.11\ivys\ivy.xml
        tried C:\Users\vfuchs070114\.ivy2\local\org.fusesource.jansi\jansi\1.11\ivys\ivy.xml
    local: resource not reachable for org.fusesource.jansi#jansi;1.11: res=C:\Users\vfuchs070114\.ivy2\local\org.fusesource.jansi\jansi\1.11\ivys\ivy.xml
     trying C:\Users\vfuchs070114\.ivy2\local\org.fusesource.jansi\jansi\1.11\jars\jansi.jar
        tried C:\Users\vfuchs070114\.ivy2\local\org.fusesource.jansi\jansi\1.11\jars\jansi.jar
    local: resource not reachable for org.fusesource.jansi#jansi;1.11: res=C:\Users\vfuchs070114\.ivy2\local\org.fusesource.jansi\jansi\1.11\jars\jansi.jar
    local: no ivy file nor artifact found for org.fusesource.jansi#jansi;1.11
local-preloaded-ivy: no namespace defined: using system
    no ivy file in cache for org.fusesource.jansi#jansi;1.11: tried C:\Users\vfuchs070114\.ivy2\cache\org.fusesource.jansi\jansi\ivy-1.11.xml
     trying file:/C:/Users/vfuchs070114/.sbt/preloaded/org.fusesource.jansi/jansi/1.11/ivys/ivy.xml
        tried file:/C:/Users/vfuchs070114/.sbt/preloaded/org.fusesource.jansi/jansi/1.11/ivys/ivy.xml
    local-preloaded-ivy: resource not reachable for org.fusesource.jansi#jansi;1.11: res=file:/C:/Users/vfuchs070114/.sbt/preloaded/org.fusesource.jansi/jansi/1.11/ivys/ivy.xml
    local-preloaded-ivy: no ivy file found for org.fusesource.jansi#jansi;1.11
local-preloaded: no namespace defined: using system
    no ivy file in cache for org.fusesource.jansi#jansi;1.11: tried C:\Users\vfuchs070114\.ivy2\cache\org.fusesource.jansi\jansi\ivy-1.11.xml
     trying file:/C:/Users/vfuchs070114/.sbt/preloaded/org/fusesource/jansi/jansi/1.11/jansi-1.11.pom
        tried file:/C:/Users/vfuchs070114/.sbt/preloaded/org/fusesource/jansi/jansi/1.11/jansi-1.11.pom
    local-preloaded: resource not reachable for org/fusesource/jansi#jansi;1.11: res=file:/C:/Users/vfuchs070114/.sbt/preloaded/org/fusesource/jansi/jansi/1.11/jansi-1.11.pom
     trying file:/C:/Users/vfuchs070114/.sbt/preloaded/org/fusesource/jansi/jansi/1.11/jansi-1.11.jar
        tried file:/C:/Users/vfuchs070114/.sbt/preloaded/org/fusesource/jansi/jansi/1.11/jansi-1.11.jar
    local-preloaded: resource not reachable for org/fusesource/jansi#jansi;1.11: res=file:/C:/Users/vfuchs070114/.sbt/preloaded/org/fusesource/jansi/jansi/1.11/jansi-1.11.jar
    local-preloaded: no ivy file nor artifact found for org.fusesource.jansi#jansi;1.11
Maven Central: no namespace defined: using system
    no ivy file in cache for org.fusesource.jansi#jansi;1.11: tried C:\Users\vfuchs070114\.ivy2\cache\org.fusesource.jansi\jansi\ivy-1.11.xml
     trying https://repo1.maven.org/maven2/org/fusesource/jansi/jansi/1.11/jansi-1.11.pom
        tried https://repo1.maven.org/maven2/org/fusesource/jansi/jansi/1.11/jansi-1.11.pom
problem occurred while resolving dependency: org.fusesource.jansi#jansi;1.11 {default=[default(compile)]} with Maven Central: java.lang.RuntimeException: java.util.NoSuchElementException
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1453)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1439)
    at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:2965)
    at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:489)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
    at org.apache.ivy.util.url.BasicURLHandler.checkStatusCode(BasicURLHandler.java:130)
    at org.apache.ivy.util.url.BasicURLHandler.getURLInfo$57a0216e(BasicURLHandler.java:73)
    at org.apache.ivy.util.url.BasicURLHandler.getURLInfo(BasicURLHandler.java:54)
    at org.apache.ivy.plugins.repository.url.URLResource.init(URLResource.java:65)
    at org.apache.ivy.plugins.repository.url.URLResource.exists(URLResource.java:81)
    at org.apache.ivy.plugins.resolver.RepositoryResolver.findResourceUsingPattern(RepositoryResolver.java:97)
    at org.apache.ivy.plugins.resolver.AbstractPatternsBasedResolver.findResourceUsingPatterns(AbstractPatternsBasedResolver.java:96)
    at org.apache.ivy.plugins.resolver.IBiblioResolver.findIvyFileRef(IBiblioResolver.java:102)
    at org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:228)
    at org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:512)
    at org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:104)
    at org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:169)
    at org.apache.ivy.core.resolve.VisitNode.loadData(VisitNode.java:292)
    at org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:714)
    at org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:799)
    at org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:722)
    at org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:594)
    at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:234)
    at xsbt.boot.Update.xsbt$boot$Update$$lockedApply(Update.scala:105)
    at xsbt.boot.Update$$anon$4.call(Update.scala:99)
    at xsbt.boot.Locks$GlobalLock.withChannel$1(Locks.scala:93)
    at xsbt.boot.Locks$GlobalLock.xsbt$boot$Locks$GlobalLock$$withChannelRetries$1(Locks.scala:78)
    at xsbt.boot.Locks$GlobalLock$$anonfun$withFileLock$1.apply(Locks.scala:97)
    at xsbt.boot.Using$.withResource(Using.scala:10)
    at xsbt.boot.Using$.apply(Using.scala:9)
    at xsbt.boot.Locks$GlobalLock.ignoringDeadlockAvoided(Locks.scala:58)
    at xsbt.boot.Locks$GlobalLock.withLock(Locks.scala:48)
    at xsbt.boot.Locks$.apply0(Locks.scala:31)
    at xsbt.boot.Locks$.apply(Locks.scala:28)
    at xsbt.boot.Update.apply(Update.scala:100)
    at xsbt.boot.Launch.update(Launch.scala:352)
    at xsbt.boot.Launch$$anonfun$jansiLoader$1.apply(Launch.scala:178)
    at scala.Option.getOrElse(Option.scala:120)
    at xsbt.boot.Launch.jansiLoader$2f324eef(Launch.scala:173)
    at xsbt.boot.Launch.<init>(Launch.scala:150)
    at xsbt.boot.Launcher$.apply(Launch.scala:366)
    at xsbt.boot.Launch$.apply(Launch.scala:18)
    at xsbt.boot.Boot$.runImpl(Boot.scala:41)
    at xsbt.boot.Boot$.main(Boot.scala:17)
    at xsbt.boot.Boot.main(Boot.scala)
Caused by: java.util.NoSuchElementException
    at java.util.StringTokenizer.nextToken(StringTokenizer.java:349)
    at sun.net.www.protocol.http.HttpURLConnection.doTunneling(HttpURLConnection.java:2016)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:183)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1511)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1439)
    at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
    ... 41 more

它尝试从 https 获取数据://repo1.maven.org/maven2/org/fusesource/jansi/jansi/1.11/jansi-1.11.pom 存在,但似乎无法解析它或其他东西(StringTokenizer 抛出的 NoSuchElementException).. 我试图将 pom 和 jar 文件放在它试图找到它们的本地:它找到了它们,但最终没有太大的区别.

It tries to fetch data from https://repo1.maven.org/maven2/org/fusesource/jansi/jansi/1.11/jansi-1.11.pom that exists but it seems it's not able to parse it or something (NoSuchElementException thrown by StringTokenizer).. I've tried to place the pom and jar files in local where it tries to find them : it finds them but it doesn't make a big difference at the end.

类似的事情发生在 typesafe-ivy-releases 和 sbt-ivy-snapshots 上,它试图从不存在的远程 URL 获取一些常春藤信息:

similar stuff happens for typesafe-ivy-releases and sbt-ivy-snapshots, for which it's trying to get some ivy informations from remote URLs that don't exist :

https://repo.scala-sbt.org/scalasbt/ivy-snapshots/org.fusesource.jansi/jansi/1.11/ivys/ivy.xml

因此,在这种情况下,它失败并不是什么大惊喜.

So in that case, it's not a major surprise that it fails.

知道什么是错误的吗?

谢谢

============

============

编辑

我在这里看到 https://github.com/typesafehub/activator/issues/18 这可能是 Ipv4/Ipv6 的问题.我尝试添加推荐的属性以强制使用 IPv4 (-Djava.net.preferIPv4Stack=true),但它仍然不起作用.

I see here https://github.com/typesafehub/activator/issues/18 that it could be an issue with Ipv4 / Ipv6 . I tried adding the recommended property to force to IPv4 (-Djava.net.preferIPv4Stack=true), but it still doesn't work.

但是,我觉得根本原因可能是这样的,或者一些编码问题,这使得远程文件无法解析"

However, I have the feeling the root cause could be something like this, or some encoding issue, that makes the remote file "unparsable"

编辑 2

昨天我花了一整天的时间手动获取依赖项,最后它仍然无法正常工作..然后我在没有代理的情况下在家里的电脑上尝试,它运行得很好.所以现在我再次尝试,只专注于运行 sbt.bat :我在 java 调用之前在 sbt.bat 中添加了一个echo"以确保它符合我的期望,并且确实如此:

I spent my whole day yesterday fetching the dependencies manually and at the end it was still not working.. then I tried on my computer at home without a proxy, and it worked perfectly. So now I'm trying again, focusing solely on running sbt.bat : I've added an "echo" in sbt.bat just before the java call to make sure it has what I expect, and it does :

"C:\Toolbox\apps\jdk\jdk1.8.0_25-windows-x64\bin\java.exe" -Dhttps.proxyHost=theProxyURL 
-Dhttps.proxyPort=8080 -Dhttps.proxyUser=myId -Dhttps.proxyPassword=myPassword
-cp "C:\Toolbox\apps\sbt-0.13.15_2ndTry\bin\sbt-launch.jar" xsbt.boot.Boot  

但我还是遇到了这个问题..如果是证书问题或类似问题,我应该得到更明确的消息,对吧?

but I'm still getting the issue.. If it was a certificate issue or something similar, I should get a clearer message, right ?

编辑 3

我观察到,即使代理没有正确配置,我们也不会在日志中收到任何相关消息.例如,通过故意提供不正确的代理设置(例如不存在的代理主机),我们不会得到与配置正确值时不同的消息.这使得调试非常不方便.

What I observe is that even if the proxy is not configured properly, we don't get any relevant message in the logs. For instance, by providing intentionally an incorrect proxy settings (a non existing proxy host for instance), we don't get a different message than when configuring correct values. This makes it very inconvenient to debug.

我发现的另一个问题是,即使正确配置密码,当密码包含感叹号时,修改后的版本也可能传递给 SBT 启动器.我为此创建了一个问题:https://github.com/sbt/sbt/issues/3139.但即使解决了这个问题,我仍然面临问题.

One other I found, is that even when configuring password properly, a modified version may be passed to SBT launcher when password contains an exclamation mark. I've created an issue for this : https://github.com/sbt/sbt/issues/3139 . But even after solving that issue, I still face problems.

实际上有几个代理相关的开放问题:https://github.com/sbt/sbt/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20proxy

There are actually a couple of proxy related open issues : https://github.com/sbt/sbt/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20proxy

我现在正在寻找的一件事是配置代理存储库:http://www.scala-sbt.org/0.13/docs/Proxy-Repositories.html(我们使用 Nexus)

One thing I'm now looking out now is to configure a proxy repository : http://www.scala-sbt.org/0.13/docs/Proxy-Repositories.html (we use Nexus)

推荐答案

尽管我无法找到最初问题的明确答案,但我学到了一些东西:

Even though I haven't been able to find the definitive answer to my initial question, I've learned a few things :

SBT 日志记录不是很有帮助,同样的错误消息可能有很多实际的失败原因.

SBT logging is not very helpful, and the same error message could have dozens of actual reasons for failure.

取决于配置的依赖库(http:///www.scala-sbt.org/0.13/docs/Proxy-Repositories.html),SBT 将尝试各种 UR,基于各种命名约定(Ivy 和 Maven).这就是为什么有时 URL 根本不存在的原因.

Depending on the dependency repositories configured (http://www.scala-sbt.org/0.13/docs/Proxy-Repositories.html), SBT will try all kinds of UR, based on various naming conventions (Ivy and Maven). That's why sometimes the URL don't exist at all.

这篇关于首次使用 SBT - 在代理后面检索依赖项的问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆