Комментарии
13
Ушел и ушел. Устал. Groovy уже точно останется надолго и в Gradle, и в Jenkins Pipeline / configuration, и какой крутой скриптовый язык на JVM. Возможно, кто-то хотел сделать из Groovy системный язык, куда стремится Kotlin, а получился отличный скриптовый + Groovy DSL, благодаря которому мы и получили лучшую билд-систему.
Поведение сообщества, если все действительно так, похоже на какую-то дешевую мелодраму.
Вот тип взял и закомитил в Apache Groovy билд скрипт на языке, который сообщество Groovy считает враждебным конкурентом. И он был в курсе, что в сообществе Groovy Kotlin не любят. Вот какой реакции он ожидал?
Есть такой важный аспект как dogfooding. Как можно делать язык более удобным для пользователей, если самим его не использовать?
Последней каплей стало то, что на днях он закоммиттил в Apache Groovy билд-скрипт, написанный на Kotlin Gradle DSL (что вызвало возражения).Я убежден, что сообщество правильно отреагировало.
Представьте, что вы пишете проект на python, а туда вместо tasks.py запилиили Rakefile (Ruby).
Или в документацию вашего проекта некто Ван Нгуен добавляет страницы на вьетнамском вместо английского.
Ruby и вьетнамский язык сами по себе не плохие, но они неуместны в этих случаях.
Ну если уж продоожать эту мысль, зачем разработчикам Java изучать новый Groovy для билд скриптов Gradle? И зачем вообще Gradle если Maven вполне способен все собрать? :)
Я не JVM разработчик но сталкивался с ситуациями когда пытались прикрутить Gradle для CI — и честно, я непонимаю зачем он весь (и Groovy вместе с ним) нужен. Так как уже есть jenkins pipeline, maven (java), cmake/msbuild/ninja (плюсы). Изучать поверх этого Gradle + Groovy кажется чем то абсолютно избыточным и неуместным.
Ну если уж продоожать эту мысль, зачем разработчикам Java изучать новый Groovy для билд скриптов Gradle? И зачем вообще Gradle если Maven вполне способен все собрать? :)Потому что это языки разного назначения с разной сложностью запуска и конфигурации. Хороший пример — скрипты на bash или python в проекте на C++ для конфигурации. А вот для проектов на Ruby подобное уже не нужно.
Для Groovy Kotlin избыточен и вреден, он вносит лишь дополнительную сложность поддержки не привнося какой-либо пользы.
Я разделяю ваше непонимание и с удовольствием пользовался бы системой сборки, в которой всё писалось бы на чистой Java. Не вижу никаких киллер-фич, ради которых я бы предпочёл тот же Groovy или Kotlin. Да, на Java было бы больше синтаксического мусора. Но, особенно начиная с Java 8, не так уж и больше. Зато простота понимания куда лучше. Я Gradle пользуюсь много лет, но до сих пор копипасчу решения, а когда надо самому написать — это ад, автокомплит не работает, фиг пойми, что там вообще происходит. Но тут, понятное дело, пользоваться приходится тем, чем остальные пользуются. Индустриальные стандарты и всё такое.
с удовольствием пользовался бы системой сборки, в которой всё писалось бы на чистой Java
На правах шутки — project.jerkar.org
зачем он весь (и Groovy вместе с ним) нужен
Так как уже есть jenkins pipeline
А ничего что Jenkinsfile это Groovy?:)
Тут фокус в том что об этом можно (или ненужно) знать. :)
Люди открывают пример, видят stages… и сразу понимают как добавить новый этап сборки. Т.е. как тут уже писали — «just copy and paste», это то что по большому счету хотят видеть все разработчики. Причем насколько я понимаю Jenkins именно навязывает эту структуру и сам разбирает файл а не отдает весь на съедение Groovy, сам сталкивался много раз с ситуациями когда конструкции Groovy не работают в некоторых местах (изза специфики Jenkins).
А вот Gradle + Groovy, со своими импортами зависимостей и зависимости которые могут переопределять «все что движется» приводят к ситуациями когда девелопер со стажем 10+ лет должен тратить часы чтобы понять как оно вообще собирается и кто кого зовет. Вот до такого доводить нельзя но в Gradle мне показалось достичь этого очень легко именно потому что структуру можно полностью переопределить.
Люди открывают пример, видят stages… и сразу понимают как добавить новый этап сборки. Т.е. как тут уже писали — «just copy and paste», это то что по большому счету хотят видеть все разработчики. Причем насколько я понимаю Jenkins именно навязывает эту структуру и сам разбирает файл а не отдает весь на съедение Groovy, сам сталкивался много раз с ситуациями когда конструкции Groovy не работают в некоторых местах (изза специфики Jenkins).
А вот Gradle + Groovy, со своими импортами зависимостей и зависимости которые могут переопределять «все что движется» приводят к ситуациями когда девелопер со стажем 10+ лет должен тратить часы чтобы понять как оно вообще собирается и кто кого зовет. Вот до такого доводить нельзя но в Gradle мне показалось достичь этого очень легко именно потому что структуру можно полностью переопределить.
Как опытный Jenkins-овод, могу заверить:
1) "Groovy не работают в некоторых местах" — это скорее бага, чем особенность, которую они так и не смогли побороть
2) "тратить часы чтобы понять как оно вообще собирается и кто кого зовет" — так же применимо к Jenkinsfile-ам, иногда даже ситуация гораздо хуже, чем в Gradle.
3) "структуру можно полностью переопределить" — это не совсем так. В Gradle действительно можно "пачкать" variable scope, но нельзя, например, переопределить "configurations {}" блок, в итоге имеем структурированность практически как в декларативном Jenkinsfile-е
4) "stages" в Jenkinsfile только если использовать декларативный подход, он не всегда подходит, приходится использовать императивный, и там ад и содомия похлеще Gradle файлов
Думаю, это некорректное сравнение, поскольку «Ван Нгуен» не пытается заменить английский вьетнамским, а лишь добавляет поддержку нового языка. Кто не знает вьетнамский — просто читает документацию на английском. А вот вьетнамский язык может оказаться хорошим плюсом и привлечь в этом проекте дополнительных участников.
К тому же, Седрик Шампо не просто «ещё один» участник проекта, а тот, благодаря кому в проекте появились хорошие и полезные фичи (то есть, он явно не дилетант). Возможно, с его профессиональной точки зрения такие изменения хороши, когда другие не понимают его и ошибочно считают, что это неправильно (так сказать, эффект Даннинга — Крюгера, только с этим проектом всё сложнее, поскольку Седрик не является единственным профессионалом).
К тому же, Седрик Шампо не просто «ещё один» участник проекта, а тот, благодаря кому в проекте появились хорошие и полезные фичи (то есть, он явно не дилетант). Возможно, с его профессиональной точки зрения такие изменения хороши, когда другие не понимают его и ошибочно считают, что это неправильно (так сказать, эффект Даннинга — Крюгера, только с этим проектом всё сложнее, поскольку Седрик не является единственным профессионалом).
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Из Groovy ушёл Cédric Champeau