How to become an author
Search
Write a publication
Pull to refresh

Comments 37

Неожиданно, учитывая нарастающую популярность Gradle, я думаю с Groovy все будет хорошо.
Total votes 5: ↑4 and ↓1 +3
Я понимаю что конкуренция — это хорошо, но какова область использования Groovy? Я имею ввиду не то, что на нем можно сделать, а реальные проекты, где groovy активно используется.
Total votes 3: ↑2 and ↓1 +1
Ну не знаю у кого как, а у нас активно в jenkins используются скрипты на Groovy.
Total votes 3: ↑2 and ↓1 +1
Система сборки Gradle написана на нем, она используется, например, в Android Studio для сборки проектов. А вот на счет grails не знаю.
Total votes 2: ↑2 and ↓0 +2
Мы Gradle активно используем для сборки.
This comment wasn’t rated yet 0
bintray.com/ — дико быстро растущий бинарный репозиторий, скоро Maven Central обгонит такими темпами (и уже зеркалирует его, т.е. уже больше, чем Maven Central), про него вам jbaruch лучше расскажет)

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

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

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

grails.org/websites?offset=0&max=12 — вот тут куча страниц с проектами на grails
Total votes 3: ↑3 and ↓0 +3
Тесты опять же пишут на Groovy.
This comment wasn’t rated yet 0
Так может Gradleware и подхватит знамя. Им даже проще будет — сами подпилят Groovy в нужную сторону для нужд Gradle, а не ждать, когда там разрабы из Pivotal прочухаются.
This comment wasn’t rated yet 0
Мне кажется, им-то как раз дешевле и проще будет вернуться в сторону ant.
Total votes 7: ↑1 and ↓6 -5
Искренне надеюсь, что это никогда не случится
Total votes 6: ↑6 and ↓0 +6
Что не так с Антом, по Вашему мнению, расскажите вкратце, пожалуйста.
Total votes 7: ↑1 and ↓6 -5
Одно двойное слово: XML-программирование
Total votes 9: ↑9 and ↓0 +9
В контексте системы сборки для Android ANT морально устарел. Во первых, более сложные скрипты на ANT читать затруднительно, из — за мягко говоря странного синтаксиса (на мой взгляд). Во вторых, для таких простых и часто используемых операций как смена packageName, изменения поля в каком — либо классе для различных task'ов, приходится использовать мягко говоря не тривиальные методы. По большому счету вины ANT тут нет, есть плохая поддержка со стороны разработчиков Android, ведь для Gradle вышеописанные задачи решает отдельный плагин.
Total votes 2: ↑1 and ↓1 0
В Ant императивное программирование на XML и стиль «GOTO» из бейсика между зависимыми целями сборки запутывает понимание.

Декларативное описание целей сборки в Maven на XML гораздо понятнее, но ограничивает процесс сборки возможностями используемых плагинов. Но плагины не такие выразительные — сделать что-то экзотическое не получится, либо достигается написанием собственного плагина (с большим трудом).
Total votes 1: ↑1 and ↓0 +1
экспериментальный проект для Maven-а под названием «Polyglot» частично решал эти ограничения, кстати:

github.com/takari/maven-polyglot
This comment wasn’t rated yet 0
Есть довольно много вариантов, центральных два:
  • Большие и богатые ребята, вложенные в G&G нанимают всех семерых. Тут можно подумать в первую очередь о Netflix и, например, RedHat.
  • Создается фонд, куда ежемесячно скидываются все, кто может, сколько может.
Total votes 2: ↑2 and ↓0 +2
у RedHat сейчас есть своя игрушка в виде ceylon-lang.org

