Gradle教程第一章：1.8复合构建

Posted 2021-04-27 安卓开发资源分享

01

Gradle教程第一章：1.8复合构建

目录

1.8.1。 什么是复合构建？

1.8.2。 定义复合构建

1.8.3。 与复合构建交互

1.8.4。 声明由包含的构建替换的依赖项

1.8.5。 在依赖中建立一个构建任务

1.8.6。 复合构建的当前局限性和后期计划

复合构建是一个不可替代的功能。对于许多案例来说，这是有用的，如果发现BUG，我们会及时改进。 感谢您的试用！

1.8.1什么是复合构建

复合构建只是一个包含其他构建的构建。 在许多方面，复合构建与Gradle多项目构建类似，不同之处在于除了包括单个项目之外，还包括completebuilds。

复合构建允许你：

组合通常独立开发的构建，例如在你的应用程序中使用库尝试错误修复时

将大型多项目构建分解成更小，更独立的块，可根据需要独立工作或一起工作

包含在复合构建中的构建自然地被称为“包含构建”。 包含的构建不与共享构建或其他包含的构建共享任何配置。 每个包含的构建，都被隔离配置和执行。

包括构建与其他构建viadependency替代。如果组合中的任何构建都具有可以由包含的构建来满足的依赖关系，则该依赖关系将被包含的构建的项目依赖性所取代。

默认情况下，Gradle将尝试确定可由替代的构建替换的依赖关系。 然而，为了更灵活。如果由Gradle确定的默认值对于复合构建不正确，则可以显式声明这些替换。 请参见第1.8.4节“声明由包含的构建替换的依赖关系”。

除了通过项目依赖关系输出外，复合构建可以直接声明包含的构建的任务依赖关系。 包含的构建是隔离的，并且无法在复合构建或其他包含的构建上声明任务依赖关系。 参见第1.8.5节“根据包含的构建中的任务”。

1.8.2。 定义复合构建

以下示例演示了，通常单独开发的Gradle构建的各种方式可以组合成复合构建。 对于这些示例，themy-utilsmulti-project构建生成2个不同的java库（number-utilsandstring-utils），而且它们使用这些库中的函数生成可执行文件。

My-appbuild没有直接依赖于我的工具。 相反，它声明对由my-utils提供的库的二进制依赖。

例1.8.1。 我的应用程序的依赖关系

my-app/build.gradle

apply plugin:'java'apply plugin:'application'apply plugin:'idea'group"org.sample"version"1.0"mainClassName ="org.sample.myapp.Main"dependencies {    compile"org.sample:number-utils:1.0"compile"org.sample:string-utils:1.0"}repositories {    jcenter()}

注意：此示例的代码可以在“Gradle-all”分布中找到atsamples / compositeBuilds / basic。

1.8.2.1。 通过包含构建定义复合构建

The- include-buildcommand-line参数将执行的构建转换为复合，将依赖关系从包含的构建转换为已执行的构建。

例1.8.2。 声明一个命令行复合

Output ofgradle --include-build ../my-utils run

> gradle --include-build ../my-utils run:processResources NO-SOURCE:my-utils:string-utils:compileJava:my-utils:string-utils:processResources NO-SOURCE:my-utils:string-utils:classes:my-utils:string-utils:jar:my-utils:number-utils:compileJava:my-utils:number-utils:processResources NO-SOURCE:my-utils:number-utils:classes:my-utils:number-utils:jar:compileJava:classes:runThe answer is 42BUILD SUCCESSFUL in 0s2 actionable tasks: 2 executed

1.8.2.2。 定义复合构建

viasettings.gradle

可以通过usingSettings.includeBuild（java.lang.Object）在settings.gradlefile中声明包含的构建来实现上述安排.Thesettings.gradlefile可以用于同时添加子项目和包含的构建。 包含的构建是按位置添加的。 有关详细信息，请参阅下面的示例。

1.8.2.3。 定义单独的复合构建

上述方法的一个缺点是，它需要您修改现有版本，使其不再作为独立构建使用。 避免这种情况的一种方法是定义一个单独的复合构建，其唯一目的是组合其他单独的构建。

例1.8.3。 声明一个单独的组合

settings.gradle

rootProject.name='adhoc'includeBuild'../my-app'includeBuild'../my-utils'

在这种情况下，执行的“main”构建是复合的，它没有定义任何有用的任务来执行自身。 为了在“我的应用程序”构建中执行“运行”任务，组合构建必须定义一个委托任务。

例1.8.4。声明由包含的构建替换的依赖项

build.gradle

task run {    dependsOn gradle.includedBuild('my-app').task(':run')}

更多详细信息依赖于下面包含的构建任务的任务。

1.8.2.4。 对包含构建的限制

大多数构建可以包含在复合中，但是有一些限制。

每个包括的构建：

必须有asettings.gradlefile。

本身不能是复合构建。

不能具有与另一个包含的构建相同的arootProject。

不能具有与复合构建的顶级项目相同的arootProject。

不能有arootProject.namethe与复合buildrootProject.name相同。

1.8.3。 与复合构建交互

通常，与复合构建交互与常规多项目构建大致相同。 可以执行任务，可以运行测试，并将构建导入到IDE中。

11.3.1。 执行任务 

