我们有一个较大的独立(即不是 Java EE)商业 Java 项目(10,000 多个类、四到五个 SVN 存储库、十或二十个第三方库)正在切换到 Maven。不幸的是,只有一名工程师(分布在三个国家的十几名工程师的团队中)有任何先前的 Maven 经验,所以我们在进行过程中会弄清楚这一点。
在旧的 Ant 做事方式中,我们会:
- 从三个或四个存储库中查看源代码
- 将它们全部编译成一个单一的 JAR
- 发布它(作为带有库 JAR、安装程序、各种配置文件等的 ZIP 文件的一部分)
- 将 JAR 检查到 SVN 中,这样我们就有了客户实际得到的记录。
现在,我们有一个充满工件的 Maven 存储库,以及一个依赖于 Maven 访问该存储库的构建过程。因此,如果我们需要复制我们实际交付给客户的内容,我们需要针对具有所有正确版本的 Maven 存储库进行构建。我猜,如果在(某些版本的)(SVN 控制的)POM 文件中,我们将所有依赖项设置为已发布版本,这是可行的?
但它让我们的发布工程师感到毛骨悚然,因为似乎没有任何办法:
- 确保有人不会错误地破坏 WebDAV 服务器上的 foo-api-1.2.3.jar 副本(WebDAV 服务器具有访问控制,但这不会阻止错误的构建脚本)
- 检测它,如果他们这样做
- 之后恢复
他的想法是,对于发布版本,使用本地文件系统作为存储库而不是 WebDAV 服务器,并将本地存储库置于 SVN 控制之下。
我们的一位 Maven 经验丰富的工程师不喜欢这样——我猜是因为他不喜欢将二进制文件置于版本控制之下?- 并建议也许专业版的 Nexus 服务器可以解决破坏或破坏跟踪/恢复问题。
就个人而言,当我们甚至还没有看到免费版本的任何好处时,我不高兴(对不起,Sonatype 读者)为非免费构建系统掏钱,并且不能保证它会真正解决问题。
所以我们的选择似乎是:
- WebDAV 服务器
- 优点:只有一台服务器,开发人员也可以访问,...?
- 缺点:容易破坏,没有破坏跟踪/恢复
- 本地文件系统
- 优点:可以置于修订控制之下
- 缺点:仅适用于分发脚本
坦率地说,这两个对我来说似乎都是黑客,我不得不怀疑是否有更好的方法来做到这一点。
所以:这里有正确的做法吗?