令人郁闷的maven

今天我用maven编译一个程序的时候,死活过不去。老说jms的jar包下载不下来。

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.407s
[INFO] Finished at: Wed Sep 05 17:38:58 CST 2012
[INFO] Final Memory: 3M/15M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project logconsumer: Could not resolve depende
ncies for project com.sunchangming:logconsumer:jar:0.0.1-SNAPSHOT: The following
artifacts could not be resolved: javax.jms:jms:jar:1.1, com.sun.jdmk:jmxtools:j
ar:1.2.1, com.sun.jmx:jmxri:jar:1.2.1: Could not transfer artifact javax.jms:jms
:jar:1.1 from/to java.net (https://maven-repository.dev.java.net/nonav/repositor
y): No connector available to access repository java.net (https://maven-reposito
ry.dev.java.net/nonav/repository) of type legacy using the available factories W
agonRepositoryConnectorFactory -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyReso
lutionException

这个程序唯一的maven依赖就是log4j。

然后我就去查,那个"No connector available to access repository java.net"到底是因为什么?我开始以为是https的问题,后来想,该不会是被gfw了吧?最后发现,原来是因为https://maven-repository.dev.java.net/nonav/repository 这个域名已经无法解析了。

原来是这样,在log4j 1.2.15版本中,引用了这样一个repos

<repository> 
          <id>java.net</id> 
          <url>https://maven-repository.dev.java.net/nonav/repository</url> 
          <layout>legacy</layout> 
</repository>

要从它这里面下载jms。

但是,这个域名,它失效了! maven并没有报告域名解析异常,而是说没有可用的Connector。神啊!鬼才知道你那异常日志代表什么。解决办法很简单:把log4j的版本换成1.2.16或者1.2.17就可以了。

当然,今天还有郁闷的。

我让一个proxy程序在localhost的5800端口监听。然后让securecrt去连它(localhost:5800)。结果发现,连不上!原因最后发现,是因为我那个proxy程序太老,不支持ipv6,所以就在127.0.0.1端口上监听了。 而windows8默认把localhost给解析成了"::1"。而SecureCRT太新,它支持ipv6,于是就去连接"::1"的5800端口。于是就失败了。囧啊!

此博客中的热门博文

在windows下使用llvm+clang

少写代码,多读别人写的代码

tensorflow distributed runtime初窥