复合构建中的任务可以从命令行执行，也可以从IDE执行。 执行任务将导致执行直接任务依赖关系，以及从包含的构建构建依赖项工件所需的任务。

没有任何手段通过命令行从包含的构建中直接执行任务。 包含的构建任务将自动执行，以生成所需的依赖项工件，或者包括构建可以从包含的构建声明对任务的依赖。

11.3.2。 导入IDE

复合构建的最有用的功能之一是IDE集成。 通过对构建应用theideaoreclipseplugin，可以生成一个单一的IDEA或Eclipse项目，允许组合中的所有构建一起开发。

除了这些Gradle插件，最新版本的IntelliJ IDEAandEclipse Buildship支持直接导入复合构建。

导入复合构建允许来自单独的Gradle构建的源可以一起轻松开发。 对于每个包含的构建，每个子项目都包含在IDEA模块或Eclipse项目中。 配置源依赖关系，提供跨构建导航和重构。

1.8.4。 声明由包含的构建替换的依赖项

默认情况下，Gradle将配置每个包含的构建，以确定它可以提供的依赖关系。 执行此操作的算法非常简单：Gradle将检查包含的构建中的项目的组和名称，并替代项目依赖关系，以匹配$ {project.group}：$ {project.name}的任何外部依赖关系。

有些情况下，由Gradle确定的默认替换不够，或者对于特定复合材料来说，它们不正确。 对于这些情况，可以显式声明包含的构建的替换。 例如，单项目构建“未发布”，它会生成一个java实用程序库，但不声明组属性的值：

例1.8.5。生成不声明组属性

build.gradle

apply plugin:'java'

当此构建包含在组合中时，它将尝试替换依赖模块“undefined：unpublished”（“undefined”是“project”的默认值，“unpublished”作为根项目名称）。 显然，这在组合构建中并不是非常有用。为了在复合构建中使用未修改的未发布库，组合构建可以显式地声明它提供的替换：

例1.8.6。 声明包含构建的替换

settings.gradle

rootProject.name ='app'includeBuild('../anonymous-library') {    dependencySubstitution {        substitute module('org.sample:number-utils') with project(':')    }}

使用此配置，“my-app”复合构建将替换任何依赖关系onorg.sample：number-utils与根目录“unpublished”的依赖关系。

1.8.4.1。 必须声明包含构建替换的情况

许多使用uploadArchivestask发布工件的构建函数将自动作为包含的构建函数而无需声明的替换。 以下是需要声明替换的常见情况：

当使用thearchivesBaseNameproperty来设置已发布工件的名称时。

当配置其他thandefaultis发布时：这通常意味着使用otheruploadArchivesis以外的任务。

当使用MavenPom.addFilter（）来发布与项目名称不匹配的工件时。

当使用themaven-publishorivy-publishplugins进行发布时，出版坐标与$ {project.group}不匹配：$ {project.name}。

1.8.4.2。 复合构建替换不起作用的情况

即使在显式声明依赖关系替换时，某些构建函数也不能正常运行。 此限制是由于替代的项目依赖性将始终指向目标项目的默认配置。 任何时候，为项目的默认配置指定的工件和依赖关系与实际发布到存储库的内容不匹配，则复合构建可能会表现出不同的行为。

以下是发布模块元数据可能与项目默认配置不同的一些情况：

当配置其他thandefaultis发布。

当使用themaven-publishorivy-publishplugins时。

当POMorivy.xml文件作为发布的一部分进行调整时。

使用这些功能构建功能在包含在复合构建中时功能不正确。 我们计划在未来改善这一点。

1.8.5。 在依赖中建立一个构建任务

虽然包含的构建是彼此隔离的，并且无法声明直接依赖关系，但是复合构建能够声明其包含的构建的任务依赖关系。 包含的构建使用Gradle.getIncludedBuilds（）或Gradle.includedBuild（java.lang.String）访问，并且通过theIncludedBuild.task（java.lang.String）方法获取任务引用。

使用这些API，可以声明对特定包含的构建中的任务的依赖性，或者在所有或部分包含的构建中具有特定路径的任务。

例1.8.7。 依赖所包含的构建中的单个任务

build.gradle

task run {    dependsOn gradle.includedBuild('my-app').task(':run')}

例1.8.8。 依赖所有包含的构建中具有路径的任务

build.gradle

task publishDeps {    dependsOn gradle.includedBuilds*.task(':uploadArchives')}

1.8.6。 复合构建的当前局限性和后期计划

我们认为复合构建是非常有用的。 然而，有些事情还没有按照我们想要的方式工作，而我们认为的其他改进将使事情更好。

目前实施的限制包括：

不支持包含不具有项目默认配置镜像的发布的构建。 请参见第11.4.2节“复合构建替换不起作用的情况”。

不支持本地构建。 （本地构建不支持二进制依赖关系）。

替代插件只适用于buildstriptblock，但不适用于插件块。

我们为即将发布的版本的改进包括：

更好地检测依赖替换，用于使用自定义坐标发布的构建，生成多个组件的构建等。这将减少需要为包含的构建显式声明依赖替换的情况。

能够直接从命令行定位包含的构建中的任务或任务。 我们正在探索允许此功能的语法选项，这将删除复合中需要委派任务的许多情况。

使implicitbuildSrcproject成为一个包含的构建。

支持复合复合构建。