当前位置: 首页 > 知识库问答 >
问题:

Maven如何解析存储库中的快照版本

经兴安
2023-03-14

我正在开发一个服务器,它承载一个maven repo,并且面临一个问题,即如果快照不是特定格式,maven会错误地解析快照版本。在查找版本规则之后,我知道限定符可以是任何字符串,所以我希望maven能够下载带有任何限定符的依赖项。然而,这与我的经验不符。

回购协议具有以下文件夹结构(假设maven项目a.b.c:a.b.c.d:1.0.0-SNAPSHOT):

<repo-root>
|-a
 |-b
  |-c
   |-a.b.c.d
    |-maven-metadata.xml
    |-1.0.0-SNAPSHOT
     |-a.b.c.d-1.0.0-20190213.120000-1.jar
     |-maven-metadata.xml

如果我尝试解析a. b. c. d-SNAPSHOT,这很好。我可以在maven日志中看到它查找a/b/c/a. b. c. d/1.0.0-SNAPSHOT/maven-metadata.xml,然后下载正确的JAR文件。到目前为止还不错。

但是如果我将限定符更改为其他内容(例如删除末尾的-1),maven将无法解析文件!而不是寻找

<repo-root>/a/b/c/a.b.c.d/1.0.0-SNAPSHOT/<jar-file>

(这将是正确的),它看起来

<repo-root>/a/b/c/a.b.c.d/1.0.0-20190213.120000/<jar-file>

这显然是错误的。这种情况发生在每个不符合格式的限定词上

\d\.\d\.\d-\d{8}.\d{6}-\d+

为什么Maven不能解决这样的限定条件?是在某个地方指定了格式,还是这只是一个maven bug?

共有1个答案

江渊
2023-03-14

一般来说,Maven版本可以是任何字符串(如1.2.3-RELEASE1-1456dontknown)。以-SNAPSHOT结尾的版本具有特殊含义,即它们是针对最新的构建版本解析的。

一个特定SNAPSHOT的不同版本(如1.0-SNAPSHOT)由您在问题中提到的时间戳来区分。我不知道这种格式是否真的是“Maven标准”,但我想是的,因为它在所有常见的存储库管理器中都是相同的,并且您在不使用它时遇到了问题。我强烈建议不要使用不同类型的时间戳,即使您使其工作,因为每个Maven插件的期望是时间戳SNAPSHOT版本都有一个定义和给定的格式(无论这是否是“官方”)。

顺便说一下:我很想知道你为什么要开发自己的Maven存储库。

 类似资料:
  • 我有一个teamcity项目,它成功地将快照工件部署到我们的artifactory实例中。我好像没法让maven把那些神器拉下来。我可以用时间戳而不是快照在artifactory中看到它们,但我似乎无法让maven使用时间戳请求它们。我真的不知道该去哪找。我注意到TeamCity上载的工件没有,而其他手动上载的工件有和。这有关系吗? 我曾多次尝试删除,所以这不是缓存问题。 下面是中的一个片段: 我

  • 问题内容: 我们正在尝试将Archiva用作中央和其他外部存储库的Maven代理,以及用作我们的工件的快照存储,这些工件由Hudson从SVN自动构建并安装到快照存储库。 我无法将Maven客户端设置为同时使用内部存储库和快照存储库。我的项目有一些外部依赖项(例如),可以从Archiva内部存储库中正确下载。另外,我的项目还依赖于自己的项目,该项目的工件已经构建并安装到快照存储库中。但是,如果我尝

  • 我有一个本地的artifactory存储库。我在应用程序的pom.xml中有一个依赖项,如下所示: 我在我的“ext-local-snapshot”存储库中部署了一个activequant-p2-1.3-snapshot.jar。Artifactory将其部署在org/activequant/activequant-p2/activequant-p2-1.3-20130925.170928.jar

  • https://maven.java.net/content/repositories/public/com/oracle/avatar-js/0.10.25-SNAPSHOT/有罐子 和中的dllhttps://maven.java.net/content/repositories/public/com/oracle/libavatar-js-win-x64/0.10.25-SNAPSHOT/

  • 我试图在maven项目中使用外部库。由于我希望在任何机器上构建项目,所以我不希望使用 存储库(当依赖项在本地< code>.m2存储库中不可用时工作)结合工作,并且第二部分在每次构建期间刷新< code>.m2。 但是,我仍然不清楚为什么普通的“快照”机制不起作用(即,当前的脏解决方案在没有快照的情况下也能工作,因为本地< code>.m2 repo每次都显式更新)。有没有更干净的方法? 解决方案