Apache Ivy和本地Maven repo - 如何处理使用Maven 3构建的快照

Tho*_*mas 7 java ant ivy maven-3

我们目前有一个项目设置,使用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>
Run Code Online (Sandbox Code Playgroud)

由于这种设置,Ivy应该寻找更新版本的快照并正确解决.通过比较相应.pom文件的文件日期来识别较新版本.

当我们使用Maven 2构建快照时,相应的.pom将获取当前构建的文件日期,因此该检查有效,Ivy会解析正确的快照版本.

Ivy + Maven 3

使用Maven 3构建快照时,上述分辨率会中断.原因似乎是安装的.pom文件没有将当前时间戳作为其文件日期,而是保留复制的原始pom.xml的文件日期.因此,Ivy无法检测快照是否更新.

似乎Maven 3将更新时间戳存储在maven-metadata-local.xml中,但Ivy不会读取它们.我们知道,有是ibiblio上解析器(我们使用的),但是(从这样的问题如accoring我们所知道的这个)是指与工作真正删除存放,当被应用到本地回购.m2目录下可能产生的问题.

我们还考虑过跟踪其他文件的文件日期,例如maven-metadata-local.xml或实际的工件,但是我们不确定这是否明智或者是否会在其他情况下破坏构建.

那么我们应该如何解决这个问题呢?

TL; DR

在使用Maven 3构建并部署在本地.m2 repo中的快照上处理Ivy依赖关系的标准/建议方法是什么?

更新2016-07-26

以下是我试图解决这个问题的两件事,但我不确定是否会有任何我没想到的副作用.如果有人能对此有所了解,我将不胜感激:

  1. 将文件系统解析程序用于本地.m2存储库,但与具有useOrigin="true"(并且可选地具有低defaultTTL)的高速缓存一起使用.这样,似乎只有xml文件存储在.ivy2缓存中,并且工件在.m2存储库中被引用,即它们不被复制.

    这似乎有效,但我不确定如果第一次查找将从共享快照存储库(Artifactory)下载快照,并且稍后将通过本地构建更新这些快照.在这种情况下,我们最终可能会在.ivy2中缓存工件的远程版本,并且在.m2中安装较新版本,两种情况下的.pom文件日期都相同.
  2. 使用root="file://${user.home}/.m2/repository/"似乎能够解析大多数工件的ibiblio解析器(例外见下文),但在读取元数据时似乎仍然失败,即它不会使用.m2中找到的较新版本更新缓存回购.

    虽然能够解析.m2 repo中的大多数工件,但是file://{user.home}/.m2/repository/javax/enterprise/cdi-api/1.0/cdi-api-1.0.jar当工件存在时,我似乎得到了几个"url"的分辨率错误,即我直接从Windows资源管理器复制了路径,它就是"${user.home}\.m2\repository\javax\enterprise\cdi-api\1.0\cdi-api-1.0.jar".

Mar*_*nor 5

...我们知道这种情况远非理想,我们正在评估改善这种情况的方法,但我们可以...

根据我的经验,这是完全正常的。许多大公司都有大量混合使用 ANT、Maven 和越来越多的 Gradle 构建的项目。

以下是我提出的一些建议

使用存储库管理器

集成这些不同技术的最佳方法是运行一个中间存储库来保存所有构建输出。这将有效地将您的构建步骤与二进制工件随后的使用方式分离。

推荐的存储库技术是 Maven 存储库(目前为 Java 标准),您可以选择可用于托管存储库的开源技术:

虽然运行额外的服务器可能看起来是一种开销,但随着依赖项目数量的增加(拥有单个大型共享文件系统无法扩展),它会带来巨大的回报。

无论如何,您都需要拥有发布二进制文件的参考副本。这些 Maven 存储库管理器允许您控制项目使用的第 3 方依赖项,并有助于缓存文件,这实际上会减少构建时间并简化共享依赖项管理。

最后,如何配置使用 Maven 存储库的 ivy 构建?使用ibiblio解析器如下所示(您会发现所有现代 Java 构建工具都对本地 Maven 存储库具有类似的支持)

<ivysettings>
    <settings defaultResolver="myrepo"/>
    <resolvers>
        <ibiblio name="myrepo" m2compatible="true" root="http://myrepo.com/path/to/repo"/>
    </resolvers>
</ivysettings>
Run Code Online (Sandbox Code Playgroud)

谨防快照发布

快照发布是 Maven 引入的一个概念,Maven 是一个固执己见的构建框架。在我看来,使用它们时应该非常慎重:

正如您所发现的,快照不断变化,在与希望测试(如 QA)保持不变的团队共享时不能依赖快照。

我对此的想法是由以下讨论 Maven 发布管理方法的帖子形成的:

最后,虽然我建议将快照的使用限制在密切合作的团队中,但 ivy 确实支持它们,但它们的使用存在一些众所周知的限制。因为它们是 Maven 构造,所以其他构建技术并不 100% 支持它们。这是存储库管理器真正提供帮助的地方,因为它们能够重新生成正确的元数据以支持快照发布:

希望这可以帮助。