在gradle中,使用buildSrc
文件作为顶层的目的是什么,而不是仅仅是典型的java项目布局(src / main / java)?
如果我有
的布局src
main
java
或
buildSrc
src
main
java
有什么不同(或者这样做的原因)?它在多模块项目中更有用吗?即使对于多模块项目,也不能做类似
的事情proj1
src
proj2
src
然后只需要一个顶级build.gradle(与proj1
和proj2
处于同一级别)来定义项目中的常用设置?
答案 0 :(得分:35)
buildSrc
是一个单独的 build ,其目的是构建任何旨在用于构建脚本的任务,插件或其他类。主构建,但不必在构建之间共享。(*)不可能将这些类构建为主构建的一部分,因为它们必须在主构建的构建脚本甚至可以编译之前存在/已评估,Gradle在完成任何工作(配置与执行阶段)之前编译/评估所有构建脚本。
与将所有构建代码放入构建脚本相比,buildSrc
为您提供了一种开发构建代码的方法,就像常规代码一样,可以测试的类,导入到IDE中的等等。这是一种方法保持构建脚本简单,干燥甚至更复杂的构建。
buildSrc
,因为较大的构建更有可能实现自己的自定义任务和插件。
随着时间的推移,buildSrc
将成为在单个Gradle调用中执行多个依赖构建的更一般功能。
(*)可以跨版本共享类,但更多参与。特别是,您需要将类发布到存储库,并且使用构建必须从那里显式地导入它们,类似于在构建之间共享生产库时。
答案 1 :(得分:0)
在gradle中,使用buildSrc文件作为顶部的目的是什么 级别,而不是典型的Java项目布局 (src / main / java)?
您绝对可以做到这一点。它在gradle中被称为composite build,但是您必须告诉Gradle从该文件夹中进行任何构建include。顶级buildSrc
文件夹中的unique property是gradle会自动将其视为包含的内部版本。
请注意,即使buildSrc
被视为复合版本,运行gradle.getIncludedBuilds()
时,它也不会在包含的版本列表中显示。我相信原因是因为该列表是保留给您手动包含在settings.gradle
中的内部版本的。
要同时包含src/main/java
作为复合构建,您必须使用--include-build
标志以及src/main/java
的路径来运行gradle脚本。对于包含的版本来说,这是一个不寻常的地方,但是gradle不会抱怨。
然后只有一个顶层build.gradle(与 proj1和proj2)来定义项目中的通用设置?
您可以在您的build.gradle
和proj1
子项目的同一级别拥有一个顶级proj2
。通常,这就是大多数多项目项目的结构方式。
正如an answer所指出的那样,buildSrc
项目的目的是创建自定义插件或任务,该插件或任务要在本地的不同项目之间共享。您的构建。 这并不意味着您不能在顶级build.gradle
中创建这些自定义任务和插件。您可以通过这种方式执行此操作,但是问题是您将无法在任何子项目中使用它。
请记住,要在Java / groovy中导入某些内容,要求该内容存在于正确的Java / groovy文件(或Java 9+的模块)中。既然您的build.gradle
只是一个脚本,那么从其中简单地导入插件或任务并不是任意的。
正如我已经指出的那样,这是来自Gradle docs的,拥有buildSrc
目录的原因之一是:
发现目录后,Gradle会自动编译并 测试此代码并将其放入构建脚本的类路径。
如您所见,buildSrc
充当了构建过程的扩展,因为它可以为项目的所有构建脚本添加附加功能。
还有几点:
dependencies
中声明的任何buildSrc/build.gradle
对您项目中的其余构建脚本都是可见的。buildscript
中的buildSrc/build.gradle
块仅对buildSrc/build.gradle
可见,而其他任何可见。buildSrc
can be used中定义的任何插件类,都不需要在META-INF/gradle-plugins
中声明。build.gradle
或您的任何子项目中定义的任何依赖项在buildSrc
中都不可见。如果您还记得该文件夹被视为包含的内部版本(即外部),则应该理解为什么看不到包含该文件夹的项目的类路径。