Pivotal прекращает разработку Groovy & Grails с 31 марта

[dim_s]

Неожиданно, учитывая нарастающую популярность Gradle, я думаю с Groovy все будет хорошо.

[crmMaster]

Я понимаю что конкуренция — это хорошо, но какова область использования Groovy? Я имею ввиду не то, что на нем можно сделать, а реальные проекты, где groovy активно используется.

[thunderspb]

Ну не знаю у кого как, а у нас активно в jenkins используются скрипты на Groovy.

[porutchik]

my.ihc.ru на Grails :)

[dim_s]

Система сборки Gradle написана на нем, она используется, например, в Android Studio для сборки проектов. А вот на счет grails не знаю.

[Losted]

Мы Gradle активно используем для сборки.

[bsideup]

bintray.com/ — дико быстро растущий бинарный репозиторий, скоро Maven Central обгонит такими темпами (и уже зеркалирует его, т.е. уже больше, чем Maven Central), про него вам jbaruch лучше расскажет)

netflix.com/ — сделали большую ставку на groovy & grails

LinkedIn используют Groovy в их деплоймент тулзах

Gradle написан на Groovy, а на него сейчас делают ставку большие корпорации.

grails.org/websites?offset=0&max=12 — вот тут куча страниц с проектами на grails

[netslavehq]

https://transferwise.com на Groovy + Grails

[vaniaPooh]

Тесты опять же пишут на Groovy.

[leventov]

Так может Gradleware и подхватит знамя. Им даже проще будет — сами подпилят Groovy в нужную сторону для нужд Gradle, а не ждать, когда там разрабы из Pivotal прочухаются.

[zloyreznic]

google что-то придумает

[megatron]

Мне кажется, им-то как раз дешевле и проще будет вернуться в сторону ant.

[nemezis]

Искренне надеюсь, что это никогда не случится

[igors48]

Что не так с Антом, по Вашему мнению, расскажите вкратце, пожалуйста.

[asm0dey]

Одно двойное слово: XML-программирование

[nemezis]

В контексте системы сборки для Android ANT морально устарел. Во первых, более сложные скрипты на ANT читать затруднительно, из — за мягко говоря странного синтаксиса (на мой взгляд). Во вторых, для таких простых и часто используемых операций как смена packageName, изменения поля в каком — либо классе для различных task'ов, приходится использовать мягко говоря не тривиальные методы. По большому счету вины ANT тут нет, есть плохая поддержка со стороны разработчиков Android, ведь для Gradle вышеописанные задачи решает отдельный плагин.

[igors48]

Cпасибо

[iZENfire]

В Ant императивное программирование на XML и стиль «GOTO» из бейсика между зависимыми целями сборки запутывает понимание.

Декларативное описание целей сборки в Maven на XML гораздо понятнее, но ограничивает процесс сборки возможностями используемых плагинов. Но плагины не такие выразительные — сделать что-то экзотическое не получится, либо достигается написанием собственного плагина (с большим трудом).

[bsideup]

экспериментальный проект для Maven-а под названием «Polyglot» частично решал эти ограничения, кстати:

github.com/takari/maven-polyglot

[igors48]

«Боги передумали» (с)

[jbaruch]

Есть довольно много вариантов, центральных два:

• Большие и богатые ребята, вложенные в G&G нанимают всех семерых. Тут можно подумать в первую очередь о Netflix и, например, RedHat.
• Создается фонд, куда ежемесячно скидываются все, кто может, сколько может.

[bsideup]

у RedHat сейчас есть своя игрушка в виде ceylon-lang.org

Я вот себе другой сценарий в голове рисую — Redhat (Ceylon), либо JetBrains (Kotlin) нанимают к себе всех семерых и ставят задачу по переманиваю всех юзеров G&G стека на их язык. Круто я завернул?:)

[jbaruch]

