由于磁盘空间的考虑,我只想在我的存储库中保留任何快照的一个版本。而不是保留带有时间戳后缀的多个版本
例如电子商务-2.3-20090806.145007-1.ear
我该如何设置?这是构建设置还是存储库(Artifactory)设置
谢谢!
由于磁盘空间的考虑,我只想在我的存储库中保留任何快照的一个版本。而不是保留带有时间戳后缀的多个版本
例如电子商务-2.3-20090806.145007-1.ear
我该如何设置?这是构建设置还是存储库(Artifactory)设置
谢谢!
最简单(也是推荐的)方法是使用非唯一快照。如果您必须使用唯一快照,您可以在 Artifactory 中通过在 artifactory.config.xml 中的 <localRepository> 定义上指定 <maxUniqueSnapshots> 属性来执行此操作
例如:
<localRepository>
<key>snapshots</key>
<blackedOut>false</blackedOut>
<handleReleases>false</handleReleases>
<handleSnapshots>true</handleSnapshots>
<maxUniqueSnapshots>1</maxUniqueSnapshots>
<includesPattern>**/*</includesPattern>
<snapshotVersionBehavior>non-unique</snapshotVersionBehavior>
</localRepository>
作为参考,您可以通过设置计划服务在Nexus (通过 UI)中执行此操作,它允许您指定要保留的最小数量、保留它们的最大期限,以及是否在发布版本为时删除快照部署。
请注意,此功能/功能已在 Maven 3.0 中删除
只需在我自己的问题中添加一些内容:
添加
<distributionManagement>
...
<snapshotRepository>
...
<uniqueVersion>false</uniqueVersion>
</snapshotRepository>
...
</distributionManagement>
我的父母pom也促成了这个问题的解决。
看:
http://i-proving.com/space/Jessamyn+Smith/blog/2008-06-16_1
要更改 Artifactory 中存储库上的唯一设置 - 以管理员身份登录 - 并在相关 repo 上选择编辑 - 此处的屏幕截图:
http://wiki.jfrog.org/confluence/display/RTF/Understanding+Repositories
Artifactory 可以清理旧的独特快照。但是,我们发现唯一快照对于跟踪依赖关系或回滚到特定版本没有用处。有更好的替代方法可以做到这一点,它们更清洁、更可靠。这就是 Artifactory 默认偏好非唯一快照的原因,而且这个策略可以集中控制(这是 Artifactory 独有的)。您可以在此处阅读有关此内容以及自动清理功能的更多信息。
使用非唯一快照不是一个好方法。取而代之的是获得一个存储库管理器,它可以清理快照并对其进行配置以减少磁盘空间。拥有时间戳快照可以更轻松地跟踪问题,因为您可以轻松查看实际使用的版本。
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>remove-old-artifacts</id>
<phase>package</phase>
<goals>
<goal>remove-project-artifact</goal>
</goals>
<configuration>
<removeAll>true</removeAll><!-- When true, remove all built artifacts including all versions. When false, remove all built artifacts of this project version -->
</configuration>
</execution>
</executions>
</plugin>
不会在 Maven 3 中工作,因为它在下面被 Apache 引用
It's not recommended to use non-unique snapshots since they lead to non-reproducible builds. The main use case for these was to save disk space in the repository, but this is best handled by scheduling a periodic snapshot removal task to keep the number of versions down