Question

我通常的做法是每个svn主干有一个单独的maven项目（可以是多模块），如下所示：

trunk/ (style 1)
  /pom.xml
  /submod-1
  /submod-2

基本上，整个行李箱被视为单个释放包。我发现这更容易管理。有一个聚合/父pom来管理这个主干中的所有模块。

然而，我注意到我的一些同事组织如下：

trunk/ (style 2)
  /project-1
    /pom.xml
  /project-2
    /pom.xml

基本上，在单个svn trunk中...... project-1和project-2需要单独管理。即我不能检查行李箱，并将其内容作为一个单一的多模块maven项目工作 - 我很欣赏。

Q1：什么时候风格2会是一个好主意，如果有的话？

第二季度：有人能告诉/指出如何使用subversion管理maven项目的最佳实践吗？

Answer 1

我见过这两种情况。

在我看来，这取决于项目/模块的独立性。如果他们有自己的发布计划，那么他们拥有自己的主干，分支和标签是有意义的。但是，如果项目/模块总是一起发布，那么它们可能成为单个主干的一部分。

从maven的角度来看，如果多模块项目的模块从父项继承<version>，那么它应该遵循上面的style 1。

Answer 2

我非常同意@ Raghuram的回答，但是想补充以下内容：

如果要以相同的生命周期和相同的版本号一起发布项目，则需要样式1，其中父POM位于主干的根目录中。然后，此父POM通常将子项目包含为从根构建的 modules 。
如果您有一组独立项目（例如实用程序），您需要一个SVN位置（为了便于管理），但具有不同的发布周期，样式2才有意义。在这种情况下，您不需要将单个项目包含为 modules 的根聚合器POM。为实用程序项目提供一个公共父POM可能仍然有意义，它集中了编译器设置和插件管理等内容。样式1的不同之处在于您永远不会将所有项目一起发布。您将发布仅父POM的稳定版本，然后根据需要发布单个实用程序项目。

我们使用这两种风格取得了巨大的成功 - 主要区别在于您用于发布的方式和频率。

使用Style 2（和实用程序项目示例）如果这些项目共享相同的SVN标记和主干，我看不出问题。开发人员仍然可以决定是否要检查整个实用程序主干或仅检查单个项目。

Answer 3

只需查看this问题，至少是最常见的答案。它实际上总结了案例，并说了很多关于它的事情。

Answer 4

想想继续整合：这个想法首先使用jinkins，bitbucket或bamboo等CI服务器更加灵活......