如何有效地处理maven-3时间戳快照？

Question

现在，maven-3对快照的false执行了跌落支架操作，看来您确实需要使用时间戳快照。特别是在内部使用maven 3的m2eclipse似乎受到了影响，当快照不是唯一的时，更新快照就无法工作。

最好是以前的实践将所有快照设置为uniqueVersion=false

现在，切换到时间戳版本似乎没什么大问题，毕竟它们是由一个中央连接库管理的，它能够在常规的间隙中删除旧的快照。

问题是当地开发商的工作站。他们的本地存储库很快就会变得非常大，有着独特的快照。

如何处理这个问题？

现在，我看到了可能的解决方案：

• 要求开发人员定期清除存储库(这会导致大量的混乱，因为删除需要很长时间，而下载所需的所有内容则需要更长的时间)。
• 设置一些脚本，删除本地存储库中的所有快照目录，并要求开发人员不时运行该脚本(比第一个脚本更好，但运行和下载当前快照仍然需要相当长的时间)。
• 使用依赖项:清除本地存储库插件(在从eclipse运行时确实有问题，因为打开了文件，需要从每个项目运行)
• 在每个工作站上设置连接，并设置一个作业来清理旧快照(最好的结果，但我不想维护50+ nexus服务器，而且开发人员工作站的内存总是很紧)
• 完全停止使用快照

防止本地存储库填充硬盘空间的最佳方法是什么？

更新：

为了验证beaviour并提供更多信息，我设置了一个小型连接服务器，构建两个项目(a和b)并尝试：

答：

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>de.glauche</groupId>
  <artifactId>a</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <distributionManagement>
    <snapshotRepository>
        <id>nexus</id>
        <name>nexus</name>
        <url>http://server:8081/nexus/content/repositories/snapshots</url>
    </snapshotRepository>
  </distributionManagement>

</project>

b：

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>de.glauche</groupId>
  <artifactId>b</artifactId>
  <version>0.0.1-SNAPSHOT</version>
    <distributionManagement>
    <snapshotRepository>
        <id>nexus</id>
        <name>nexus</name>
        <url>http://server:8081/nexus/content/repositories/snapshots/</url>
    </snapshotRepository>
  </distributionManagement>
 <repositories>
    <repository>
        <id>nexus</id>
        <name>nexus</name>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
        <url>http://server:8081/nexus/content/repositories/snapshots/</url>
    </repository>
 </repositories>
  <dependencies>
    <dependency>
        <groupId>de.glauche</groupId>
        <artifactId>a</artifactId>
        <version>0.0.1-SNAPSHOT</version>
    </dependency>
  </dependencies>
</project>

现在，当我使用maven并在"a“上运行”部署“时，我将

a-0.0.1-SNAPSHOT.jar
a-0.0.1-20101204.150527-6.jar
a-0.0.1-SNAPSHOT.pom
a-0.0.1-20101204.150527-6.pom

