Бывало у вас такое пытаешься ты написать скрипт для Gradle, и во время его написания, будто магия какая-то происходит. В одном месте так нужно писать, в другом по другому.
Вся это магия происходит из-за неудачного выбора Gradle. Смысл в чем, Gradle работает на базе JVM, естественно разработчики хотели для написания скриптов язык который максимально близок к JVM.
Эта близость нужна из-за Maven. В индустрии тогда было принято писать плагины на Java, естественно нужно было сделать мягкий переход для новых пользователей, чтобы откушать часть рынка у Maven.
Помимо этого, язык должен быть скриптовым, не охото компилировать скрипты перед компиляцией проекта.
В момент разработки Gradle таких языков было всего 2: Groovy и Clojure. В расчет не берем всяких JPython и подобных монстров. Clojure не стали использовать так как, он вышел буквально за год до выхода Gradle и его никто не воспринимал всерьез. Плюс, писать скрипты в стиле Lisp не каждый захочет. Остался только один единственный вариант – Groovy.
Groovy отлично подходил под требования. Одновременно и динамический и типизированный, работает на базе JVM и имеет кучу синтаксического сахара. Вот только этот самый сахар и создает ощущение магии для всех, что пытался погрузиться в тему с Gradle. Вот смотрите, на примере, базовая вещь, как можно указать Gradle где находятся сорцы:
1️⃣
sourceSets {
main {
java {
srcDirs('src')
}
}
}2️⃣
sourceSets.main.java.srcDirs = [‘src’]3️⃣
sourceSets.main.java.srcDirs('src')Три способа сделать одно и тоже. Приверженцы дзена Python на этом момент должны были в космос улететь от ярости. И ведь это только один мелкий пример, добавить сюда еще то, что ты каждый раз гадаешь типы входного аргумента и что в Gradle все мутабельное и можно поменять почти все что хочешь в любом месте.
Мы с вами творческие ребята, разумеется иногда это круто, когда у тебя есть несколько способов решить задачу. По себе знаю, что иногда хочется выебнутся и решить типичную задачу новым способом. Это круто, когда это все в меру то почему нет? Однако это относится только к основному проекту. В билд системе напротив, такого точно не должно быть, в ней должен быть только один единственно правильный способ сделать что-то. Это важно по двум причинам:
☝️У разработчиков самой билд системы должна быть возможность проводить оптимизации исходя из того, что есть только один способ что-то сделать. Когда ты точно уверен, что у клиента нет возможности сделать что-то иначе, это развязывает тебе руки в оптимизации.
✌️У разработчиков, которые используют билд систему, не должно быть сложностей в изменении скриптов. С Gradle же ты начинаешь в угадайку играть, перебирая различные варианты скопированные с инета.
Ну что тут можно сказать. Скорее всего в ближайшие годы мы не слезем с иглы Gradle. Поэтому если хотите уменьшить уровень магии и упростить себе жизнь, посвятите часок другой изучению Groovy.