Question

我们已经使用了常春藤几个月，并在办公室的网络服务器上拥有我们自己的托管“Ivy Repo”。我们所有的项目都配置为使用此repo来解决依赖关系。

我们的许多项目都使用了几种“公共”类型的JAR。因此，并且因为我们只有1个回购，我们发现以下情况会产生很多丑陋的开销：

开发人员有一项任务是向Project 1添加一个功能（取决于Common jar）
在开发Project 1的过程中，开发人员意识到他/她需要对Common jar进行更改
常见的jar更改
常见的jar必须经过代码审查和正常的代码推广
Build master发布新的Common jar
项目1可以在Common jar更新后继续开发

这对我们的团队来说变得荒谬可笑。

对我来说，显而易见的解决方案是在每个项目中提供ant目标，允许开发人员在本地发布/解析（进出文件系统）。通过这种方式，他们可以通过星期日的方式打破常见的jar方式，但在等待Common发布时不会丢失2到4天。这样，开发人员对Project 1和Common进行了本地更改，代码一次性完成了我们的升级过程。

我知道这对Ivy来说是可能的，但是我很陌生，我甚至不知道从哪里开始。

目前，我们为所有项目使用全局ivy.settings文件。在设置文件中，我们使用一个链式解析器，里面有1个url解析器，它连接到我们的“ivy repo”。

我相信以下是唯一必要的改变，但我不是百分百肯定：

在ivy.settings中，我们需要在调用url解析器之前添加本地文件系统解析器;这样我们在转到常春藤仓库（Web服务器）

之前检查本地文件系统的依赖关系
使用允许本地缓存发布的选项配置每个项目的ivy.xml

调整Ant版本以使publish-locally目标行使上述选项

我相信这些更改将允许我们：（1）在查找Web服务器之前始终在本地查找依赖项，（2）在本地发布作为构建选项（目标）。

如果不是这样，或者我错过了任何步骤，请指教！否则，我可能会弄清楚如何从常春藤文档中添加文件系统解析程序，但不知道如何让publish-locally目标发挥作用。有任何想法吗？提前谢谢！

Answer 1

我也更喜欢马克斯的方法。

至于publish-locally，您可以告诉发布任务使用哪个解析器（resolver="local"）。这样它就可以发布到本地文件系统或任何已定义的解析器。

<ivy:publish 
        resolver="local" 
        overwrite="true"
        revision="${project.version}">  
        <artifacts pattern="dist/[artifact]-[revision].[type]" />
    </ivy:publish>

如果您使用链式解析器，则应设置returnFirst="true"，以便在本地找到某些内容时停止解析。

Answer 2

Ivy支持动态修订：

稳定的代码将引用最新批准的commons jar版本：

<dependency org="my-org" name="commons" rev="latest.release"/>

不稳定（开发中）代码会引用最新未经批准的代码版本

<dependency org="my-org" name="commons" rev="latest.integration"/>

因此，您需要将commons模块的构建过程更改为具有两个发布目标。一个用于代码的不稳定快照，另一个用于正式版本。

（请参阅常春藤publish任务的状态属性）

注意：在Maven中，您有两种类型的存储库，发行版和快照。常春藤对这个概念的支持更加微妙，更强大恕我直言。

常春藤：在本地解析和发布JAR

2 个答案: