Question

My Maven项目依赖于非Maven库，它被编码为系统依赖项：

<dependency>
  <groupId>com.example</groupId>
  <artifactId>foo</artifactId>
  <version>${foo.version}</version>
  <scope>system</scope>
  <systemPath>${foo.jar}</systemPath>
</dependency>

可以通过本地属性控制库的位置：

<properties>
  <foo.version>2.1.1</foo.version>
  <foo.basedir>/usr/local</foo.basedir>
  <foo.libdir>${foo.basedir}/lib</foo.libdir>
  <foo.jar>${foo.basedir}/java/foo-${foo.version}.jar</foo.jar>
</properties>

最近，库从版本2.1.1切换到版本2.2.0，所以我更改了foo.version属性，但Maven似乎停留在旧版本上：

...
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

Missing:
----------
1) com.example:foo:jar:2.1.1
...

我已经运行mvn dependency:purge-local-repository（实际上很多次）。字符串2.1.1不会出现在我的POM profiles.xml或settings.xml中的任何位置。不过，每次我尝试构建我的项目时，Maven都会因上述错误而失败。

这里发生了什么？ Maven在哪里存储依赖版本信息以及如何更新它？

Answer 1

我认为${foo.version}可能会被解析为过滤属性。您可以查看src/main/filters下的属性文件。

不确定这是否确实是问题，只是试一试并更新回来。

我能想到的另一个原因是 - com.example:foo:jar:2.1.1可能存在传递依赖。这是一些需要2.1.1版本此工件的其他依赖项。通过执行mvn dependency:tree

，您可以找到传递过多的工件

Answer 2

你知道吗。看到@Chris Conway找到的解决方法，我认为只需运行mvn clean就可以“解决”这个问题。

即使它在这里没有帮助，当发生奇怪的事情时，总是值得尝试mvn clean。

Answer 3

依赖版本冲突是一个非常常见的问题，大多数情况下，当我们开始构建应用程序时，除非我们的应用程序以意想不到的方式开始运行或者开始出现异常，否则我们从不关注或一般都忘记了这个方面。

对于那些有兴趣了解依赖冲突产生原因以及如何在我们的应用程序中避免它们的SO的读者和访问者，我发现这里的来源以精确的方式解释，所以我想添加我的2位到它。

http://techidiocy.com/maven-dependency-version-conflict-problem-and-resolution/

干杯

Maven坚持使用旧版本的系统依赖

3 个答案: