Комментарии 5
Плагин для грэдла самый обычный. Смотрим «maven против gradle» батл — там аналогиные действия. Не понимаю в чем профит фиксированного имени плагина. Можете пояснить разницу?
Плагины можно вводить тремя способами:
* Прямо в сборочный скрипт
* В диреторию buildSrc
* Сделать отдельный проект
Имхо buildSrc — это разумный компромисс между первым и третьим. Плагин уже видно отовсюду и он не мозолит глаза в зонтичном сборочном файле, но еще не нужно соблюдать все ритуалы по поддержанию самостоятельного проекта.
Кроме того, buildSrc дает дополнительный уровень стандартизации, который упрощает людям жизнь в динамичном мире, в котором что угодно может лежать где угодно. С точки зрения нового разработчика, впервые сталкивающегося с проектом (а это почти все люди с Гитхаба, которые первый и последний раз забежали в проект, чтобы поправить единственный баг, который мешает лично им), четкое понятное место куда смотреть и патчить — лучше чем произвольное.
* Прямо в сборочный скрипт
* В диреторию buildSrc
* Сделать отдельный проект
Имхо buildSrc — это разумный компромисс между первым и третьим. Плагин уже видно отовсюду и он не мозолит глаза в зонтичном сборочном файле, но еще не нужно соблюдать все ритуалы по поддержанию самостоятельного проекта.
Кроме того, buildSrc дает дополнительный уровень стандартизации, который упрощает людям жизнь в динамичном мире, в котором что угодно может лежать где угодно. С точки зрения нового разработчика, впервые сталкивающегося с проектом (а это почти все люди с Гитхаба, которые первый и последний раз забежали в проект, чтобы поправить единственный баг, который мешает лично им), четкое понятное место куда смотреть и патчить — лучше чем произвольное.
Попробовал трюк управления зависимостей через buildSrc, но с использованием Kotlin (ради string template). В итоге навигация и авто дополнение работают, но подсветка значения — нет. Вместо значения получаю:
В случае с Java корректно показывает значение. Жаль :(
public final val playServicesGcm: String defined in com.myapp.gradle.Libs
В случае с Java корректно показывает значение. Жаль :(
Нелегкая судьба первопроходца :) Спасибо!
А может, зарепортить в JetBrains? Если есть минимальный пример.
А может, зарепортить в JetBrains? Если есть минимальный пример.
Попробуйте указать аннотацию @JvmField
, потому что в Kotlin вы объявляете property (а это getter-метод), а не поле. Ну или писать что-то вроде getPlayServicesGcm()
. Но думаю, учитывая возможность написания Gradle-скриптов на самом Kotlin, это всё не самые элегантные решения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование buildSrc для внедрения дополнительной логики в Gradle