0

我们有一个较大的独立（即不是 Java EE）商业 Java 项目（10,000 多个类、四到五个 SVN 存储库、十或二十个第三方库）正在切换到 Maven。不幸的是，只有一名工程师（分布在三个国家的十几名工程师的团队中）有任何先前的 Maven 经验，所以我们在进行过程中会弄清楚这一点。

在旧的 Ant 做事方式中，我们会：

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

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

但它让我们的发布工程师感到毛骨悚然，因为似乎没有任何办法：

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

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

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

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

所以我们的选择似乎是：

  1. WebDAV 服务器
    • 优点：只有一台服务器，开发人员也可以访问，...？
    • 缺点：容易破坏，没有破坏跟踪/恢复
  2. 本地文件系统
    • 优点：可以置于修订控制之下
    • 缺点：仅适用于分发脚本

坦率地说，这两个对我来说似乎都是黑客，我不得不怀疑是否有更好的方法来做到这一点。

所以：这里有正确的做法吗？

4

2 回答 2

1

我不确定能得到所有东西，但我会：

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

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

于 2009-11-24T11:08:17.643 回答
0

Nexus 有一个设置可以防止你破坏发布存储库中已经发布的工件。

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

于 2011-01-25T06:10:41.770 回答