Как внедрить зависимости в Gradle Plugin в Gradle рекомендуемым способом?

Я пишу собственный плагин и, чтобы протестировать его, хочу внедрить фиктивные реализации. Это не только для тестирования, но и с точки зрения API, я хочу внедрить разные реализации в зависимости от контекста. В настоящее время я использую Gradle 2.6 и понимаю, что он поддерживает некоторую форму внедрения зависимостей. Я не хочу использовать Spring/Guice/HK2, поскольку сам Gradle поддерживает его. Однако я не могу найти никакой информации о том, как внедрять зависимости с помощью API-интерфейсов Gradle 2.6.

Например:

 class CustomTask extends DefaultTask {

       private SomeInterface interface

       @Inject
       CustomTask(SomeInterface interface) {}

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

Итак, по сути, я хочу понять, где определить привязки для разных экземпляров SomeInterface и механизм для их внедрения в задачу или куда-либо еще, например, в некоторые пользовательские классы.


gradle dependency-injection gradle-plugin
person chauhraj    schedule 11.09.2015    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Поскольку этот вопрос не был закрыт, некоторая информация все еще может быть полезна для тех, кто столкнется с ним.

Я не хочу использовать Spring/Guice/HK2, поскольку сам Gradle поддерживает его.

Возможно, вы уже видели соответствующее обсуждение на форуме Gradle.
https://discuss.gradle.org/t/dependency-injection-in-gradle-plugins/6538

В настоящее время мы работаем над этим. Внедрение зависимостей уже доступно для внутренних служб Gradle, но я предполагаю, что вы хотите внедрить своих собственных соавторов. Наша инъекция зависимостей будет поддерживать это в какой-то момент.

Как обычно с Gradle, мы можем проверить все, что находится в духовке.
https://github.com/gradle/gradle/tree/bd4fb1c396a695d55aeba9bc37e164a488c0b882/design-docs

Этот проектный документ может дать вам представление о том, что, по мнению одного из основных сопровождающих, является хорошим подходом к решению проблемы. Хотя он не завершен, я считаю его весьма ценным.

К сожалению, документ (вместе со всей папкой) был удален 20 сентября 2017 г. со следующим сообщением:

Это превратилось в кладбище для идей. Это служит только для того, чтобы запутать людей в этот момент. Мы сочли более продуктивным либо

  • используйте GitHub Epics и Issues для небольших вопросов по дизайну
  • используйте Документы Google для более крупных тем (например, собственные публикации)

Эти документы быстро устаревают после реализации функции. Они не заменяют хорошую пользовательскую документацию и документацию по коду.

Многие документы касаются функций, которые мы так и не реализовали. Наличие этих документов может привести нас к определенному способу мышления о проблеме. Вместо этого мы должны по-новому взглянуть на него, когда мы действительно хотим начать над ним работать.

person dbalakirev    schedule 20.04.2017