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