Maven - Archiva - 针对不同地理位置设置 Archiva

发布于 2024-08-03 19:50:56 字数 194 浏览 9 评论 0原文

我们的开发人员在不同的地理位置工作,我们希望为每个地理位置设置 Archiva(只是为了确保获取工件的往返次数更少)。

是否有可能每当从位于 G1 的 Archiva 上传/删除工件时,相同的更改就会被推送到位于 G2G3等等?

We have developers working in different geographic locations and we want to set up Archiva for each of those geographic locations (just to make sure that the round trip in getting the artifacts is less).

Is it possible that whenever an artifact is uploaded/deleted from Archiva at location G1 then the same change gets pushed to Archiva managed repository at location G2, G3 and so on?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

挖个坑埋了你 2024-08-10 19:50:56

这并不完全是您所要求的,但最终效果对于系统用户来说是相同的,因此值得研究。

您可以使用代理连接器<将Archiva设置为代理远程存储库/a>.
使用此机制,您可以将 G2 配置为具有 G1 的代理,这意味着当任何工件部署到 G1 时,它都可以通过代理机制在 G2 上使用。

从文档中:

代理连接器用于将托管存储库(存储在 Archiva 计算机上)链接到远程存储库(通过 URL 访问)。这意味着当托管存储库收到请求时,将咨询连接器来决定是否应该从远程存储库请求资源(并可能在本地缓存结果以供将来请求)。

每个托管存储库都可以代理多个远程存储库,以允许通过 Archiva 实例内的单个接口对存储库进行分组。例如,通常通过 Archiva 的单个存储库以及所有远程快照存储库的单个快照存储库来代理所有远程版本。

基本的代理连接器配置只是将远程存储库链接到托管存储库(使用可选的网络代理来通过防火墙进行访问)。但是,不同类型的工件和路径的行为可以由代理连接器专门管理,以便更灵活地控制对远程存储库的访问。


如果代理连接器不适合您,您可以考虑替代复制方法。我会重新考虑,因为任何本土解决方案都可能在用户修改存储库内容时引入问题。

  • 只要您只允许部署到其中一个节点,您就可以使用 rsync 或 robocopy 在节点之间复制存储位置。
  • 您可以编写一个自定义插件来侦听获取和删除事件并向另一个节点触发相应的事件。

This isn't exactly what you asked for, but the net effect is the same to the users of the system so it is worth looking into.

You can set Archiva up to proxy remote repositories by using proxy connectors.
Using this mechanism you could configure G2 to have a proxy of G1, this means when any artifact is deployed to G1, it would be available at G2 via the proxy mechanism.

From the documentation:

A proxy connector is used to link a managed repository (stored on the Archiva machine) to a remote repository (accessed via a URL). This will mean that when a request is received by the managed repository, the connector is consulted to decide whether it should request the resource from the remote repository (and potentially cache the result locally for future requests).

Each managed repository can proxy multiple remote repositories to allow grouping of repositories through a single interface inside the Archiva instance. For instance, it is common to proxy all remote releases through a single repository for Archiva, as well as a single snapshot repository for all remote snapshot repositories.

A basic proxy connector configuration simply links the remote repository to the managed repository (with an optional network proxy for access through a firewall). However, the behaviour of different types of artifacts and paths can be specifically managed by the proxy connectors to make access to remote repositories more flexibly controlled.


If proxy connectors won't work for you, you could look into alternative replication approaches. I would reconsider though as any homegrown solution is likely to introduce issues as users modify the repository contents.

  • As long as you only allow deployment to one of the nodes, you can use rsync or robocopy to replicate the storage location between the nodes.
  • You can write a custom plugin that listens for the get and delete events and fires a corresponding event to the other node.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文