在两个开发分支中组织公共依赖项

时间:2014-10-13 11:07:04

标签: maven version-control code-organization

鉴于您有两个开发分支,导致两个不同的设置。当然,这两个分支共享一些共同的代码。如果您更改了一些常用功能,则必须将更改从一个分支复制粘贴或合并到另一个分支。那很糟。有没有更好的方法来组织它?

以下是我看到的方式。

1)创建一些核心功能'分支,将共享模块放在那里并将其作为新工件连接到我们的构建。

优点:我们现在不需要支持相同代码的两个分支,不再需要合并,所有密切相关的类都存储在一个地方。

缺点:BOTH版本中包含常用功能。 '核心'由分支1驱动的模块版本更改实际上是强制改变核心' Branch 2中的工件版本也是如此,这意味着需要重新测试。否则我们必须指定此核心'的不同版本。每个分支中的人工制品,也不好。

2)与上一点相同,但是公共模块的SEPARATE类:将公共类放入'核心'如上一点所述的假象,但是在特定分支中保留特定于分支的类。

优点:现在我们对两个版本中包含的版本和常用功能都没有问题。

缺点:它不是一个简洁的解决方案。事实上,有时这意味着我们必须将相同类型的类放入不同的工件中。例如,我们有TextProcessor和NumberProcessor。分支1a需要两者,而分支2只需要第二分支,因此NumberProcessor进入核心'单独的工件,TextProcessor停留在分支1中。一个丑陋的解决方案:相同的功能分布在3个分支之间。

3)将所有常用代码放入一个核心'如第2页和第3页中的分支,但不像第2页那样分离特定于分支的类,也不像第1页那样在一个工件中构建它们,而是提供两种构建核心的方法&# 39;:分支1的一种方式和分支2的方式。

优点:看起来不错

缺点:再次它并不那么容易:可能我们必须以某种方式过滤Maven的类,如果有几十个差异,或者可能在内部创建两个共同模块的副本;核心',因此我们只是因为在更改相同功能时使用复制粘贴而不是合并而受益。

可能还有其他一些选择吗?

1 个答案:

答案 0 :(得分:1)

我会以一种安静的简单方式...创建以下结构

+-- root (pom.xml)
     +--- core (pom.xml)
     +--- common (pom.xml)
     +--- customer-1 (pom.xml)
     +--- customer-2 (pom.xml)

通过这样的设置,您不需要为常见/客户特定的实施设立分支机构等。您拥有所有模块的(主干/主服务器),并且可以为面向功能的目的创建分支。如果您需要特定客户,请将其放入相应的模块中。如果你发现客户特定的东西可以更好地转移到公共场所,这很简单,你可以通过IDE支持将类重构为适当的模块。

相关问题