我理解设置 Maven 镜像的部分吸引力,如下所示:
<mirror>
<id>nexus</id>
<name>Maven Repository</name>
<mirrorOf>*</mirrorOf>
<url>http://server:8081/nexus/content/groups/public</url>
</mirror>
... 是 文档 指出:
您可以通过让 Maven 镜像所有存储库请求来强制 Maven 使用单个存储库。
然而,这是否也表明通过设置*
镜像,每个工作站必须被迫通过镜像?
我之所以这么问,是因为我希望每个工作站能够进行故障转移,并在 Nexus 无法解析依赖项或插件的情况下直接连接到它所知道的任何公共存储库。 (在完美的世界中,每个开发人员都具有根据需要添加其他代理存储库所需的访问权限。但是,有时该访问权限不可用;有时 Nexus 服务器出现故障;有时会遇到 Java 堆错误。)
这是“镜像”吗 ?但继续直接连接到公共存储库” Maven 2 中可能的故障转移配置吗?会在 Maven 3 中吗?
I understand that part of the appeal of setting up a Maven mirror, such as the following:
<mirror>
<id>nexus</id>
<name>Maven Repository</name>
<mirrorOf>*</mirrorOf>
<url>http://server:8081/nexus/content/groups/public</url>
</mirror>
... is that the documentation states:
You can force Maven to use a single repository by having it mirror all repository requests.
However, is this also an indication that by having a *
mirror set up each workstation must be forced to go through the mirror?
I ask because I would like each workstation to failover and connect directly to whatever public repositories it knows about in the event that Nexus can't resolve a dependency or plugin. (In a perfect world, each developer has the access necessary to add additional proxy repositories as needed. However, sometimes that access isn't available; sometimes the Nexus server goes down; sometimes it suffers a Java heap error.)
Is this "mirror but go ahead and connect directly to public repos" failover configuration possible in Maven 2? Will it be in Maven 3?
发布评论
评论(4)
不,没有故障转移模式。您可以使用
*,!repository
排除某些存储库进入镜像,或者您可以有两个settings.xml
文件行为不同,并根据需要使用--settings
进行切换。No, there's no failover mode. You can exclude some repositories from ever going to the mirror with
<mirrorOf>*,!repository</mirrorOf>
, or you can have twosettings.xml
files that will behave differently and switch using--settings
if needed.这在 Maven 2 中是不可能的。将来在 Maven 3 中可能是可能的。我们也考虑过在 Nexus 中添加这种可能性来动态代理工件。最重要的是,大多数组织都希望控制开发人员使用的代理存储库,因此该功能在存储库管理器中非常受欢迎。
出于同样的原因,让开发人员机器从访问存储库管理器直接回退到直接存储库也是不可取的。然后你最终会失去代理缓存、共享、过滤等所带来的所有好处。
It's not possible in Maven 2. It may be possible in the future in Maven 3. We have also considered adding this possibility in Nexus to dynamically proxy artifacts. The bottom line is that most organizations want control over the proxy repos used by developers and so this feature turns out to be very popular in a repo manager.
For the same reason, having developer machines directly fall back from accessing the repo manager to the repos directly is not desirable. Then you end up losing all the benefits of proxy caching, sharing, filtering etc that you get.
一个答案(隐含在我的问题中)是,这在设计上是不可能的。 Jason Van Zyl 在这张票末尾的评论表明:
One answer (implicit in my question) is that this isn't possible by design. The comment at the end of this ticket by Jason Van Zyl indicates that
这种配置也是可以的。它工作得很好,但有一个困难的情况,如果项目层次很大并且并非所有子项都有相同的父项,您甚至必须将此部分复制到他们的 poms 中。这意味着除了声明这个假中央库(默认要查看的存储库)的项目之外,您的请求将发送到正确的 Maven 中央库或项目 pom.xml 中的其他声明的存储库。
CATCH:你使用插件 X —— 也许实际上并没有意识到它 —— 并且插件 X 依赖于工件 Y,它在它自己的 pom 中声明了 repo....>>>>>无法控制将所有依赖项请求代理到 nexus
另一种选择是为项目提供额外的 settings.xml 并“提供”它 $mvn -s settings.xml
第三种选择是使用全局 settings.xml 如下,并仅激活 -P nexus当需要时,因为没有假的中央存储库,它的工作效果令人惊讶。
在另一个选项卡/窗口中打开图像。
This configuration is possible too. It works great, there is one tough situation though , if the project is hierarchically big and not all children have the same parent, you'd have to copy over this section even to their poms. It means that everywhere else than in project that declares this fake central, that is default repo to look at, your request will go to proper maven central or to other declared repositories in the project's pom.
CATCH: you use plugin X -- and maybe are not aware of it actually -- and plugin X depends on artifact Y, that in it's own pom has repo declared.... >>> no control over proxying all requests for dependencies to nexus
Another alternative is having an extra settings.xml for projects and "supply" it $mvn -s settings.xml
Third alternative is having global settings.xml as follows, and activate -P nexus only when needed, cause without fake central repository it is surprisingly working.
Open the image in another tab/window.