Gradle软件模型的现有优势和未来发展方向介绍

212 阅读7分钟

我们收到了许多关于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社区的其他成员相比,本地用户将不再有单独的扩展模型,他们将能够利用新的变体感知依赖管理。

为爱发展是什么样子的?以下是今年年底前的重点领域:

  • 对本地的当前模型支持。基于当前模型的新的插件集正在开发中,并随着每一次夜间发布而得到改进。他们仍然需要更多的工作来实现功能的平等和稳定,但已经提供了很多功能。试用它们并给我们反馈。
  • 编译和链接任务默认为并行。我们计划通过对编译和链接任务启用默认的并行性来改善本地生态系统的性能。这将对使用Gradle构建本地程序的所有人产生积极影响。
  • 横向依赖解决。我们正在从我们的JVM生态系统中移植这一强大的功能,以帮助本地开发者在本地项目之间声明丰富的依赖关系。
  • 在当前模式下的新本地插件。我们的计划是让插件具备软件模型插件的大部分功能,同时也会有大量的新功能,如构建缓存和本地的外部源依赖。
  • 改进工具链支持。我们正在研究解决工具链声明的一些问题,这对嵌入式开发特别重要。

为了获得最完整和最新的进展,我们建议看一下gradle-native项目,这是本地生态系统功能规划的家园。

用户从软件模型插件到新插件的迁移将是非常无缝的。所有的核心原生任务将被重用,工具链的概念将被移植到当前的模型中。我们期望你的很多构建逻辑可以被简单地重复使用。我们将在很长一段时间内支持基于软件模型的插件,以确保每个人都有一个成功的迁移。

如果你目前正在使用或计划使用Gradle来构建本地项目,请继续这样做。Gradle的本地支持一次又一次地证明了它比目前可用的工具更有性能,更灵活,更容易使用。

总结

今天,我们正在进行IDE集成和XCTest支持,并提供开箱即用的HTML报告生成和完整的构建扫描支持。工具链定义也将得到改进,以便更容易地与其他工具链系列集成;这对投资于嵌入式世界的用户来说尤其令人激动。

对于多资源库的开发者来说,你会很高兴地了解到,复合构建将适用于所有的本地项目。

image.png

新的插件将与Kotlin DSL集成,为Gradle用户提供适当的IDE支持,包括自动完成和重构。

我们将首先在当前模式下实现原生开发的完整工作流程,而不进行任何定制——即不配置平台、构建类型或工具链。我们所说的工作流程是指与构建二进制文件有关的一切,以及测试、打包、部署和与你最喜欢的IDE集成。起初,该工作流程将适用于最常见的情况。在随后的版本中,我们将通过向整个工作流程逐步添加定制化的内容来进行。

社区参与

我们的原生社区是论坛上最活跃和参与度最高的社区之一,我们希望鼓励和扩大这种参与度。 请继续在论坛上互相帮助,找到你所寻求的答案,但也请参与我们的工作,尝试各种原生示例项目,订阅gradle-native项目并提交问题,对对你最重要的问题进行投票,甚至考虑提交拉动请求,如果你很想卷起袖子参与进来的话。

被动地保持原生平台支持的最新信息的最好方法是订阅每月的通讯在Twitter上更频繁地发布消息。

我们期待着与您合作,开发出最好的原生构建工具。