gradle - 如何以 Gradle 推荐的方式在 Gradle Plugin 中注入(inject)依赖项？

Question

我正在编写一个自定义插件并对其进行测试，我想注入(inject)模拟实现。它不仅用于测试，而且从 API 的角度来看，我想根据上下文注入(inject)不同的实现。我目前正在使用 Gradle 2.6，并且我知道它支持某种形式的依赖注入(inject)。我不想使用 Spring/Guice/HK2，因为 Gradle 本身支持它。但是，我无法找到如何使用 Gradle 2.6 API 注入(inject)依赖项的任何信息。

例如:

 class CustomTask extends DefaultTask {

       private SomeInterface interface

       @Inject
       CustomTask(SomeInterface interface) {}

       @TaskAction
       public void executeTask() {
           interface.executeSomething()
       }
 }

所以，本质上，我想弄清楚在哪里为 SomeInterface 的不同实例定义绑定(bind)。以及将其注入(inject)任务或其他任何地方(如某些自定义类)的机制。

Answer 1

由于此问题尚未结束，因此某些信息可能对遇到它的人仍然有用。

I do not want to use Spring/Guice/HK2 since Gradle itself supports it.

您可能已经在 gradle 论坛上看到了相关讨论。
https://discuss.gradle.org/t/dependency-injection-in-gradle-plugins/6538

We are currently working on this. Dependency injection is already available for internal Gradle services, but I'm guess you are wanting to inject your own collaborators. Our dependency injection will support this at some point.

与通常使用 Gradle 一样，我们可以检查 toastr 中的任何内容。
https://github.com/gradle/gradle/tree/bd4fb1c396a695d55aeba9bc37e164a488c0b882/design-docs

该设计文档可以让您了解核心维护者认为解决问题的好方法。虽然它不完整，但我认为它非常有值(value)。

不幸的是，文档(连同完整的文件夹)已被删除 on Sep 20, 2017带有以下消息:

This has turned into a graveyard for ideas. It only serves to confuse people at this point. We have found it more productive to either

• use GitHub Epics and issues for smaller design questions
• use Google Docs for larger topics (e.g. native publishing)

These documents quickly go out of date once a feature is implemented. They are not a replacement for good user and code documentation.

Many of the documents are about features that we never ended up implementing. Having those documents still around might lock us into a certain way of thinking about a problem. Instead we should have a fresh look at it when we actually want to start working on it.