我想使用 Maven 发布插件发布一个快照项目“foo-1.0-SNAPSHOT”。 该项目依赖于尚未发布的第三方模块“bar-1.0-SNAPSHOT”。
我在项目的 pom.xml 中使用选项“allowTimestampedSnapshots”来允许带时间戳的快照，但我假设第 3 方模块（bar）没有时间戳，除非我自己构建它，因为 Maven 仍然抱怨未解决的 SNAPSHOT 依赖项。
有没有办法发布项目 foo 而不管依赖的 SNAPSHOT 项目，如果没有，我如何向第 3 方项目添加时间戳？
i would like to release a snapshot project 'foo-1.0-SNAPSHOT' using the maven release plugin. The project depends on a 3rd party module 'bar-1.0-SNAPSHOT' which is not released yet.
I use the option 'allowTimestampedSnapshots' in my project's pom.xml to allow timestamped snapshots but i assume that the 3rd party module (bar) is not timestamped unless i build it myself as maven still complains about unresolved SNAPSHOT dependencies.
Is there a way to release the project foo regardless of dependent SNAPSHOT projects and if not how could i add a timestamp to the 3rd party project?
发布评论
评论（5）
问题在于
allowTimestampedSnapshots参数名称，它在文档中，但插件的源在表达式中使用不同的参数名称 -ignoreSnapshots。因此，只需使用
-DignoreSnapshots=true，发布插件的准备目标将忽略快照依赖项。Problem is with the
allowTimestampedSnapshotsparameter name, it's in the documentation but the plugin's source uses a different parameter name in expression -ignoreSnapshots.So just use
-DignoreSnapshots=trueand the prepare goal of the release plugin will ignore snapshot dependencies.在我的例子中，使用 maven-release-plugin 选项
而不是
帮助，这将允许使用快照版本的依赖项来准备和执行发布。
应非常小心地处理此选项，因为如果更新快照依赖项，在版本中使用快照版本可能会在以后破坏您的版本，这在正常情况下不是您想要的。
Using the maven-release-plugin option
instead of
helped in my case, this will allow to use dependencies with snapshot version to prepare and perform a release.
This option should be handled very carefully, because using snapshot versions in a release can later break your release, if the snapshot dependency is updated, which in normal case is not what you want.
简短的答案是参见以下答案....长的答案是你可以解决它。
我过去应对的唯一方法是有效地分叉第 3 方库并自行发布版本。 当然，说起来容易做起来难，如果库又大又复杂，那就很困难，如果第 3 方库是闭源的，那就不可能了。 更简单的方法可能是联系第 3 方并要求他们削减版本。
另一种选择可能是复制他们的 pom（确保它没有快照）更改版本信息并在存储库中手动安装 pom 和工件。
The short answer is see the following answer.... the long answer is you can work around it.
The only way I have coped in the past is to effectively fork the 3rd party library and cut a release myself. This of course is easier said than done and is just plain difficult if the library is large and complex and impossible if the 3rd party library is closed source. An easier route maybe to approach the 3rd party and ask them to cut a release.
Another option may be to copy their pom (ensure that it has no snapshots) change the version information and manually install the pom and artifact in your repository.
前面的答案建议更改组和工件 ID...不要这样做，因为稍后当此依赖项被释放时，maven 不会将其识别为相同的工件，并且您最终会在类路径上得到两个副本。 我的首选方法是仅更改版本，我会执行以下操作：[原始版本]-[我的组织名称]-[我从中提取的 svn 版本]，这样我会得到类似 1.0-SONATYPE-3425 的内容。 通过使用 svn rev，我总是可以再次拉取源代码并在需要时对其进行修补，并且确切地知道我正在使用什么，而无需将整个源代码拉入我自己的 svn 中。
更新 - 我 不久前在博客上讨论了这个问题。
The previous answer suggested changing the group and artifact id...don't do this as maven won't recognize it as the same artifact later when this dependency is released and you'll end up with two copies on the classpath. My preferred method is to change only the version and I'll do something like : [original version]-[my org name]-[svn version i pulled it from] so i get something like 1.0-SONATYPE-3425. By using the svn rev, i can always pull the source again and patch it if needed and know exactly what i'm using without pulling the whole source into my own svn.
Update - I blogged about this a while back.
只需使用您拥有的 pom 安装 jar 即可。 我通常会更改组和工件 ID，以明确这不是官方版本，但这通常是解决您的问题的最佳方法。
Just install the jar with a pom you own. I generally change the group and artifact id to make it clear that this is not the official version, but that's generally the best work around for your problem.