Pull to refresh

Comments 13

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

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

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

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


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

UFO just landed and posted this here
UFO just landed and posted this here
с удовольствием пользовался бы системой сборки, в которой всё писалось бы на чистой Java

На правах шутки — project.jerkar.org
зачем он весь (и Groovy вместе с ним) нужен

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

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

Тут фокус в том что об этом можно (или ненужно) знать. :)
Люди открывают пример, видят 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 файлов

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

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