使用Maven构建时可存档，可复制的版本：有正确的方法吗？

Question

我们有一个较大的独立（即不是Java EE）商业Java项目（10,000多个类，四个或五个SVN存储库，十个或二十个第三方库），它们正在切换到Maven。不幸的是，只有一名工程师（在一个分布在三个国家的十几个团队中）拥有Maven的任何经验，因此我们可以随时了解它。

在旧的蚂蚁做事方式中，我们：

1. 查看三个或四个存储库的源代码
2. 将它全部编译成单个单片JAR
3. 发布（作为带有库JAR的ZIP文件的一部分，安装程序，各种配置文件等）。
4. 将JAR检查到SVN，这样我们就可以记录客户的实际情况。

现在，我们有一个充满工件的Maven存储库，以及依赖于Maven可以访问该存储库的构建过程。因此，如果我们需要复制我们实际发送给客户的内容，我们需要针对具有所有适当版本的Maven存储库进行构建。我想，如果在（某些版本的）（SVN控制的）POM文件中我们将所有依赖项设置为已发布的版本，这是可行的吗？

但它给了我们的发布工程师令人毛骨悚然的爬行，因为似乎没有任何办法：

1. 以确保有人不会错误地在WebDAV服务器上破坏foo-api-1.2.3.jar的副本（WebDAV服务器具有访问控制，但这不会阻止错误的构建脚本）< / LI>
2. 如果他们确实
就会检测到它
3. 之后恢复

对于发布版本，他的想法是使用本地文件系统作为存储库而不是WebDAV服务器，并将该本地存储库置于SVN控制之下。

我们的Maven经验丰富的工程师不喜欢这样 - 我猜是因为他不喜欢将二进制文件置于版本控制之下？ - 并建议可能Nexus服务器的专业版可以解决破坏或破坏跟踪/恢复问题。

就个人而言，当我们还没有看到免费版本的任何好处时，我不高兴（对不起，Sonatype读者）为非免费版本系统支付钱，并且不能保证它会真正解决问题。

所以我们的选择似乎是：

1. WebDAV服务器  
   • 优点：只有一台服务器，也可由开发人员访问，......？
    
   • 缺点：容易崩溃，没有破坏追踪/恢复
2. 本地文件系统  
   • 优点：可以置于修订控制之下
    
   • 缺点：仅适用于分发脚本
坦率地说，这些对我来说似乎都是黑客，我不得不怀疑是否有更好的方法来做到这一点。

那么：这里有正确的事吗？

Answer 1

我不确定会得到一切，但我愿意：

• 使用maven-release-plugin（自动执行发布过程，即执行release:prepare中记录的所有步骤。）
• 将WebDAV与匿名只读和经过身份验证的写入策略一起使用（因此只有发布工程师才能将已发布的工件部署到公司回购中）。

没有必要将生成的工件置于版本控制之下（如果您在版本控制下有poms）。我没有看到使用本地文件系统而不是WebDAV的好处（这不提供更多安全性，您也可以保护WebDAV）。我不知道Nexus的商业版本会在这里解决什么。

Answer 2

Nexus有一个设置可以防止您在发布存储库中破坏已经发布的人工制品。

对于一个大约十几人的团队，Nexus的免费版本应该足够了。