Разработчики динамического языка программирования Groovy (http://groovy-lang.org/) объявили (http://glaforge.appspot.com/article/groovy-projects-intends-...) о решении перевести разработку под крыло организации Apache Software Foundation и направили (https://blogs.apache.org/foundation/entry/groovy_submitted_t...) соответствующую заявку (http://mail-archives.apache.org/mod_mbox/incubator-general/2...) на принятие проекта в инкубатор Apache. Язык Groovy заимствовал некоторые полезные качества Ruby, Haskell и Python, но создан для работы внутри виртуальной машины Java (JVM) и поддерживает тесную интеграцию с Java приложениями. За годы существования Groovy, вокруг данного языка сформировалась экосистема из связанных проектов, таких как MVC web-фреймворк Grails (http://grails.org/), swing-ориентированный фреймворк Griffon (http://griffon.codehaus.org/), системы сборки Gant (http://gant.codehaus.org/) и Gradle (http://gradle.org/), инструментарий для интеграции с Google App Engine - Gaelyk (http://gaelyk.appspot.com/), система параллельного программирования Gpars (http://gpars.codehaus.org/), тестовый комплект Spock (http://www.spockframework.org/), инструменты для контроля качества CodeNarc (http://codenarc.sourceforge.net/) и GMetrics (http://gmetrics.sourceforge.net/).Причиной перевода разработки в Фонд Apache является решение компании Pivotal по прекращению финансирования нескольких разработчиков, которым ранее предоставлялась возможность работы над проектом Groovy в режиме полного рабочего дня. Подобное решение заставило задуматься над тем, как сделать проект жизнеспособным в долгосрочной перспективе, независимо от наличия спонсорской поддержки и изменений в составе основной команды разработчиков. После проведения дискуссий с представителями различных организаций, в том числе с Eclipse Foundation и Software Conservancy, оптимальным вариантом, наиболее полно отвечающим текущей философии разработки Groovy, признана организация Apache Software Foundation.
После вынесения совместного решения о принятии проекта управляющим комитетом Фонда Apache, Groovy будет помещён в инкубатор (http://incubator.apache.org/) Apache, в котором будет выполнена подготовка инфраструктуры, проведён аудита лицензионной чистоты и проверка способности соблюдения принятых в сообществе Apache принципов разработки. В дальнейшем, как только проект покажет себя готовым для самостоятельного существования, не требующего дополнительного надзора, он будет переведён в число первичных проектов Apache. Groovy будет развиваться в соответствии с принципами меритократии, при которых решения принимают представители сообщества, вносящие наибольший вклад в развитие проекта.
URL: https://blogs.apache.org/foundation/entry/groovy_submitted_t...
Новость: http://www.opennet.me/opennews/art.shtml?num=41826
Заголовок не соответствует содержанию..
Что за старье начали постить? Pivotal очень давно уже сказал что груви развивать не будет, все надеялись что гугель возьмется но гугелю такие девелоперы которые развивают груви даром не нать. А вообще Groovy по большей части стал ненужен когда нормально стал работать JRuby, что собственно и стало причиной смерти оного.
Вы Java-код собираете из jrake? И тесты к нему у вас тоже на jruby? Ну и как вам это?
> Вы Java-код собираете из jrake? И тесты к нему у вас тоже на jruby? Ну и как вам это?Есть же легковесный maven. Зачем что-то ещё?
> Есть же легковесный maven.У жабистов свои понятия о легковесном. Если даунлоад менее 200 мегабайтов и запускается на 16-ядерном проце с 128 гигз - значит легковесный.
легковесно - значит операция за такт. Представляем вообще че при 6 тыщах оборотов в ДвигателеВнутреннегоСгорания делается?
>> Есть же легковесный maven.
> У жабистов свои понятия о легковесном. Если даунлоад менее 200 мегабайтов и
> запускается на 16-ядерном проце с 128 гигз - значит легковесный.А сколько это весит - в наше время только далбичей интересует, ну или лошков с префиксом PROGMEM..
вот как? как ты умудряешься *постоянно* говорить глупости? ну ведь даже чисто по теории вероятностей один раз что‐то умное сказать должен. ан нет…
1. ага, с конфигами в xml. gradle не так уж их плох на его фоне.
2. groovy достаточно удобен для писания скриптов сборки и тестов.
> 1. ага, с конфигами в xml.На момент создания maven'a формат представления XML был в моде. Сейчас ничто не мешает XML переписать в JSON.
> gradle не так уж их плох на его фоне.
Скажем так: gradle сильно избыточен. Зачем готовить стартовый стол на космодроме для запуска воздушного змея? И так ведь делается при любой сборке проекта...
> 2. groovy достаточно удобен для писания скриптов сборки и тестов.
sh-скрипт ещё более удобен, так как не нуждается в 100 мегабайтах поддерживающей инфраструктуры.
> Сейчас ничто не мешает XML переписать в JSON.ну, и что мне написать maven'у, чтобы он читал pom.json, а не pom.xml? гугль ничего не дал.
> Скажем так: gradle сильно избыточен
вы точно его пользовали? там configuration by convention, т.е. в широком ряде случаев она не нужна вообще или минимальна. в отличие от maven.
> sh-скрипт ещё более удобен, так как не нуждается в 100 мегабайтах поддерживающей инфраструктуры.
вы видели template engine на шелле? я видел, это ужасно.
> 1. ага, с конфигами в xml. gradle не так уж их плох на его фоне.Для Java xml вполне нормальное явление, потому как там работать с этим форматом очень удобно. Но maven я тоже не люблю. И не за xml.
izen не палился бы ты, в очередной раз, быдлоподелочки a la Hello World этим угробищем собираешь? А слабо собрать мавеном проект с тремя библиотеками, две из которых от третьей зависят? И по-теме: если в сабже будут так-же как в мавене ошибки править, то лучше сразу закопать. Баге с зависимостеми в мавене уже больше 12 (ДВЕНАДЦАТИ) ЛЕТ, и она не самая древняя.
Сам программирую на Java и скажу, что ваш maven гадость редкая.
Первое, что мне не нравится это подключение к репе и нет возможности работать оффлайн.
Ясно или не явно должен быть указан центральный репозиторий. Если скажем я захотел использовать только для решение зависимостей, то это не получится. А разрешение зависимостей порой еще больше создает проблем, чем их решает, а порой лишь создает иллюзию решения зависимостей. Потому как иногда получается так, что некоторые могут быть не явными.
В этом случае приходится разбираться в ручную. Поэтому для меня подручные инструменты это IDE среда и Ant и больше ничего.
> Сам программирую на Java и скажу, что ваш maven гадость редкая.
> Первое, что мне не нравится это подключение к репе и нет возможности
> работать оффлайн.Есть такая возможность. Maven может спокойно работать в оффлайне, если в его локальном репозитории находятся все необходимые артефакты. То же самое, кстати, должно обеспечиваться и другими системами сборки и управления зависимостями — это от средства сборки не зависит, так как родить отсутствующую зависимую библиотеку из выхлопа никто не может.
> Ясно или не явно должен быть указан центральный репозиторий.
Нет.
> Maven может спокойно работать в оффлайне, если в его локальном репозитории находятся все необходимые артефакты.А мне не нужны репозитории:) Но без них он видимо работать не хочет.
> Нет.
Ну вы же сами сказали локальный, но все же должен быть.
Я мавен давно включал, но потом понял(когда разбирался с ним) что мне он не нужен. Он только усложняет, но никак не решает самые простые мои задачи.
> как сделать проект жизнеспособным в долгосрочной перспективе
> перевести разработку под крыло организации Apache Software Foundationвзаимоисключающие параграфы рулят.
Пусть переименуют в "Gravy".
Это про который сам автор говорил "если бы я тогда знал о скале, то не стал бы его делать"?
Да, он самый
Не "знал" а "увидел" или как - то так, скалы тогда просто не было, она появилась сильно много позже, когда груви уже был достаточно матёрым и известным.
>>инструменты для контроля качества CodeNarcНу всё понятно, дальше можно не читать. Опять упоротые неосиляторы Си свой ЯП написали, а теперь его впаривают. Хоть бы не палились так явно ))
Я вот не понимаю одного. В Линухе столько софта нет, аналогичного винде. Тот же Electronic Workbench в конце 90х в винде был, а в линухе какая-то кривая поделка Spice с которой ни в зуб ногой без мана, как сделать простенькую симуляцию.
Гимп и Блендер ещё есть куда пилить, да куча всего не доделана для использования НЕ-программистами. Документация на русском опять же не для всего.
Нет, надо пилить свою ОС, свой компилятор Си, свой ЯП, и гнуть потом пальцы.А теперь поставь минус и листай дальше.