Как стать автором
Обновить

Комментарии 5

Плагин для грэдла самый обычный. Смотрим «maven против gradle» батл — там аналогиные действия. Не понимаю в чем профит фиксированного имени плагина. Можете пояснить разницу?
Плагины можно вводить тремя способами:

* Прямо в сборочный скрипт
* В диреторию buildSrc
* Сделать отдельный проект

Имхо buildSrc — это разумный компромисс между первым и третьим. Плагин уже видно отовсюду и он не мозолит глаза в зонтичном сборочном файле, но еще не нужно соблюдать все ритуалы по поддержанию самостоятельного проекта.

Кроме того, buildSrc дает дополнительный уровень стандартизации, который упрощает людям жизнь в динамичном мире, в котором что угодно может лежать где угодно. С точки зрения нового разработчика, впервые сталкивающегося с проектом (а это почти все люди с Гитхаба, которые первый и последний раз забежали в проект, чтобы поправить единственный баг, который мешает лично им), четкое понятное место куда смотреть и патчить — лучше чем произвольное.
Попробовал трюк управления зависимостей через buildSrc, но с использованием Kotlin (ради string template). В итоге навигация и авто дополнение работают, но подсветка значения — нет. Вместо значения получаю:
public final val playServicesGcm: String defined in com.myapp.gradle.Libs

В случае с Java корректно показывает значение. Жаль :(
Нелегкая судьба первопроходца :) Спасибо!
А может, зарепортить в JetBrains? Если есть минимальный пример.

Попробуйте указать аннотацию @JvmField, потому что в Kotlin вы объявляете property (а это getter-метод), а не поле. Ну или писать что-то вроде getPlayServicesGcm(). Но думаю, учитывая возможность написания Gradle-скриптов на самом Kotlin, это всё не самые элегантные решения.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий