我在工作中继承了一个Java（Maven）项目。我不是 Java 开发人员，但该项目现在是我的了。当我克隆（a la git clone）存储库时，我注意到在任何 .java 文件出现之前文件夹结构非常深入。例如，文件夹结构如下所示：
project_name
.git
.idea
src/
main/
java/
org/
bah/
co/
lab/
zeus/
apimanager/
RestClient.java
我用谷歌搜索了一下，试图找出为什么文件夹结构如此深入。经过对 Maven 的一些研究，我的理解是默认结构以/src/main/java开头。所以，我很好奇为什么以前的（现在与外界隔绝的）开发人员会像这样构建这个存储库（以及许多其他存储库）。为了不征求意见，请告诉我：该项目的结构是否有技术原因？该文件夹之外实际上没有其他 .java 文件apimanager，那么有什么技术原因将所有内容埋得这么深呢？
rzw*_*oot 11
Maven 是一个对事情应该走向何方有一定意见的工具；默认配置。您不必遵循它，但不遵循此默认配置会带来三个显着的缺点：
解释一下每一层：
src指示这些是源文件：编译和生成的内容不应该放在这里，并且整个 src树应该处于版本控制中。与例如bin或build包含构建工件、doc包含文档以及谁知道存储库的其他相关部分需要哪些其他目录进行对比。
main一个项目可以由多个可单独构建的工件和“多种”产品组成。例如，大多数项目都包含一堆仅用于测试目的（单元测试）的代码。他们住在src/test。核心产品位于main. 例如，您还可以为安装程序（可能是（src/installer））、构建插件或注释处理器提供单独的源，这些源需要首先构建，然后在编译项目时需要位于类路径上main，等等。
java有一种分离语言项目，其中一些是用 A 语言编写的，一些是用 B 语言编写的。就其价值而言，我认为这一层的设计很糟糕；以 结尾的文件.java给出了如何“编译它”，这适用于几乎每个需要应用编译器的源文件：扩展名就像文件夹名称一样java。为了向您展示一个常见的对比： 许多项目都具有src/main/resources以下功能src/main/java： 资源只需通过复制即可“编译”： 想象您的应用程序有一个文本文件，其中包含美国所有州的列表以及每个州使用的所有邮政编码。或者png带有 GUI 应用程序图标图像的文件。此类文件与类文件一样是主应用程序的一部分，并且应该最终位于同一位置（文件内jar），但是要“编译”它们，您只需..复制它们，而不是运行javac去做这个。这就是这个级别的内容：应该使用什么工具将源文件转换为可分发的方面？
co/lab/zeus/apimanager这与java包结构相匹配。这实际上是一个单独应用的要求javac。使用如此深度嵌套的包结构的原因很简单，因为包充当名称空间：如果存在冲突的完全限定名称，则一切都会崩溃：Java 根本无法处理此问题。因此，java 程序员通过使用“反向域名”结构来确保此类冲突永远不会发生：如果您拥有该域，则可以将您的项目放在该包中zeus.lab.co，从而确保除了团队中的其他人之外没有人共享该服务器的控制权可能会发生冲突（对于那些人：他们在您的团队中，请与他们交谈以避免冲突）。例如，有 3 个不同的开源 Java 项目，都称为 Spark。如果它们全部都消失了package spark;（因此，src/main/java/spark/Main.java作为示例文件），那么对于每个 java 项目，您将选择 3 个中的一个：另外 2 个您永远不能在该项目中使用。严厉且毫无意义，这就是为什么（几乎）所有java库都使用反向域名作为根包名称，然后maven在其目录结构中遵循这个包名称，因为javac如果你不这样做，生活将变得极其困难。
这让我们能够project_name/src/main/java。
org/bah你用夸张的手法弥补了这一点。没有人在 上托管项目zeus.lab.co.bah.org。但如果他们这样做了：与决定将这个巨大的域名分配给团队的管理层交谈。这是他们的责任，而不是这个项目的作者的责任。