<dependency>
<groupId>com.test</groupId>
<artifactId>fooLib</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
....
<repository>
<id>in-project</id>
<snapshots>
<updatePolicy>always</updatePolicy>
<enabled>true</enabled>
</snapshots>
<name>In Project Repo</name>
<url>file://${project.basedir}/libRepo</url>
</repository>
问题是当我更换libRepo中的jar(没有更新版本号,因为它只是另一个快照)没有使用这个更新的jar(而是使用.m2目录的旧版本),即使对于mvn -U clean install
如何让maven更新这个jar？
编辑：
根据What exactly is a Maven Snapshot and why do we need it? maven将尝试找到永远不会发布的SNAPSHOT依赖版本,“即使在本地存储库中找到了这个库的版本”.我的设置有什么问题？
肮脏的解决方案：
根据Maven 2 assembly with dependencies: jar under scope “system” not included的答案,我的原始解决方案的扩展似乎工作：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>hack-binary</id>
<phase>validate</phase>
<configuration>
<file>${repo.path.to.jar}</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.test</groupId>
<artifactId>fooLib</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
</executions>
</plugin>
正如对该解决方案的评论中所提到的,它不能单独工作,因此它与项目内存储库(当依赖在本地.m2存储库中不可用时工作)一起工作,而第二部分在每次构建期间刷新.m2.
然而,我仍然不清楚为什么普通的“SNAPSHOT”机制不起作用(即当前的脏解决方案也可以在没有SNAPSHOT的情况下工作,因为本地.m2 repo每次都被明确更新).有没有更干净的方式？
解决方案(基于Aaron的回答和讨论)：问题是我尝试使用install-file将文件安装到libRepo中.实际的解决方案是,如果库更新,请使用
mvn deploy:deploy-file -Dfile=fooLib.jar -DgroupId=com.test \
-DartifactId=fooLib -Dversion=1.0-SNAPSHOT -Dpackaging=jar \
-Durl=file://..\libRepo -DrepositoryId=in-project
将其部署到回购.正确部署后,maven正确处理SNAPSHOT.
解决方法
顺便提一下,为此目的在内部为快照分配了一个版本号：这样Maven就可以在内部注意到快照已经更新.
我建议改用system dependency.这样,实际的JAR将被添加到类路径中(没有任何复制或东西).您也不需要复制此方法的repo结构,它将清楚地传达您的意图.
[编辑]我知道Maven以不同的方式处理与范围系统的依赖关系.我不确定这是否有意义(如果它使用依赖项进行编译,它肯定可以用它来运行？)
在我看来,你有这些选择：
>使用deploy:deploy-file将依赖项安装到libRepo中,而不是自己复制它.这应该以这样的方式更新元数据：当您在真实项目上再次运行mvn install时,Maven将再次复制它.
请注意file：install不起作用.文件插件用于访问本地存储库,但您需要使用知道如何更新共享/服务器存储库的deploy插件.>将依赖项安装到本地存储库中;我建议你使用一个脚本,你可以包含在你的项目中.这样,您可以避免所有问题,并且可以轻松地在新机器上进行设置.>更改依赖项的版本号,但这很乏味,当依赖项的实际版本号发生更改时,您可能会遇到麻烦.>为您的公司设置本地仓库服务器并将依赖关系部署到该公司.这将需要几个小时,但a)您将获得所有依赖项的本地缓存,使您的初始构建更快,b)它将更快地为其他开发人员设置.