在本地存储库中。每次运行deploy目标时，都会使用一个新的时间戳版本。当我试图从nexus服务器更新快照时(关闭"a“项目，从本地存储库中删除它，构建"b")，也会发生同样的情况。

在构建了大量快照的环境中(想想hudson服务器.)，本地的位置填充了旧版本的fast

更新2:

为了测试失败的原因和原因，我做了更多的测试。每个测试都是针对所有的清洁设备运行的(de/glauche从机器和附件中删除)

• 使用maven 2.2.1部署mvn：

机器A上的本地存储库确实包含snapshot.jar +快照-时间戳。

但是:只有一个nexus中有时间戳的jar，元数据是这样的：

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>de.glauche</groupId>
  <artifactId>a</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <versioning>
    <snapshot>
      <timestamp>20101206.200039</timestamp>

      <buildNumber>1</buildNumber>
    </snapshot>
    <lastUpdated>20101206200039</lastUpdated>
  </versioning>
</metadata>

• 运行m2eclipse (embedded m3 final)中的update依赖项(机器B)，->本地存储库有snapshot.jar +快照-时间戳. has :(
• 使用外部maven 2.2.1 ->本地存储库运行包目标具有snapshot.jar +快照-timestamp.jar :(

好的，接下来尝试使用maven 3.0.1 (在删除了项目a的所有跟踪之后)

• 机器A上的本地存储库看起来更好，只有一个没有时间戳的jar
• 在nexus中只有一个时间戳的jar，元数据是这样的： de.glauche a 0.0.1-快照20101206.201808 3 20101206201808 jar 0.0.1-20101206.201808-3 20101206201808 pom 0.0.1-20101206.201808-3 20101206201808
• 运行m2eclipse (embedded m3 final)中的update依赖项(机器B)，->本地存储库有snapshot.jar +快照-时间戳. has :(
• 使用外部maven 2.2.1 ->本地存储库运行包目标具有snapshot.jar +快照-timestamp.jar :(

因此，简单地说: maven3中的“部署”目标比2.2.1中的效果更好，创建机器上的本地存储库看起来很好。但是，接收器总是有很多有时间的版本.

我做错什么了？

更新3

我还测试了其他各种配置，首先用工件->替换连接，行为相同。然后使用linux 3客户端从存储库管理器下载快照，->本地存储库仍然有时间戳快照:(

Answer 1

<uniqueVersion>配置应用于部署到Maven存储库(如Nexus )的工件(通过mvn )。

要从Nexus中删除这些内容，您可以轻松地创建一个自动作业，以便每天清除快照存储库。它可以被配置为保留一定数量的造型，或者将它们保留一定的时间。它超级容易，工作起来很棒。

开发人员机器上的本地存储库中的工件从“安装”目标到达，并且不使用这些timestamps...they，只需继续替换一个和唯一的快照版本，除非您还在增加修订编号(例如，1.0.0-快照到1.0.1-快照)。

Answer 2

这个插件从本地存储库中删除项目的工件。只保留一个大型本地快照的副本非常有用。

<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>

Answer 3

就远程存储库部分而言，我认为前面讨论定期清除快照的答案是可行的。但是没有人提到您问题的本地开发人员工作站同步部分。

我们还没有开始使用Maven3，所以我们还没有看到快照开始在本地机器上生成。

但是我们在m2eclipse上遇到了不同的问题。当我们启用了“工作区解决方案”，并且项目存在于我们的工作区中时，源更新通常会使我们处于危险的边缘。但是我们发现很难让m2eclipse用最近在Nexus中发布的工件来更新自己。我们在团队中遇到了类似的问题，这是特别有问题的，因为我们有一个非常大的项目图.有许多依赖项不在您的工作区中，但是将得到经常发布的快照。

我非常肯定，这回回过头来讨论m2eclipse中的一个问题，在这个问题上，它没有按照应有的方式处理快照。您可以在eclipse中的Maven控制台中看到，m2eclipse告诉您它跳过了最近发布的快照的更新，因为它有缓存的版本。如果从运行配置或命令行执行-U，Maven将获取元数据更改。但“更新快照.”选择应该告诉m2eclipse让Maven终止这个缓存。它似乎并没有被传播下去。如果你对投票感兴趣的话，似乎会有一个错误被归档：https://issues.sonatype.org/browse/MNGECLIPSE-2608

你在某个地方的评论中提到了这一点。

解决这个问题的最佳方法似乎是让开发人员在m2eclipse内部出现故障时清除他们的本地工作站。类似于另一个问题的解决方案。其他人报告了Maven 2.2.1和3支持m2eclipse的问题，我也看到了同样的问题。

我希望如果您使用的是Maven3，您可以将其配置为只提取最新的快照，并缓存存储库所述的时间(或者直到手动将其过期)。希望这样，您就不需要在本地存储库中放置一堆快照。

除非您说的是一个手动对它们执行mvn install的构建服务器，否则就不会发生这种情况。至于如何防止快照在构建服务器这样的环境中生成，我们通过让每个构建都使用自己的工作区和本地存储库(不过，在Maven 2.2.1中，某些东西(比如POMs )似乎总是从~/.m2/存储库中出现)来避免这一问题，额外的快照只在单个构建中保留，然后被丢弃(然后重新从零开始下载)。因此，我们已经看到，这种方法最终占用了更多的空间，但它往往比在单个存储库中解决所有问题更稳定。此选项(在Hudson上)称为“使用私有Maven存储库”，当您选择使用Maven构建时，该选项位于Build节有关项目配置的Advanced按钮下。下面是该选项的帮助说明：

通常，Hudson使用由Maven确定的本地Maven存储库--确切的过程似乎没有文档化，但它是~/.m2/存储库，可以被in ~/.m2/see ings.xml覆盖(有关更多细节，请参见参考资料)。这通常意味着在同一个节点上执行的所有作业共享一个Maven存储库。这样做的好处是可以节省磁盘空间，但缺点是有时这些构建可能会相互干扰。例如，尽管POM中的任何一个存储库都没有构建依赖项，但您的构建可能会不正确地成功，因为您的本地存储库中有所有依赖项。 还有一些关于并发Maven进程试图使用同一个本地存储库的报告中的问题。 当选中此选项时，Hudson将告诉Maven使用$工作区/.存储库作为本地Maven存储库。这意味着每个作业将只为自己获得自己的独立Maven存储库。它以牺牲额外的磁盘空间消耗为代价解决了上述问题。 在使用此选项时，请考虑设置一个Maven工件管理器，这样您就不必经常访问远程Maven存储库。 如果您希望在Hudson上执行的所有Maven作业中激活此模式，请参阅这里描述的技术。

希望这有帮助-如果它不能解决你的问题，请让我知道我错过了什么。