常春藤:使用不在本地存储库中的Jar版本

时间:2012-11-09 17:28:55

标签: ant publish ivy

这实际上是两个问题,但来自同一个问题:

  • 我们使用Jenkins作为持续集成系统。每当有人提交更改时,Jenkins都会构建它。
  • 我们使用公司Maven存储库(Artifactory),我们构建的所有其他项目所需的jar都存储在那里。
  • 我使用Jenkina中的 Promotion Plugin 推广 Jenkins构建。当我提升构建时,我使用mvn deploy:deploy-file命令将该构建中的jar及其关联的POM部署回我们的公司Maven存储库。
  • 我们实际上将Ivy与Ant一起使用,但仍然使用我们的Maven存储库。

出现了一个问题。开发人员正在开发Project B ,它使用由Project A 构建的jar。开发人员更改Project A ,然后想在他们的Project B 中使用该更改的jar。


第一个问题

我认为我可以使用<ivy:publish>将该jar传递到该计算机的本地存储库中。然后,当该开发人员进行构建时,它将使用该版本的jar而不是我们公司存储库中的jar。

但是,我设置Ivy的方式是ivysettings-public.xml checkmodified 设置为 true 。这意味着如果存储库具有不同版本的jar,即使它已经在本地存储库中,它也会下载它。这如何影响开发人员将jar发布到本地存储库的能力?

当Ivy解析依赖项时,它是否注意到本地计算机上的依赖项与公共存储库中的依赖项不同,因此它将始终下载公共jar,或者Ivy是否使用时间戳?也就是说,Ivy会看到本地jar上的时间戳比公司存储库中jar的时间戳更新,因此不会下载公司存储库中的时间戳。

如果需要,我可以将 checkmodified 重置为 false ,但我必须让开发人员知道他们需要在常规上清理常春藤缓存获得最新版罐子的基础。

第二个问题

如何处理可能影响其他项目的基础罐变化问题?

在我目前的模型中(我做的假设),我期望将这些罐子放入我们的公司Maven存储库中的某种工作流程。有人会创建一个问题,它将通过一个工作流,我会将该jar部署到我们的Maven存储库中。

然而,这可能只是限制性太强。也许基础罐的部署(特别是当有很多开发工作正在进行时)应该有点宽松。

  • 我可以坚持这个工作流程模型。我是CM,我的话是法律。但是,我要做好准备,这样开发人员就可以完成自己的工作,而不是遵循一堆无意义的程序。
  • 我可以让项目负责人进行部署,而不是问我。通过这种方式,他们可以确定(并承担责任)他们推广的罐子的质量。
  • 我可以设置,所以Jenkins会在某些条件下自动推广罐子(就像他们通过所有单元测试一样)。我甚至可以将它与手动部署相结合:开发人员可以推广jar,但只能通过单元测试。并且,我甚至可以设置它,因此即使单元测试没有通过,项目负责人(或仅仅是我自己)也可以宣传一个罐子。

最后,我在我们公司设置了Ivy,因此我可以完全控制ivysettings.xml所有项目(我们使用svn:externals将Ivy引入所有项目中。)

我可以做的一件事是设置第二个快照存储库。完成Jenkins构建后,可以将jar自动部署到此 snapshot 存储库。我可以允许开发人员将Ant属性传递给构建(通过命令行或通过build.properties文件),这将允许开发人员在之前使用来自 snapshot 存储库的jar。 发布存储库。

Jenkins可以设置为始终将新构建的jar部署到此 snapshot 存储库,bur。我仍然会将jar的部署控制到我们的发布存储库中。官方(Jenkins)构建将始终使用发布存储库,但开发人员可以根据需要使用快照

1 个答案:

答案 0 :(得分:0)

我们在Maven中再次领先,并在每次构建时创建 snapshot 版本。我为每个通过pom-snapshot.xml任务构建的jar创建pom.xml<ivy:makepom/>

我有两个促销活动:一个推广快照版本,另一个推广发布版本(真的是同一个jar)。快照促销在每次成功构建后运行。发布促销手动进行。这样,我们可以将jar提升到我们的发布库中,但仍允许开发人员使用最新的jar。