Комментарии 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, это всё не самые элегантные решения.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
jugru.org
Численность
51–100 человек
Дата регистрации

Блог на Хабре