java - Eclipse Java 项目中的长文件夹路径是否有解决方法？

Question

我有一个基于 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 给出了错误:

The declared package "com.company.product.component.subcomponent" does not match the expected package ""

我可以在 Eclipse 中使用任何解决方法吗？或者其他减轻每个人痛苦的方法的建议？

Answer 1

请记住:包是文件夹。

如果您的项目以这种方式分解为多个组件，并且每个组件都有不同的包，那么至少应该有一个合理的理由。

虽然对于重构您的组件可能有一个有效的论据(我既不能赞成也不能反对，因为我不知道这些组件应该如何相互交互)，但您不应该试图扁平化文件夹结构仅仅是因为一两个开发人员不希望使用工具来帮助他们更简单地导航。

此时最简单的事情就是标准化每个人的开发环境。 IDE 可能不是每个人都喜欢，但它们特别有助于减轻这样的痛点。