Из Groovy ушёл Cédric Champeau‏

[vics001]

Ушел и ушел. Устал. Groovy уже точно останется надолго и в Gradle, и в Jenkins Pipeline / configuration, и какой крутой скриптовый язык на JVM. Возможно, кто-то хотел сделать из Groovy системный язык, куда стремится Kotlin, а получился отличный скриптовый + Groovy DSL, благодаря которому мы и получили лучшую билд-систему.

[GeraJet]

Поведение сообщества, если все действительно так, похоже на какую-то дешевую мелодраму.

[poxvuibr]

Вот тип взял и закомитил в Apache Groovy билд скрипт на языке, который сообщество Groovy считает враждебным конкурентом. И он был в курсе, что в сообществе Groovy Kotlin не любят. Вот какой реакции он ожидал?

[justboris]

Есть такой важный аспект как dogfooding. Как можно делать язык более удобным для пользователей, если самим его не использовать?

[forester11]

Ну если уж продоожать эту мысль, зачем разработчикам Java изучать новый Groovy для билд скриптов Gradle? И зачем вообще Gradle если Maven вполне способен все собрать? :)

Я не JVM разработчик но сталкивался с ситуациями когда пытались прикрутить Gradle для CI — и честно, я непонимаю зачем он весь (и Groovy вместе с ним) нужен. Так как уже есть jenkins pipeline, maven (java), cmake/msbuild/ninja (плюсы). Изучать поверх этого Gradle + Groovy кажется чем то абсолютно избыточным и неуместным.

[dougrinch]

с удовольствием пользовался бы системой сборки, в которой всё писалось бы на чистой Java

На правах шутки — project.jerkar.org

[bsideup]

зачем он весь (и Groovy вместе с ним) нужен

Так как уже есть jenkins pipeline

А ничего что Jenkinsfile это Groovy?:)

[forester11]

Тут фокус в том что об этом можно (или ненужно) знать. :)
Люди открывают пример, видят stages… и сразу понимают как добавить новый этап сборки. Т.е. как тут уже писали — «just copy and paste», это то что по большому счету хотят видеть все разработчики. Причем насколько я понимаю Jenkins именно навязывает эту структуру и сам разбирает файл а не отдает весь на съедение Groovy, сам сталкивался много раз с ситуациями когда конструкции Groovy не работают в некоторых местах (изза специфики Jenkins).

А вот Gradle + Groovy, со своими импортами зависимостей и зависимости которые могут переопределять «все что движется» приводят к ситуациями когда девелопер со стажем 10+ лет должен тратить часы чтобы понять как оно вообще собирается и кто кого зовет. Вот до такого доводить нельзя но в Gradle мне показалось достичь этого очень легко именно потому что структуру можно полностью переопределить.

[bsideup]

Как опытный Jenkins-овод, могу заверить:
1) "Groovy не работают в некоторых местах" — это скорее бага, чем особенность, которую они так и не смогли побороть
2) "тратить часы чтобы понять как оно вообще собирается и кто кого зовет" — так же применимо к Jenkinsfile-ам, иногда даже ситуация гораздо хуже, чем в Gradle.
3) "структуру можно полностью переопределить" — это не совсем так. В Gradle действительно можно "пачкать" variable scope, но нельзя, например, переопределить "configurations {}" блок, в итоге имеем структурированность практически как в декларативном Jenkinsfile-е
4) "stages" в Jenkinsfile только если использовать декларативный подход, он не всегда подходит, приходится использовать императивный, и там ад и содомия похлеще Gradle файлов

[w0den]

Думаю, это некорректное сравнение, поскольку «Ван Нгуен» не пытается заменить английский вьетнамским, а лишь добавляет поддержку нового языка. Кто не знает вьетнамский — просто читает документацию на английском. А вот вьетнамский язык может оказаться хорошим плюсом и привлечь в этом проекте дополнительных участников.

К тому же, Седрик Шампо не просто «ещё один» участник проекта, а тот, благодаря кому в проекте появились хорошие и полезные фичи (то есть, он явно не дилетант). Возможно, с его профессиональной точки зрения такие изменения хороши, когда другие не понимают его и ошибочно считают, что это неправильно (так сказать, эффект Даннинга — Крюгера, только с этим проектом всё сложнее, поскольку Седрик не является единственным профессионалом).