我们目前有一个项目设置，它使用Ivy进行依赖关系管理，使用Ant作为常规构建工具（虽然这可能与此不相关）。另外，我们有一堆用Maven构建的库，以及项目（我们有多个）依赖于它们。我们知道这种情况远非理想，我们正在评估改进方法，但我们无法像我们一样快速地改变这种情况。因此，我们必须与目前的工作合作。
无论如何，问题在于：它与Maven 2和Ivy一起工作但我们最近开始切换到Maven 3有几个原因（一个是更好的冲突解决方案），这种组合破坏了我们的构建。
首先，我将尝试描述我们的构建如何与Maven 2和Ivy一起使用。在此之后，我将添加切换到Maven 3时破坏的位置。
Ivy + Maven 2
在开发我们库的新版本时，我们使用SNAPSHOT版本，这些版本安装在本地Maven仓库（.m2）中。此外，我们将这些快照部署到Artifactory中，以便能够共享中间构建以实现某些并行开发。
然后我们的项目声明对这些快照的依赖。相应的ivysettings.xml如下所示：
<ivysettings>
<settings defaultResolver="default" />
<include url="${ivy.default.settings.dir}/ivysettings-local.xml" />
<resolvers>
<ibiblio name="public" root="path.to.our.artifactory" m2compatible="true" />
<filesystem name="local-maven2" m2compatible="true" checkmodified="true" changingPattern=".*SNAPSHOT">
<ivy pattern="${user.home}/.m2/repository/[organisation]/[module]/[revision]/[module]-[revision].pom" />
<artifact pattern="${user.home}/.m2/repository/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]" />
</filesystem>
<filesystem name="local" checkmodified="true" changingPattern=".*SNAPSHOT">
<ivy pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}" />
<artifact pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" />
</filesystem>
<filesystem name="local2" checkmodified="true" changingPattern=".*SNAPSHOT">
<ivy pattern="${user.home}/.ivy2/cache/[organisation]/[module]/ivy-[revision].xml" />
<artifact pattern="${user.home}/.ivy2/cache/[organisation]/[module]/[artifact]-[revision].[ext]" />
</filesystem>
<chain name="default" checkmodified="true" changingPattern=".*SNAPSHOT">
<resolver ref="local" />
<resolver ref="local-maven2" />
<resolver ref="public" />
</chain>
</resolvers>
<include url="${ivy.default.settings.dir}/ivysettings-shared.xml" />
</ivysettings>
由于这种设置，Ivy应该寻找更新版本的快照并正确解决。通过比较相应.pom文件的文件日期来识别较新版本。
当我们使用Maven 2构建快照时，相应的.pom将获取当前构建的文件日期，因此该检查可以正常工作，Ivy会解析正确的快照版本。
Ivy + Maven 3
使用Maven 3构建快照时，上述分辨率会中断。原因似乎是已安装的.pom文件没有将当前时间戳作为其文件日期，而是保留原始pom的文件日期。复制的xml。因此Ivy无法检测快照是否更新。
似乎Maven 3将更新时间戳存储在maven-metadata-local.xml中，但Ivy没有读取它们。我们知道有ibiblio解析器（我们正在使用它）但是根据我们所知道的（例如来自this之类的问题）它意味着可以使用真正删除的存储库并且在应用于本地时可能会产生问题.m2 repo。
我们还考虑过跟踪其他文件的文件日期，例如maven-metadata-local.xml或实际的工件，但我们不确定这是否明智或可能在其他情况下破坏构建。
那么我们应该如何解决这个问题呢？
TL; DR
使用Maven 3构建并部署在本地.m2 repo中的快照处理Ivy依赖关系的标准/建议方法是什么？
更新2016-07-26
以下是我试图解决这个问题的两件事，但我不确定是否会有任何我没有想到的副作用。如果有人能对此有所了解，我将不胜感激：
useOrigin="true"（以及可选的低defaultTTL）的缓存一起使用。这样，似乎只有xml文件存储在.ivy2缓存中，并且工件在.m2存储库中被引用，即它们没有被复制。
root="file://${user.home}/.m2/repository/"的ibiblio解析器，它似乎能够解析大多数工件（例外情况见下文），但在读取元数据时似乎仍然失败，即它没有用新版本更新缓存在.m2回购中找到的版本。file://{user.home}/.m2/repository/javax/enterprise/cdi-api/1.0/cdi-api-1.0.jar类似，即我直接从Windows资源管理器复制路径，它是"${user.home}\.m2\repository\javax\enterprise\cdi-api\1.0\cdi-api-1.0.jar"。答案 0 :(得分：4)
......我们知道这种情况远非理想，我们正在评估 如何改进，但我们可以......
在我的经历中完全正常。许多大公司都有许多项目，包括ANT，Maven和越来越多的Gradle。
以下是我要提出的一些建议
集成这些不同技术的最佳方法是运行一个中间存储库来保存所有构建输出。这将有效地将您的构建步骤与以后使用二进制文件的方式分离。
推荐的存储库技术是Maven存储库（此时是Java标准），您可以选择可用于托管存储库的开源技术：
虽然运行额外的服务器可能看起来是一个开销，但随着依赖项目数量的增加（单个大型共享文件系统无法扩展），它会在黑桃中回报。
在任何情况下，您都需要拥有发布二进制文件的参考副本。这些Maven存储库管理器允许您控制项目消耗的第三方依赖项，并帮助缓存文件，这实际上会减少构建时间并简化共享依赖项管理。
最后，如何配置使用Maven存储库的ivy构建？如下使用ibiblio解析器（您将发现所有现代Java构建工具都具有对本地Maven存储库的类似支持）
<ivysettings>
<settings defaultResolver="myrepo"/>
<resolvers>
<ibiblio name="myrepo" m2compatible="true" root="http://myrepo.com/path/to/repo"/>
</resolvers>
</ivysettings>
Snaphot版本是Maven引入的一个概念，它是一个自以为是的构建框架。在我看来，使用它们时应该非常慎重：
正如您所发现的快照不断变化，并且在与期望不断变通的测试（如QA）的群体共享时无法依赖快照。
我对此的看法是由以下帖子讨论的，该帖子讨论了Maven的发布管理方法：
最后，虽然我建议将快照的使用限制在密切合作的团队中，但常春藤确实支持他们，但他们的使用只有一些众所周知的限制。因为他们是Maven构造，所以他们并不是100％得到其他构建技术的支持。这是Repository manager真正帮助的地方，因为他们能够重新生成正确的元数据以支持快照发布：
希望这有帮助。