我有一个基于Java代码的多项目Gradle构建。它被组织成几个项目，以保留第三方依赖关系，同时仍然允许共享代码。（每个子组件中都有main（）函数。）以下是我在磁盘上的项目文件夹结构，我相信它遵循了所有Gradle和Java最佳实践：
+---repository_for_component
+---component
| +---src
| +---main
| +---java
| +---com
| +---company
| +---product
| +---component
| +---SharedSource.java
+---subcomponent1
| +---src
| +---main
| +---java
| +---com
| +---company
| +---product
| +---component
| +---subcomponent1
| +---Source1.java
+---subcomponent2
| +---src
| +---main
| +---java
| +---com
| +---company
| +---product
| +---component
| +---subcomponent2
| +---Source2.java
+---build.gradle
+---settings.gradle
...我们的一个开发者不喜欢使用IDE（仅限终端），这对他来说是一个可以理解的巨大痛苦。当我必须从命令行或使用文件浏览器做任何事情时，对我来说也是痛苦的。
因为这个仓库只针对有问题的“组件”，所以很多路径都是冗余的。特别是，这消除了4个冗余文件夹：
+---repository_for_component
+---subcomponent1
| +---src
| +---main
| +---java
| +---com.company.product.component.subcomponent1
| +---SharedSource.java
...这仍然是一个微小的改进，但它是一些东西。我会把我的运气推得更远，但是当Gradle构建这个项目时，Eclipse给出了错误：
声明的包“com.company.product.component.subcomponent”与预期的包“”不匹配
在Eclipse中有没有可以使用的变通方法？或者其他建议，可以让每个人都不那么痛苦？
3条答案
按热度按时间wooyq4lh1#
记住：包是文件夹。
如果你把你的项目以这种方式分解成组件，并且每个组件都有不同的包，那么至少应该有一个合理的理由。
虽然重构你的组件可能有一个有效的论点（我既不赞成也不反对，因为我不知道这些组件应该如何相互作用），但你不应该仅仅因为一两个开发人员不希望使用工具来帮助他们更简单地导航，就试图扁平化文件夹结构。
在这一点上，最简单的事情就是标准化每个人的开发环境。IDE可能不是每个人都喜欢的，但它们特别有助于减轻这样的痛点。
ru9i0ody2#
我已经确认Eclipse只支持与包名匹配的源路径;替代方案已被requested并标记为“不会修复”。
我想我已经为希望从命令行完成工作的Linux开发人员准备了found a suitable workaround。在
~/.bashrc文件中，添加如下内容：设置好路径后，启动一个新的终端示例，并像这样运行它：
或者，您可以使用
export来代替别名。无论什么都可以。关键是您可以更快地快速遍历这些路径，并且可以从任何地方这样做。0lvr5msh3#
不是完美的答案，但可能会有帮助。在Eclipse中，为新建（文件夹）创建一个“键盘快捷键”（首选项-〉通用-〉键）（例如Ctrl + Shift + f）。它会立即打开新文件夹对话框。
In Eclipse, create a "keyboard shortcut" (Preferences -> General -> Keys) for New (Folder)