Я пишу пользовательский плагин Gradle, который использует мой пользовательский объект расширения. Я понял, что мне нужно использовать соглашениеMapping для ленивой оценки значения объекта расширения из этого ответа SO и форум Gradle.
Проблема возникает, когда я пытаюсь написать свой плагин с помощью обычного API Gradle (не API DSL). Я решил, что хочу сделать это, потому что это более удобно для IDE. Итак, создание задачи выполняется так:
MyTask task = project.tasks.create("mytask", MyTask)
task.?conventionMapping? ..
вместо
project.task(type:MyTask) {
conventionMapping.field = ..
}
MyTask расширяет DefaultTask, поэтому у него нет поля ConventionMapping. Затем я обнаружил, что часть реализации Task из Java-плагина Gradle является расширением ConventionTask, от которого, как я думал, я должен расшириться, но, к сожалению, эти факты снова меня смущают:
- Пакет ConventionTask является внутренним
- DefaultTask снабжен аннотацией @NoConventionMapping.
Я также нашел эту тему, в которой говорилось, что я не должен следовать соглашениям. Итак, мой вопрос: является ли ConventionMapping правильным способом написания плагина, использующего расширение? Если да, то как правильно их получить без магии gradle dsl?
conventionMapping
? Откладывание чего-либо вafterEvaluate { }
приводит к тому, что необходимо помещать туда зависимые вещи. Допустим, мой пользовательский плагин добавляет задачу типаZip
и устанавливаетbaseName
из нее вafterEvaluate
со значением, взятым из расширения плагина. Тогда клиентский проект, который использует этот плагин и ссылается на задачу типаmyZipTask.archivePath
, получит неправильный путь, если только вызовarchivePath
не будет выполнен также вafterEvaluate
. Однако не дело клиента догадываться о таких вещах заранее, не так ли? Любые советы по этому поводу? 21.10.2015