在Maven项目中，嵌套或平面目录布局的原因是什么？

Question

随着我的Maven项目的发展，我试图保持在项目结构的顶端。到目前为止，我有一个2-3级别的嵌套目录布局，每个级别上都有一个POM，其中module条目对应于该级别的目录。POM继承(parent属性)不一定遵循这一点，并且与此问题无关。

现在，虽然嵌套结构在Maven看来是很自然的，而且只要您在一个特定的级别上，它就很干净，但我开始对我在IDE中看到的内容感到困惑(的想法)。

我看了一下Apache源代码，它们有一个非常复杂的项目，它的目录结构看起来很平坦，所以我想知道这是否是一个更好的方法。

你在实践中经历过的这两种方法的优缺点是什么？

注意到，this question (我同时发现)似乎非常相似。我将把它留给社区来决定是否应该作为一个副本来关闭它。

Answer 1

我用了一种混合的方法。具有不同生命周期的事物(从发行版到因此从VCS的角度来看)是扁平的，具有相同生命周期的事物是嵌套的。我使用svn:externals进行结账。我在this previous answer中写过这种方法。

Answer 2

我投票赞成筑巢。我使用的是IDEA 9，它显示了项目窗格中的嵌套，因此演示文稿反映了您的逻辑项目结构。( 8.1中的情况并非如此-它被夷为平地。)

我更喜欢保持嵌套，特别是在名称非常相似的情况下--在使用命令提示符时使导航更加容易。我有一个像myapp层组件这样的名字的项目，所以它们都以相同的前缀开头，而且很多项目都有相同的层，所以在命令行上使用自动完成几乎毫无用处。然后，将它们分离到嵌套结构中要容易得多，因为名称的每一部分(appname、层或组件)在目录结构的每个级别上只重复一次。

如果从命令行构建，构建项目的子集就容易得多，例如，如果我正在处理db模型，那么我通常需要构建该领域的所有项目。当文件被平放时，这是很难做到的--我知道的唯一方法是使用-pl参数来maven并指定要构建的proejcts。对于嵌套的目录，我只需将cd转到db目录并运行mvn。

例如，而不是

myapp-web-gui1
myapp-web-gui2
myapp-web-base
myapp-svc-clustered
myapp-svc-clustered-integrationtest
myapp-svc-simple
myapp-db-model
myapp-db-hibernate

我们有这个结构

\myapp
   \web
     \gui1
        pom.xml
     \gui2
        pom.xml  (other poms omitted to keep it short)
     \base
   \svc
      \clustered
      \clustered-it
      \simple
   \db
      \model
      \hibernate      

您也可以为集成测试添加嵌套，但这似乎太过分了。

通过嵌套，您还可以获得继承的所有好处(以及其中的一些痛苦)。

我遇到的唯一问题是目录名与工件id不匹配。(我仍在使用完整的artifactIds。)因此，每个项目都必须明确定义SCM路径，因为不能再从父pom推断这些路径。当然，每个目录都可以与artifactId相同，然后可以从父目录推断SCM的详细信息，但我发现长目录名有点难以处理。