我有一个基于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中使用任何变通方法吗?或者其他建议如何让每个人减少痛苦?
答案 0 :(得分:0)
请记住:包是文件夹。
如果您的项目以这种方式分解为组件,并且每个组件都有不同的软件包,那么至少 应该是的正当理由。
虽然可能有一个有效的论点要重构你的组件(我既不赞同也不反对,因为我不知道这些组件应该如何互相交互),你不应该看简化文件夹结构只是因为一个或两个开发人员不希望使用工具来帮助他们更简单地导航它。
此时最简单的方法是标准化每个人的开发环境。 IDE可能不是每个人都喜欢的,但它们特别有助于缓解这样的痛点。
答案 1 :(得分:0)
我已经确认Eclipse只支持与包名匹配的源路径;替代品已requested,并标记为“不会修复。”
对于希望从命令行完成工作的Linux开发人员,我认为我found a suitable workaround。在~/.bashrc
文件中,添加以下内容:
# Project shortcuts export repo="/path/to/repository/" alias repo_root="cd $repo" alias repo_core="cd $repo/core/src/main/java/com/company/product/component/" alias repo_sub1="cd $repo/sub1/src/main/java/com/company/product/component/subcomponent1" alias repo_sub2="cd $repo/sub2/src/main/java/com/company/product/component/subcomponent2"
设置路径后,启动一个新的终端实例,并按如下方式运行:
bash-4.1$ repo_root bash-4.1$ pwd /path/to/repository bash-4.1$ repo_sub1 bash-4.1$ pwd /path/to/repository/sub1/src/main/java/com/company/product/component/subcomponent1
或者,您可以为每个使用export
而不是别名。无论桃子什么都可以。关键是你可以更快地快速遍历这些路径并从任何地方进行。