Я вот себе другой сценарий в голове рисую — Redhat (Ceylon), либо JetBrains (Kotlin) нанимают к себе всех семерых и ставят задачу по переманиваю всех юзеров G&G стека на их язык. Круто я завернул?:)
Total votes 1: ↑1 and ↓0 +1
Я очень слабо вижу как кто либо из них начинает топить за другой язык, если честно. Цейлон не особо РедХатовский, его себе пилит Гевин, и никто ему не нужен, и он никому особо тоже. Но да, Нетфликс скорее, чем РедХат.
This comment wasn’t rated yet 0
Не-не, у меня-то идея в том, что они начнут пилить Ceylon\Kotlin, внося в него кусочки Groovy :) Ну, это из разряда безумия в моей голове:)
This comment wasn’t rated yet 0
Ну это может быть, да. Хотя тоже вряд ли.
This comment wasn’t rated yet 0
их там самих не намного больше семи, так что нет; тем более, что Грейлз им нафиг не сдался.
This comment wasn’t rated yet 0
Ну пускай расширяются и переименуются в Groovyware
This comment wasn’t rated yet 0
Ок, если Pivotal прекращает поддержку, значит никто им не платит. Значит, Grails никому не нужен. Значит, его можно закопать, а поддерживать Groovy, без развития, не думаю что сильно много ресурсов нужно. По Gradle уже понятно что бизнес за него готов вписаться и он никуда не денется. Значит, вопрос должен в любом случае как-то решиться.
Total votes 1: ↑1 and ↓0 +1
прыжок «pivotal-у никто не платил -> Грейлз никому не нужен» мягко говоря не очевиден.
За Спринг им тоже никто не платит, да и JDK, последний раз что я проверял, был бесплатен.
Вряд-ли можно утверждать, что Спринг и Джава никому не нужны.
Total votes 2: ↑1 and ↓1 0
Те, кому Grails нужен, не должны хотеть и рыбку съесть, и за продукт не платить. Потому что если все будут действовать по такому принципу, проект загнется от безденежья, и потом им самим будет хуже, потому что останутся без багфиксов и развития. Бесплатность это прежде всего для казуалов / новичков, которые просто хотят попробовать продукт без геморроя или запустить свой трехстраничный некоммерческий сайт. Бизнес должен платить за ПО, так или иначе.
Total votes 2: ↑2 and ↓0 +2
Тратиться можно приобретая расширенную поддержку или консалтинговые услуги. Открытость и бесплатность базового функционала обеспечивают распространенность технологии. Даже MS к этому пришли.
This comment wasn’t rated yet 0
Ну, значит, компании должны приобретать эту поддержку, даже если она им не нужна. Объективно, она мало кому нужна — работники компании просто спрашивают на форуме/в рассылке/баг-трекере, как сделать то-то и то-то, или описывают проблему, и разрабы обычно так или иначе фиксят это в бесплатном режиме — не игнорить же «сообщество» в наглую. С консалтингом то же самое — если документация говно, проектом вряд ли даже начнут пользоваться, а если хорошая, то и консалтинг не нужен.

По-хорошему, конечно, open source разработка должна быть организована в виде фондов, а не консалтингово-поддерживающих компаний. Но тут дело в том, что на фонде не получится сильно разбогатеть, максимум будешь иметь hi-end зарплату. Но, с другой стороны, единицы консалтингово-поддерживающих компаний достигают такого успеха, чтобы дать своим со-основателям прямо разбогатеть. В массе это все равно то на то и получается — денег хватает как раз ± платить зарплату себе и работникам.
Total votes 1: ↑1 and ↓0 +1
Те, кому Grails нужен, не должны хотеть и рыбку съесть, и за продукт не платить.
Тем не менее это — типичная ситуация. Примерно как с realtime Linux'ом: компаний, которые интересуются когда будет сделана поддержка 3.16 — куча, компаний готовых за это платить нет вообще. Совсем. Ни одной.

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

Тут может быть та же история.
Total votes 1: ↑1 and ↓0 +1
Да, повсеместно такое. Надо просто не дурить и делать ПО платным, вот и все. Это, кстати, не противоречит открытости: лицензия на открытый код может быть вполне коммерческая.
This comment wasn’t rated yet 0
Sign up to leave a comment.

Articles

Unlock dark mode

Your account

Sections

Information

Services

Support
© 2006–2024, Habr