Gradle 软件模型的现状与未来
介绍
我们收到了许多关于 Gradle 的软件模型 的状态和方向的咨询，特别是来自构建原生库和应用程序的用户的咨询。
在这篇博文中，我们将解释软件模型的当前状态和未来，特别是它与 Gradle 原生开发的关系。2017 年剩余时间计划进行许多令人兴奋的改进；请参阅下面的路线图。
软件模型的现状 #
简而言之，软件模型是一种非常声明式的方式来描述如何构建一个软件以及它在过程中作为依赖项需要的其他组件。它还为配置 Gradle 构建提供了一个新的、基于规则的引擎。当我们开始实施软件模型时，我们为自己设定了以下目标
- 提高配置和执行时间性能。
- 使复杂工具链的构建定制更容易。
- 提供更丰富、更标准化的方式来建模不同的软件生态系统
在开发软件模型时，Gradle 工程团队不断尝试将这些概念应用于现有的软件生态系统。用于构建原生应用程序的 Gradle 插件目前完全基于软件模型。同样，也为 Android 和 Java 等生态系统开发了基于软件模型的实验性插件。
Gradle 在原生生态系统中的采用率正在上升，我们的投资也在增加。自成立以来，Gradle 的原生支持已被证明是使用 Make 进行构建的一个受欢迎的替代方案。凭借其声明式和富有表现力的模型，对不同工具链和平台的支持以及诸如并行编译之类的功能，它为构建原生库和应用程序提供了一种革命性的方式。
我们花费了比预期更长的时间来发展新的配置和软件模型，并使其像当前 Java 和 Android 的 Gradle 模型一样强大。与此同时，Gradle 的采用率飞速上升，有许多复杂的构建都在使用当前模型，并且还有一个由 1500 多个社区插件组成的活跃生态系统。我们低估了这些构建和插件迁移到新模型的复杂性，并看到了许多合作伙伴对进行这种迁移的可以理解的抵制。
事后看来，新的软件和配置模型的范围太大了。这就是为什么在 2016 年 Gradle 峰会上，Hans Dockter 宣布我们将把它的许多功能反向移植到当前模型。一年后，Java 和 Android 生态系统的大部分功能已被反向移植。这包括变体感知的依赖项解析和 Java 组件的 API 和实现分离。这些功能在避免工作和性能方面改变了游戏规则。此外，我们找到了其他方法来大幅提高 Gradle 配置性能，而且还会有更多改进。不再需要在 Gradle 构建配置方式上进行剧烈的、不兼容的更改。
前进方向 #
因此，您可能想知道软件模型发生了什么。我们正在将原生支持的配置 DSL 移植到当前模型。因此，声明式特性和强大的建模语言将保持不变。作为软件模型一部分的规则引擎将被弃用。模型块下的所有内容都将作为扩展移植到当前模型。与 Gradle 社区的其他成员相比，原生用户将不再有单独的扩展模型，并且他们将能够利用新的变体感知依赖项管理。
路线图是什么样的？以下是到今年年底的重点领域
- 当前模型对原生的支持。基于当前模型的新插件集正在开发中，并在每个 nightly 版本中得到改进。它们仍然需要更多的工作来实现功能对等和稳定性，但已经提供了很多功能。试用它们并给我们反馈。
- 编译和链接任务默认并行。计划通过启用编译和链接任务的默认并行性来提高原生生态系统的性能。这将对每个使用 Gradle 构建原生项目的人产生积极影响。
- 传递依赖项解析。我们正在将这个强大的功能从我们的 JVM 生态系统移植过来，以帮助原生开发人员声明原生项目之间丰富的依赖关系。
- 当前模型上的新原生插件。我们的计划是拥有具有软件模型插件的大部分功能，并且还将具有重要的新功能（如构建缓存和原生外部源依赖项）的插件。
- 改进的工具链支持。我们正在研究解决工具链声明中的一些问题，这对于嵌入式开发尤为重要。
为了获得最完整和最新的进展，我们建议您查看 gradle-native 项目，这是原生生态系统功能规划的家园。
用户从软件模型插件到新插件的迁移将非常顺利。所有核心原生任务都将被重用，工具链概念将被移植到当前模型。我们预计您的许多构建逻辑都可以简单地重用。我们将长期支持基于软件模型的插件，以确保每个人都能成功迁移。
如果您目前正在使用或计划使用 Gradle 构建原生项目，请务必继续这样做。Gradle 的原生支持一次又一次地被证明比当前可用的工具更高效、更灵活、更易于使用。
令人兴奋的进展 #
今天，我们正在致力于 IDE 集成和 XCTest 支持，以及开箱即用的 HTML 报告生成和完整的构建扫描支持。工具链定义也将得到改进，以允许更轻松地与替代工具链系列集成；这对于投资于嵌入式世界的用户来说尤其令人兴奋。
对于多仓库开发人员，您会很高兴得知组合构建将适用于所有原生项目。
新插件将与 Kotlin DSL 集成，这将为 Gradle 用户提供适当的 IDE 支持，包括自动完成和重构。
我们将首先在当前模型中实现原生开发的完整工作流程，而无需任何自定义 - 即没有平台、构建类型或工具链配置。我们所说的工作流程是指与构建二进制文件、以及测试、打包、部署和与您最喜欢的 IDE 集成相关的所有内容。首先，该工作流程将适用于最常见的情况。在后续版本中，我们将逐步为整个工作流程添加自定义。
社区参与 #
我们的原生社区是在论坛上最活跃和参与度最高的社区之一，我们希望鼓励并进一步加强这种参与。请继续在论坛上互相帮助寻找您正在寻求的答案，并通过尝试各种原生示例项目、订阅 gradle-native 项目和提交问题、投票选出对您最重要的问题，甚至考虑提交 pull request（如果您很乐意卷起袖子并参与进来）来与我们互动。
被动了解原生平台支持的最新信息的最佳方法是订阅每月新闻通讯或更频繁地关注 Twitter 上的公告。
我们期待与您合作开发最好的原生构建工具！