3

假设项目 X 是基础项目,项目 Y 依赖于 X。项目 Y 可能是项目 X 的​​插件,或者它可能是一个独立的应用程序,需要以其他方式使用项目 X。

我一直认为项目 Y 应该是超级项目,项目 X 应该是项目 Y 的子模块。

然而,在阅读本文时,似乎我的想法可能会颠倒过来。在本文中,依赖项是超级项目,依赖项代码(在本例中为插件)是子模块。那么这是使用子模块的正确方法吗?

4

2 回答 2

3

这取决于,但在一般情况下,我会说子模块是(或可以是)两者。

显然,如果项目 Y 是项目 X 的​​依赖项(例如,外部库),它应该是一个子模块。

但是子模块不仅用于依赖关系,还用于作为半独立开发的项目组件的项目。插件就是这样一个组件:它是独立开发的,但您可能希望将它与项目的源代码打包在一起。

于 2010-07-15T02:19:40.730 回答
2

如果 ProjectY 可以在不了解 ProjectX 的情况下生存(它可能是 X 的插件),它就不可能是一个超级项目。

如果它需要 X 以某种方式完成,那么是的,它可能是一个超级项目,以便在其树中引用 X(如子模块的真实性质中所述)。

在基于组件的方法中,真正的超级项目将是引用正确版本的 ProjectYProjectX 的第三个项目,以记录整个项目工作所需的确切配置(即修订列表)。


OP 添加了正确的问题:在哪里存储依赖关系(Y 对 X)?

如果采用基于组件的方法并且有一个 ProjectZ 超级项目,并且 ProjectY 依赖于 ProjectX 来构建,那么我们是否不将 ProjectX 作为子模块包含在 ProjectY 的存储库中,而仅包含在 ProjectZ 中?
这意味着 ProjectY 不能独立构建,使其(由于缺乏口才)成为一种“隐含的子模块”。

如果您只有 2 个组件,一个依赖于另一个,当然:您可以直接将 ProjectX 声明为 ProjectY 的子模块。

但是,如果 ProjectY 不能自行构建,那么它无论如何都不是一个“完整的”(如“自治”)项目。
因此,在 ProjectY 之外存储依赖信息的全局父“ProjectZ”具有其优势:

  1. 直接从 ProjectZ 根目录使每个模块路径更加可见(而不是将 ProjectX 隐藏在 ProjectY 的深处,从而使 ProjectY 客户端不那么可见该依赖项)
  2. 统一 ProjectX 版本(如果多个模块需要 ProjectX,在 ProjectZ 中引用一次,清楚地宣传所有其他模块应该使用的 ProjectX 的“一个正式版本”)
于 2010-07-15T04:12:48.203 回答