gradle自定义依赖_反对buildsrc定义的依赖项或如何无缝地保持gradle的参数

最新推荐文章于 2024-07-22 17:53:32 发布

weixin_26711867

最新推荐文章于 2024-07-22 17:53:32 发布

阅读量502

点赞数

文章标签： java gradle spring android python

原文链接：https://medium.com/@wzieba/an-argument-against-buildsrc-defined-dependencies-or-how-to-seamlessly-keep-your-gradle-8e0bfd7ee8e3

版权

gradle自定义依赖

Managing dependencies is crucial for every project, especially those with large number of them included in many modules. The important part of managing is taking care of updates in order to decrease progressive tech debt. I find below conference keynote by Eileen M. Uchitelle as a great example of what can be the cost of, maybe sometimes unaware, neglected tech debt:

对于每个项目，管理依赖关系至关重要，尤其是在许多模块中包含大量依赖关系的项目。管理的重要部分是照顾更新，以减少进步的技术债务。我在下面的Eileen M. Uchitelle的会议主题演讲中可以找到一个很好的例子，说明被忽视的技术债务的成本，有时甚至是不为人所知：

如何使基于Gradle的项目依赖关系保持最新状态？ (How to keep your Gradle-based project dependencies up to date?)

Github recently announced Dependabot version updates system. This tool can automatically scan for dependencies defined in build.gradle files and create a pull request with a version update:

Github最近宣布了Dependabot版本更新系统。该工具可以自动扫描build.gradle文件中定义的依赖项，并使用版本更新创建请求请求：

https://github.com/wzieba/BuildSrcVsGradleExtraProperties/pull/2

Image for post — Sample pr created by Dependabot #1

For the detailed configuration possibilities, like scan intervals, max pull request count and more go to the official documentation.

有关详细的配置可能性，例如扫描间隔，最大拉取请求数等，请转至官方文档。

This is great for two reasons: firstly, it’ll reduce the time of developers by reminding about updates and even creating simple PRs which, in case of no errors thrown by your CI/CD system, might be assumed as valid and safe (especially minor/patch bumps). Secondly, if the configuration won’t limit number of open PRs, it’ll increase awareness of tech debt. Having one or two dependencies that are not up to date might not be a problem, but seeing ~20 open PRs might scare any developer and/or project manager. I believe, a massive number of open PRs created by Dependabot can emphasize the problem and be helpful in any negotiations on the importance and need of taking care of strictly technical aspects of the project.

之所以如此出色，有两个原因：首先，它会通过提醒更新甚至创建简单的PR来减少开发人员的时间，在您的CI / CD系统没有错误的情况下，这些PR可能被认为是有效且安全的(尤其是次要/补丁颠簸)。其次，如果该配置不限制未完成PR的数量，则会提高对技术债务的意识。具有一个或两个不是最新的依赖关系可能不是问题，但是看到约20个开放的PR可能会吓到任何开发人员和/或项目经理。我相信，由Dependabot创建的大量开放式PR可以强调该问题，并有助于就严格遵守项目技术方面的重要性和需求进行的任何谈判。

局限性？您不能使用Dependabot (Limitations? You can’t use Dependabot)

This works really great but comes with one major limitation: currently, you can’t use this bot when defining dependencies under buildSrc directory. The Github issue has been reported, but since March 2019 nothing has changed: https://github.com/dependabot/dependabot-core/issues/2180.

这确实很棒，但有一个主要限制：当前，在buildSrc目录下定义依赖项时，您不能使用此bot。 Github问题已被报道，但是自2019年3月以来没有任何变化： https : //github.com/dependabot/dependabot-core/issues/2180 。

It shouldn’t stop us to use Dependabot though. Furthermore: I would advise to every Gradle-based project to drop buildSrc support for declaring dependencies and use Gradle Extra Properties instead, which is a suggested way of managing dependencies by Android.

但是，这不应阻止我们使用Dependabot。此外：我建议每个基于Gradle的项目都放弃buildSrc支持，以声明依赖项，而改用Gradle Extra Properties，这是Android管理依赖项的建议方式。

Let’s rewind and remind ourselves why do we use buildSrc :

让我们倒带并提醒自己为什么要使用buildSrc ：

在buildSrc目录下定义依赖项的优点 (Pros of defining dependencies under buildSrc directory)

Many Gradle-based projects use buildSrc directory, which is treated as included build. Its easier to write and maintain configuration code in strongly typed JVM languages like Java or Kotlin, especially for writing custom tasks or plugins. That’s why Gradle docs stand to favor buildSrcover any script code:

许多基于Gradle的项目都使用buildSrc目录，该目录被视为包含的构建。以强类型的JVM语言(例如Java或Kotlin)编写和维护配置代码更加容易，尤其是在编写自定义任务或插件时。这就是为什么Gradle文档buildSrc支持buildSrc不是任何脚本代码：

buildSrc should be preferred over script plugins as it is easier to maintain, refactor and test the code. ~ source: docs.gradle.org

与脚本插件buildSrc应该首选buildSrc因为它更易于维护，重构和测试代码。〜资料来源： docs.gradle.org

But the majority of projects I’ve seen, use buildSrc only to provide and maintain dependencies definitions. What is the main, and I believe the only argument? The answer is: autocompletion

但是我见过的大多数项目仅使用buildSrc来提供和维护依赖项定义。主要是什么，我相信唯一的论点是？ 答案是：自动补全

Browsing through the articles I couldn’t find any other argument than this.

浏览这些文章，除了这个，我找不到其他论点。

buildSrc依赖项的缺点 (Cons of buildSrc dependencies)

You can’t use Android Studio prompts
您不能使用Android Studio提示

If dependencies are defined as plain-text or by Gradle Project Extensions, the Android Studio build-in prompt system will inform about any update. It will highlight any outdated dependencies as well as suggest version bump.

如果依赖项定义为纯文本或Gradle Project Extensions，则Android Studio内置提示系统将通知您任何更新。它将突出显示所有过时的依赖项并建议版本增加。

2. You can’t use Dependabot

2.您不能使用Dependabot

And this was dealbreaker for me. As mentioned above, Dependabot can only scan for dependencies that are declared as plaintext or declared with Gradle Extra Properties: https://github.com/dependabot/feedback/issues/392

这对我来说是个大难题。如上所述，Dependabot只能扫描声明为纯文本或使用Gradle Extra属性声明的依赖项： https : //github.com/dependabot/feedback/issues/392

甜蜜点？使用Gradle额外属性 (Sweetspot? Use Gradle Extra Properties)

With GEP you have access to Android Studio prompt as well as Dependabot tool. What you loose is only code autocompletion, which sounds as very little lose compared to unlocking tools for automated tech-debt reduction.

使用GEP，您可以访问Android Studio提示以及Dependabot工具。您松懈的只是代码自动完成，与用于自动减少技术债务的解锁工具相比，这听起来损失很小。

Or is there anything I’ve missed? Do you use buildSrc for dependency management? If so, is there anything more than just code autocompletion comparing to Gradle Extra Properties?

还是我错过了什么？您是否使用buildSrc进行依赖性管理？如果是这样，那么与Gradle Extra Properties相比，代码自动补全功能还有什么？