我在Azure DevOps中建立了一个Gradle构建，它在Azure DevOps git存储库中编译代码，然后将生成的JAR（作为Maven工件）发布到Azure Artifacts，如here所述。然后，其他Azure DevOps git存储库中的代码可以引用这些组件作为依赖项。对于这些组件的正式发行版（具有唯一的版本号），这很好，但是我还需要一种方法来使其在进行中的快照发行版中起作用。问题是我不能多次发布具有相同版本号（例如1.2.3-SNAPSHOT）的工件。这似乎是因为packages in Azure are immutable。
根据我的理解，这意味着Azure工件无法用于存储正在进行的快照工件。正确吗？
如果是，是否还有其他替代方法仍在使用Azure DevOps？我可以publish artifacts to Azure Blob Storage看到，但是大概这是您必须在现有的Azure Artifacts使用之上付出的代价。我还可以看到有很多GitHub Maven plugins可以将GitHub存储库视为Maven存储库，但是我找不到使用Azure DevOps存储库作为发布Maven工件的地方类似的东西。
以防万一，我在说的是基于云的Azure东西，不在本地。
答案 0 :(得分：0)
程序包管理的前提是程序包是不可变的。这将启用一大堆原本不存在的缓存选项。程序包存储在本地程序包缓存中，可能存储在代理供稿程序包缓存中，所有这些元素均假定具有相同名称和版本的程序包保持不变，并且将提供缓存的版本，而不是您推送的最新版本。大多数包装系统都是在此前提下构建的，包括Nuget和NPM。
创建开发快照的技巧是使用语义版本控制，并在您的版本中添加一个唯一的后缀。例如，1.2.3-SNAPSHOT.1后跟1.2.3-SNAPSHOT.2，有一些适用于Azure Pipelines的工具，例如GitVersion，它们可以自动生成唯一的版本+后缀，您可以将其传递到工件的版本中。 / p>
如果您不想“弄乱”您的主程序包提要，则可以出于开发目的设置另一个提要，其中包含所有中间包，然后您可以将其中一个程序包升级到您的主提要中，或者可以运行特定的管道（配置）以将最终软件包推送到用于稳定软件包的Feed中。
答案 1 :(得分：0)
看起来这主要是一个功能，而不是保留构建结果不变性的错误-意味着，无论该构建何时运行，它都将始终返回相同的结果。请参阅：How to update a maven dependency with a same version number in Azure Artifacts和Azure Artifact Publishing Fails for Artifact Version Containing '+'
答案 2 :(得分：0)
专门针对Maven，与其他版本相比，罐子在SNAPSHOT中的包装方式有所不同。
例如。假设我将jar的版本设置为1.0.0-PRERELEASE，现在此版本是不可变的。一旦将其发布到任何工件存储库，就不能覆盖它。通常，程序包管理系统将工件存储在这种逻辑路径-<group_id>/<artifact_id>/<version>/<artifact_id>_<version>.jar中。
但是对于快照来说，这略有不同。在行家中，快照是可变的。这意味着您可以覆盖SNAPSHOT。这是有道理的，因为按照定义，SNAPSHOT就像是在积极开发中的代码映像。快照存储在包管理源中的方式类似于<group_id>/<artifact_id>/<version(SNAPSHOT)>/<artifact_id>_<version>_<jar_timestamp>.jar。
在这种情况下，此jar的命名约定使其可变。在单个SNAPSHOT版本中，可能存在带有不同时间戳的多个jar。而且，当maven寻找SNAPSHOT依赖项进行下载时，它总是会选择最新的（出于逻辑考虑，因为这是最新的快照）。
目前，天蓝色文物正好按照预期的方式实现了这些概念。也许以前不存在，并且已经推送了更新。
http://maven.apache.org/guides/getting-started/index.html#What_is_a_SNAPSHOT_version https://xebia.com/blog/continuous-releasing-of-maven-artifacts/