Я очень слабо вижу как кто либо из них начинает топить за другой язык, если честно. Цейлон не особо РедХатовский, его себе пилит Гевин, и никто ему не нужен, и он никому особо тоже. Но да, Нетфликс скорее, чем РедХат.

[bsideup]

Не-не, у меня-то идея в том, что они начнут пилить Ceylon\Kotlin, внося в него кусочки Groovy :) Ну, это из разряда безумия в моей голове:)

[jbaruch]

Ну это может быть, да. Хотя тоже вряд ли.

[leventov]

Gradleware не?

[jbaruch]

их там самих не намного больше семи, так что нет; тем более, что Грейлз им нафиг не сдался.

[leventov]

Ну пускай расширяются и переименуются в Groovyware

[jbaruch]

на какие шиши?

[leventov]

Ок, если Pivotal прекращает поддержку, значит никто им не платит. Значит, Grails никому не нужен. Значит, его можно закопать, а поддерживать Groovy, без развития, не думаю что сильно много ресурсов нужно. По Gradle уже понятно что бизнес за него готов вписаться и он никуда не денется. Значит, вопрос должен в любом случае как-то решиться.

[jbaruch]

прыжок «pivotal-у никто не платил -> Грейлз никому не нужен» мягко говоря не очевиден.
За Спринг им тоже никто не платит, да и JDK, последний раз что я проверял, был бесплатен.
Вряд-ли можно утверждать, что Спринг и Джава никому не нужны.

[leventov]

Те, кому Grails нужен, не должны хотеть и рыбку съесть, и за продукт не платить. Потому что если все будут действовать по такому принципу, проект загнется от безденежья, и потом им самим будет хуже, потому что останутся без багфиксов и развития. Бесплатность это прежде всего для казуалов / новичков, которые просто хотят попробовать продукт без геморроя или запустить свой трехстраничный некоммерческий сайт. Бизнес должен платить за ПО, так или иначе.

[zlo]

Тратиться можно приобретая расширенную поддержку или консалтинговые услуги. Открытость и бесплатность базового функционала обеспечивают распространенность технологии. Даже MS к этому пришли.

[leventov]

Ну, значит, компании должны приобретать эту поддержку, даже если она им не нужна. Объективно, она мало кому нужна — работники компании просто спрашивают на форуме/в рассылке/баг-трекере, как сделать то-то и то-то, или описывают проблему, и разрабы обычно так или иначе фиксят это в бесплатном режиме — не игнорить же «сообщество» в наглую. С консалтингом то же самое — если документация говно, проектом вряд ли даже начнут пользоваться, а если хорошая, то и консалтинг не нужен.

По-хорошему, конечно, open source разработка должна быть организована в виде фондов, а не консалтингово-поддерживающих компаний. Но тут дело в том, что на фонде не получится сильно разбогатеть, максимум будешь иметь hi-end зарплату. Но, с другой стороны, единицы консалтингово-поддерживающих компаний достигают такого успеха, чтобы дать своим со-основателям прямо разбогатеть. В массе это все равно то на то и получается — денег хватает как раз ± платить зарплату себе и работникам.

[khim]

Те, кому Grails нужен, не должны хотеть и рыбку съесть, и за продукт не платить.

Тем не менее это — типичная ситуация. Примерно как с realtime Linux'ом: компаний, которые интересуются когда будет сделана поддержка 3.16 — куча, компаний готовых за это платить нет вообще. Совсем. Ни одной.

Эффективные манагеры, как бы. Оно им потом аукнется, конечно, но пока они «оптимизируют затраты» и получают свои бонусы.

Тут может быть та же история.

[leventov]

Да, повсеместно такое. Надо просто не дурить и делать ПО платным, вот и все. Это, кстати, не противоречит открытости: лицензия на открытый код может быть вполне коммерческая.

[monzdrpower]

пара ссылок по теме
www.infoq.com/news/2015/01/Pivotal-Pulls-Groovy-Grails-Fund
kousenit.wordpress.com/2015/01/19/groovygrails-pivotal-opportunity/