Comments 137
Скажите, вам не кажется что тема мувена неактуальна? Даже для ван Зил избегает своего детища.
тот же Spring Boot его использует и по сей день
Ну а как же, его много кто использует, только вот слезть с него не так то просто, история с коболом повторяется. Если вы в здравом уме и у вас есть выбор для нового проекта между gradle/sbt и maven, вы скорее всего выберете что то из первых двух(даже если они совместимы с репозиториями мувена), ван Зил наверное тоже.
Я с 2010 года слышу о революции в мувене о проекте полиглот, но никакой революции не было и быть не могло.
Я с 2010 года слышу о революции в мувене о проекте полиглот, но никакой революции не было и быть не могло.
Основная причина этого было то что до появления Maven 3.3.1 Core Extensions для использования проекта polyglot приходилось патчить сам maven. Сейчас дело с ним налаживается
Там, вроде бы, не все так просто с обратной совместимостью, заявленной еще в далеком 2010. Это только пока версия 0.1.5, и нет гарантий что она не зачахнет еще на несколько лет как версия до этого.
Очень часто есть trade-off и обратная совместимость зависит от того оставлять ли старое говнище или убирать его)
Все возможно. Но прошлая версия зачахла, так как со стороны энтерпрайз не было большого интереса к этой фиче
Все возможно. Но прошлая версия зачахла, так как со стороны энтерпрайз не было большого интереса к этой фиче
Продолжая тему maven habrahabr.ru/post/264415
Репозитарий maven делает возможным подгрузку модулей в существующее java приложение без его модификации.
Use case очень похож на Groovy Grape.
Репозитарий maven делает возможным подгрузку модулей в существующее java приложение без его модификации.
Use case очень похож на Groovy Grape.
Spring boot его использует только потому что Dave Syer — упёртый фанатик. Перед SpringOne 2 года назад, когда релиз поджимал, ни у кого не было времени и сил с ним спорить. Все остальные проекты Spring давно уже на Грейдле.
Разгадка почему они на maven, кроется в магии из пакета github.com/spring-projects/spring-boot/tree/master/spring-boot-cli/src/main/java/org/springframework/boot/cli/compiler/autoconfigure
При том что они активно используют Groovy, они все же выбрали maven. Зря вы клеймите фанатизмом
При том что они активно используют Groovy, они все же выбрали maven. Зря вы клеймите фанатизмом
Я говорил с Дейвом, и я говорил с его шефом Йоргеном об этом. Дейв сказал, что он любит и знает Мавен, и хотя его все уговаривали, что на Грейдле это можно все сделать тоже, у него нет ни сил ни желания учить эту хипстерскую хуету, а Йорген сказал, что поскольку время поджимало, он разрешил не насиловать Дейва Грейдлом и дать ему сделать то, что он знает.
Барух, понимаешь что я не бухал с этими людьми. Но как увижу — сразу узнаю)))
Ну зато я бухал, и все тебе уже рассказал как есть. Попытки притянуть туда рационал о том, что Мавен был выбран, а не Грейдл, из за какой-то функциональности, которая, якобы доступна только в первом, и никак её не решить со вторым, они, конечно, оправданы для тех, кто не знает этой кухни. А кто знает, тот понимает, что Дейв — немножко фанатик, и объясняется всё именно этим.
Понимаешь, я это проверить не смогу и стараюсь критически воспринимать рассказы. Ты считаешь что человек, который отлично владеет технологией и успешно использует её вместо того чтобы использовать «хипстерскую хуету» — априори фанатик?
Ну это рассказы от первого лица, так что можешь верить. А можешь и не верить. Он фанатик не потому что использует Мавен, а потому что вся экосистема Спринга перешла на Грейдл по определенным причинам, а он даже не стал проверять, имеет ли смысл делать Бут на Грейдле. Ответ «я люблю Мавен, он делает то, что мне надо, и я не буду учить ничего другого» свидетельствует о некотором фанатизме, и не априори.
Мне Папа Римский сказал что groovy — благодать, а gradle — мракобесие. Так что можешь верить, а можешь и не верить.
Просто наш спор не очень конструктивен, так как ты advocate евангелист gradle и это твой хлеб.
Переход на любую технологию должен происходить исходя из ее области применимости, уровня владения этой технологией командой, возможности модификации и адаптации под задачу, уровня поддержки IDE, в некоторых проектах «безобразно, но единообразно» лучше чем можно мешать императивно с декларативным «из коробки» и т.п.
Просто наш спор не очень конструктивен, так как ты advocate евангелист gradle и это твой хлеб.
Переход на любую технологию должен происходить исходя из ее области применимости, уровня владения этой технологией командой, возможности модификации и адаптации под задачу, уровня поддержки IDE, в некоторых проектах «безобразно, но единообразно» лучше чем можно мешать императивно с декларативным «из коробки» и т.п.
Я так понимаю, проблема твоего доверия к моим словам кроется в том, что ты считаешь, что я advocate евангелист gradle? Ну так эту проблему очень просто решить: я не advocate евангелист gradle, и никогда им не был.
Под вторым твоим параграфом я подпишусь полностью. Исходя из всех этих причин все проекты Спринга перешли на Грейдл. За исключением Бута, по причинам, которые я описал выше.
Под вторым твоим параграфом я подпишусь полностью. Исходя из всех этих причин все проекты Спринга перешли на Грейдл. За исключением Бута, по причинам, которые я описал выше.
>>Ну так эту проблему очень просто решить: я не advocate евангелист gradle, и никогда им не был.
Разгадка в конфликте интересов maven сentral и bintray!? Это твой хлеб?
Разгадка в конфликте интересов maven сentral и bintray!? Это твой хлеб?
Нет, Бинтрей прекрасно работает с Мавеном, а Мавен не имеет прямого отношения к Централу.
Разгадка в том, что я (да и не только я) считаю Грейдл лучшим решением.
Не надо везде искать теорий заговора и подковёрных интересов.
Разгадка в том, что я (да и не только я) считаю Грейдл лучшим решением.
Не надо везде искать теорий заговора и подковёрных интересов.
Но в maven зашит по умолчанию maven central, а не не jcenter bintray как в gradle
Игорь, тут прям thread открытий чудных. В Грейдл не зашит Бинтрей. Туда вообще ничего не зашито, разработчики выбирают лучший репозиторий, и с ним работают. Безусловно, когда появляется такая свобода выбора, большинство выбирают Бинтрей. Но это не дефолт, и нигде не прописано.
Я даже не знаю как еще это объяснить. У меня нет никаких скрытых мотивов предпочитать Грейдл Мавену. Ну вот абсолютно никаких. JFrog-у совершенно параллельны системы сборки.
Я даже не знаю как еще это объяснить. У меня нет никаких скрытых мотивов предпочитать Грейдл Мавену. Ну вот абсолютно никаких. JFrog-у совершенно параллельны системы сборки.
Да, извини, попутал: в groovy grape (groovy-2.4.4.jar!/groovy/grape/defaultGrapeConfig.xml) по умолчанию его приоритет выше других
<ibiblio name="jcenter" root="https://jcenter.bintray.com/" m2compatible="true"/>
В Гейпе — да. И каким образом наличие дефолта в Грейпе делает меня необъективным при спорах Мавен/Грейдл?
Объяснил свой промах. Конечно grape никак не связан с твоей предвзятостью к мавену
Особенно если учесть, что предвзятости не существует.
Я тебе не верю)
Ну я даже не знаю, как тебе еще доказать, что никакого интереса от продвижения Грейдла у меня нет. Ты уже предположил все возможные теории заговора между мной, Джейфрогом и Грейдлом, и я уже опроверг их все. Ещё идеи будут?
чем больше ты будешь пытаться доказать, тем сильнее будет уверенность оппонента в том, что интерес у тебя таки есть. Оно тебе надо?
Я предположил лишь лежащие на поверхности мотивы. Сложно тебе верить, когда называешь фанатом того, у кого другие предпочтения по билд системе. Но при этом занимаешь должность java advocate в компании заинтересованной в gradle/groovy и их комьюнити
>>все проекты Спринга перешли на Грейдл
Вполне может быть политическим решением
Вполне может быть политическим решением
В чем смысл минусовать, ведь вопрос по существу. Как можно построить конструктивный диалог если меньшинство не будет выражать свое мнение из за опасения быть заминусовоным?
Не очень понятно зачем слезать с мавена. Мавен отличный инструмент, прекрасно справляющийся со своими задачами. И не говорите про развесистость xml. Много вермишели можно и на груви и на скале написать.
если у тебя многомодульный разнопрофильный проект, то удобнее тот же gradle будет в последующем.
но если у тебя простой одномодульный проект, то Maven за глаза.
а встречается и такое: в Hybris используется сразу ant + gradle + maven (в его формате описаны зависимости).
но если у тебя простой одномодульный проект, то Maven за глаза.
а встречается и такое: в Hybris используется сразу ant + gradle + maven (в его формате описаны зависимости).
Cobol, vbscript, etc тоже отличные инструменты, они прекрасно справляются со своими задачами зачем с них слазить.
Вопрос, скажите а как мувен способен уберечь вас от jar-hell когда у вас есть две зависимости A и B которые ссылаются на зависимость C, правда на разные версии. Но вот беда C между эти двумя версиями сменила тоже название артифрукта. Результат плачевен, мувен не справляется со своей прямой задачей, да и никогда с ней не справлялся.
Он устарел морально и физически, в нем еще куча неудобностей, таких как иерархия проектов или централизация.
Вопрос, скажите а как мувен способен уберечь вас от jar-hell когда у вас есть две зависимости A и B которые ссылаются на зависимость C, правда на разные версии. Но вот беда C между эти двумя версиями сменила тоже название артифрукта. Результат плачевен, мувен не справляется со своей прямой задачей, да и никогда с ней не справлялся.
Он устарел морально и физически, в нем еще куча неудобностей, таких как иерархия проектов или централизация.
Повторюсь как когда-то дискутировал здесь с jbaruch, что разные версии зависимости «C» — это беда платформы jvm, а не мавена конкретно. А эксклуды — просто костыль. jigsaw в jdk9 решит эту проблему, как и OSGI решает ее сегодня
Если бы мавен не справлялся со своей задачей, то не просуществовал до сих пор с таким количеством проектов на нем. В нем есть сильные и слабые стороны, как в любой технологии
Если бы мавен не справлялся со своей задачей, то не просуществовал до сих пор с таким количеством проектов на нем. В нем есть сильные и слабые стороны, как в любой технологии
На мой взгляд он просуществовал столько лет из за отсутствия конкурентов. В нем были допущены ошибки на концептуальном уровне, и данные ошибки плавают от версии к версии, что в конце концов и парализовало развитие проекта на долгие годы. Мало того что ван Зил не хотел обращать внимание на свои упущения так он еще дальше увязал в них и тянул за собой пользователей мувена. Один из ярких примеров при переходе с 2 на 3 версию, а давай ка братец вместо того что бы скачивать половину интернета будем, внимание, скачивать ее параллельно, ведь так быстрее.
Если вы правы, то он должен уже исченуть. Ведь Ivy и Gradle уже существуют
уважаемый vba, вам есть что ответить по существу?
Да конечно. Дальше можно углубляться в размышления что если бы… Да оппоненты у мувена сейчас есть. Ведь не реально уговорить какой нибудь сбербанк потратить кучу денег на просто переход с мувена на gradle только по прихоти программистов. А вот обновится с одной версии на другую это проходит не так болезненно.
Ведь cobol или coldfusion живее всех живых, и до сих пор можно видеть анонсы о поиске специалистов, кстати с очень достойной оплатой. Для исчезновения или перерождения мувена понадобится несколько десятилетий.
Ведь cobol или coldfusion живее всех живых, и до сих пор можно видеть анонсы о поиске специалистов, кстати с очень достойной оплатой. Для исчезновения или перерождения мувена понадобится несколько десятилетий.
За редкую легасятину всегда хорошо платят. Тут вопрос только в том, что Maven3 — это не легаси)
Потратив кучу денег на переход, надо быть еще уверенным, что это не сломает что-либо, что весь инструментарий и IDE поддерживает не только редактирование билд скриптов, но и рефакторинг и т.п., что технология завтра не зачахнет
Время покажет, если через десятилетия будет эта платформа
Потратив кучу денег на переход, надо быть еще уверенным, что это не сломает что-либо, что весь инструментарий и IDE поддерживает не только редактирование билд скриптов, но и рефакторинг и т.п., что технология завтра не зачахнет
Время покажет, если через десятилетия будет эта платформа
Простите, не напомните в каком году выпустили не-легаси версию Maven3, в 2008 или в 2009?
Да разве это легаси? maven aether — ядерный компонент maven3 так вообще state of the art для разрешения зависимостей.
Тот же Grape из последнего groovy использует более легасятный ivy provider. Комманда spring boot с трудом вкрутила в groovy aether провайдер для grape
Тот же Grape из последнего groovy использует более легасятный ivy provider. Комманда spring boot с трудом вкрутила в groovy aether провайдер для grape
Кстати по мне так определение legacy тут не особо уместно, ибо у него немного другое значение. Я больше тяготею к термину устаревший.
Мне кажется что мувен третей версии устарел. Я так понимаю что вам так не кажется, тогда следуя вашей логике можно сказать что ivy не устарел.
Часто бывало что команда spring не блистала дальновидностью.
Мне кажется что мувен третей версии устарел. Я так понимаю что вам так не кажется, тогда следуя вашей логике можно сказать что ivy не устарел.
Часто бывало что команда spring не блистала дальновидностью.
Укажите пожалуйста, где именно из моей логики следует что ivy не устарел
>Часто бывало что команда spring не блистала дальновидностью.
Это ваше личное мнение? Можно примеры!?
>Часто бывало что команда spring не блистала дальновидностью.
Это ваше личное мнение? Можно примеры!?
Ну как же, возраст не показатель, отсутствие пульса не показатель да и концептуальные упущения путешествующие из n-1 в n не показатель тогда ivy не устарел. Что тогда для вас считается основанием полагать устарел он или нет?
Про spring source, особо не буду говорить ибо оффтоп и времени на это нет, вам так разве не кажется?
Про spring source, особо не буду говорить ибо оффтоп и времени на это нет, вам так разве не кажется?
>Про spring source, особо не буду говорить ибо оффтоп и времени на это нет, вам так разве не кажется?
Вы использовали это как аргумент в споре и при резонном вопросе сразу же закрыли обсуждение.
>>Что тогда для вас считается основанием полагать устарел он или нет?
Мнения людей, столкнувшихся с ограничениями в разрешении зависимостей из-за ivy в groovy Grape, которые невозможно обойти при использовании ivy.
Я считаю что Grape — очень ценный для многих применений в groovy скриптах, но ivy тормозит его повсеместное применение
Вы использовали это как аргумент в споре и при резонном вопросе сразу же закрыли обсуждение.
>>Что тогда для вас считается основанием полагать устарел он или нет?
Мнения людей, столкнувшихся с ограничениями в разрешении зависимостей из-за ivy в groovy Grape, которые невозможно обойти при использовании ivy.
Я считаю что Grape — очень ценный для многих применений в groovy скриптах, но ivy тормозит его повсеместное применение
Насчет проблем jvm я частично не соглашусь, ведь есть же плагины-костыли для мувена которые проверяют classpath на «дубликаты».
Расскажите пожалуйста, что вы имели в виду под централизацией
Имеется в виду использование различных репозиториев, чем их больше тем время скачивания увеличивается. Костыль для этого сводился к установке одного центрального, буфер репозитория. Я сейчас не помню что за фирма сопровождала данный проект.
Да полно решений про зеркалирование sonatype, artifactory. Никто не мешает в проекте указывать свой список repository!?)
jcenter не гнушаются использовать в gradle, хотя по сути это тоже центральный репозитарий
jcenter не гнушаются использовать в gradle, хотя по сути это тоже центральный репозитарий
Мне кажется, решение это когда производитель (в данном случае мувен) гарантирует вам что данное решение им поддерживается и все будет работать как следует при переходе от версии к версии. Иначе это workaround, по моему.
А разве repositories>repository не работает между версиями?
mirrorOf тоже вроде работает как прокси для внешних репозитариев в изолированной сети, если его использовать по назначению
mirrorOf тоже вроде работает как прокси для внешних репозитариев в изолированной сети, если его использовать по назначению
Я не знаю, я бы не стал полагаться просто на авось в данной ситуации. Обычно мажорные релизы на то и мажорные что не соблюдают обратной совместимости, и могут все поломать включая repositories>repository и mirrorOf итд.
mirrorOf плох тем, что де-факто запрещает использовать больше чем один репозиторий, даже когда они все приходят из правильного места. Это гильотина от головной боли.
Это какая-то полная ерунда. Это все равно, что сказать, что от Оракла теперь требуется гарантия поддержки всех Джава библиотек в мире, и что они будут работать как следует при переходе к следущей версии.
Почему один из инструментов экосистемы (Мавен) должен гарантировать поддержку другого (бинарного репозитория)?!
Почему один из инструментов экосистемы (Мавен) должен гарантировать поддержку другого (бинарного репозитория)?!
>>Почему один из инструментов экосистемы (Мавен) должен гарантировать поддержку другого (бинарного репозитория)?!
Потому что в противном случае случается то, что было в ant — когда все зависимости качались wget и добавлялись в scm проекта
Потому что в противном случае случается то, что было в ant — когда все зависимости качались wget и добавлялись в scm проекта
Я не спорю, что они должны работать по стандарту. Я спорю, что они обязательно должны приходить из одного источника и гарантировать поддержку. Потому что это обязательно означает, что универсального репозитория создать невозжно, ибо Мавеноский репозиторий можно получить только от Мавена, Нугетовский только от Микрософота, Рубийский только от х.з. кого, и так далее.
>>Я спорю, что они обязательно должны приходить из одного источника и гарантировать поддержку
А зачем тогда jfrog пытается подсадить всех на bintray!? Не поверю в этом контексте в альтруизм, тут уже шкурный интерес прослеживается
А зачем тогда jfrog пытается подсадить всех на bintray!? Не поверю в этом контексте в альтруизм, тут уже шкурный интерес прослеживается
Мы никого не пытаемся пересадить. Мы предлагаем продукт, который объективно лучше, чем конкуренция. Кто хочет — пересаживается, кто хочет — нет.
Никакого альтруизма нет, и шкурный интерес, конечно есть. Только не тот, который ты думаешь. Всё девелоперы опенсорца, которые публикуют бесплатно пакеты в Бинтрей — не последние люди в компаниях, которые будут за большие деньги строить свой download center на Бинтрее благодаря рекомендации тех самых девелоперов опенсорца.
Это простая, честная и банальная модель, которую никто не скрывает.
Никакого альтруизма нет, и шкурный интерес, конечно есть. Только не тот, который ты думаешь. Всё девелоперы опенсорца, которые публикуют бесплатно пакеты в Бинтрей — не последние люди в компаниях, которые будут за большие деньги строить свой download center на Бинтрее благодаря рекомендации тех самых девелоперов опенсорца.
Это простая, честная и банальная модель, которую никто не скрывает.
Gradle такой же продукт, со своими преимуществами и слабыми сторонами. Не надо идеализировать технологию.
Но модель работы Бинтрей понятна. Тут каждый волен выбирать. В любом случае спасибо за честный ответ!!!
Но модель работы Бинтрей понятна. Тут каждый волен выбирать. В любом случае спасибо за честный ответ!!!
Никто не идеализирует технологию. У Грейдла хватает недостатков. Он просто лучше, чем конкретно Мавен в большинстве случаев.
На счет «каждый волен выбирать» не понял, это про что?
На счет «каждый волен выбирать» не понял, это про что?
>>Никто не идеализирует технологию. У Грейдла хватает недостатков. Он просто лучше, чем конкретно Мавен в большинстве случаев.
Тут опять же кому как удобнее. Тем более что затраты времени на написание и поддержание билдскрипта должны быть минимальны. Сложно будет объяснить бизнесу что это вместо работы команда(которая мало знакома с gradle) билд скрипт пишет днями
Тут опять же кому как удобнее. Тем более что затраты времени на написание и поддержание билдскрипта должны быть минимальны. Сложно будет объяснить бизнесу что это вместо работы команда(которая мало знакома с gradle) билд скрипт пишет днями
Опять двадцатьпять. Когда в скрипте нет тасков, то он короток, лаконичен, и требует меньшей поддержки, чем мавеновские хмл-ные простыни.
Ну это все слова… Повторюсь что бизнесу все равно насколько лаконичен билд. Им главное чтобы ПО работало и приносило прибыль. И если команда будет ковырять gradle изо дня в день, всех уволят!
>>На счет «каждый волен выбирать» не понял, это про что?
Волен выбирать готовый бинтрей или самому поддерживать подобную инфраструктуру
Волен выбирать готовый бинтрей или самому поддерживать подобную инфраструктуру
Единственный костыль в использовании организационного прокси это то, что в Мавене разрешено прописывать источники зависимостей в метадате пакета. Всё остальное в этом подходе ни костыль ни разу.
как мувен способен уберечь вас от jar-hell когда у вас есть две зависимости A и B которые ссылаются на зависимость C, правда на разные версии. Но вот беда C между эти двумя версиями сменила тоже название артифрукта
Мы для этого используем maven-duplicate-finder-plugin
Все таки gradle vs maven не совсем корректно сравнивать. Так как maven — это декларативный подход к сборке проекта, хоть и со многими ограничениями.
И maven эволюционирует с тем же Polyglot, для тех кому хочется намешать императивных комманд с декларативными в процесс сборки или писать его конфигурацию на том языке, который ему нравится, вместо xml
И maven эволюционирует с тем же Polyglot, для тех кому хочется намешать императивных комманд с декларативными в процесс сборки или писать его конфигурацию на том языке, который ему нравится, вместо xml
Так же как и не стоит сравнивать sbt/maven, ivy/maven или maven2/maven3, зависит в каком контексте идет сравнение.
Вы искажаете факты. Например maven2/3 почти одно и то же для конечного пользователя.
Повторюсь еще раз сравнивать что лучше можно лишь в одной категории. Вряд ли кто будет всерьез сравнивать карьерный самосвал и легковой автомобиль или подводную лодку с самолетом
Повторюсь еще раз сравнивать что лучше можно лишь в одной категории. Вряд ли кто будет всерьез сравнивать карьерный самосвал и легковой автомобиль или подводную лодку с самолетом
Нет вы не правы, читайте внимательнее. Все вышеуказанное в той или иной мере одно и тоже для конечного пользователя. Я право не совсем понял что вы хотели сказать этим: «Повторюсь еще раз сравнивать что лучше можно лишь в одной категории».
Да и если мы уже перешли на личностное, то я, увы, вынужден покинуть данный топик. Я думаю я свою точку зрения высказал, вы свою тоже. Тема исчерпана. Всего хорошего.
Да и если мы уже перешли на личностное, то я, увы, вынужден покинуть данный топик. Я думаю я свою точку зрения высказал, вы свою тоже. Тема исчерпана. Всего хорошего.
Грейдл, если что, ни разу не менее декларативный чем Мавен.
То что народ повсеместно в билдах мешает груви код и gradle dsl это декларативно?
«Декларативная сборка подразумевает написание программистом функционального и логического алгоритма для исполнения» (источник)
что в Maven, что в Gradle это именно так. Только в Maven это через конфигурацию в xml файле, а в Gradle через Groovy-код в сборочном скрипте.
что в Maven, что в Gradle это именно так. Только в Maven это через конфигурацию в xml файле, а в Gradle через Groovy-код в сборочном скрипте.
Не совсем так, так как смесь груви кода и конфигурации это нечто иное чем декларативное описание сборки. В случае maven — то что если тебе нужно написать часть билда в императивном стиле, то приходится писать свой плагин для этого. И конфигурация остается декларативной
В Gradle как раз применяется подход «программирование в ограничениях». разве нет?
Можно пример? В конфигурацию билда gradle можно вставлять произвольный groovy код и gradle не анализирует AST программы. Так что не вижу противоречий со своим прошлым высказыванием.
github.com/crate/crate/blob/master/build.gradle
содержит
Разве это декларативный подход?
содержит
@Override
void afterTest(TestDescriptor test, TestResult result) {
if (result.getResultType() == TestResult.ResultType.FAILURE) {
logger.error('## FAILURE: ' + test)
testOutputs[test].each { e ->
print e
}
}
testOutputs.remove(test)
}
Разве это декларативный подход?
Нет, и тому кто это писал надо руки оторвать. Как, например и тому, кто писал вот эти 35247 помов.
Это да, тонко подмечено!) Только в maven — это выглядет извращением, а в gradle — фича.
В любом случае я согласен, что многое зависит от умения правильно готовить билд
В любом случае я согласен, что многое зависит от умения правильно готовить билд
Нифига это не фича. Грейдл говорит прямым текстом, фунционал тасков надо писать в плагинах, а не фигачить в скрипт. Ровно как в Мавене.
Если что-то не запрещается и ограничивается на уровне системы, это очень часто используется «начинающими пользователями»
Ой, да ладно, народ учится прикручивать антран чуть ли не сразу после того, как выясняется, что кроме дефолтного лайфсайкла нужно еще что либо. Траектория именно такая:
— ой как няшно всё работает из коробки
— ой, а вот тут мне нужно кое что еще, где я пишу код, который это делает?
— то есть как нельзя? Но я же в анте так делал!
— а, ну вот, можно же антран. А дальше я знаю.
— ой как няшно всё работает из коробки
— ой, а вот тут мне нужно кое что еще, где я пишу код, который это делает?
— то есть как нельзя? Но я же в анте так делал!
— а, ну вот, можно же антран. А дальше я знаю.
Кстати, не факт что по той ссылке все что ты выслал, все относится к хачным ант скриптам.
Достаточно частый usecase — это замена шел скрипта в билде, например регэксп реплейс из анта
Достаточно частый usecase — это замена шел скрипта в билде, например регэксп реплейс из анта
Вот что мене действительно понравилось в груви — это работа с процессами из коробки «ls».execute()
Тебе еще очень много что понравится, когда ты с этим столкнешься. Ну, или, почитаешь специально.
Я сейчас как раз в groovy по локти.
Получается ты согласен, что не все вызовы ант плагинов по той ссылке относятся к императивному куску билда?
Получается ты согласен, что не все вызовы ант плагинов по той ссылке относятся к императивному куску билда?
Конечно не все. На вскидку, процентов 90.
Вдруг только 10%!? Никто не считал же
Ой, да ладно. Мы все прекрасно знаем для чего в большинстве проектов добавляется антран.
Я всегда за такое по рукам бил) Как и за комиты jar в scm
Так что у нас с тобой разный опыт применения antrun plugin
Так что у нас с тобой разный опыт применения antrun plugin
Запуск шелл-скрипта?
А зачем тогда в грейдл добавили апи анта? Зачем писать плагин ради одного билда? Зачем вообще груви, если билд скрипт это просто конфигурация?
Прекрасные, прекрасные вопросы.
— А зачем тогда в грейдл добавили апи анта?
Это не дрейдл добавил. Объект анта существует в Груви. И в грейдле он нужен для того, чтобы дёргать таски анта из старого билда во время постепенного перехода на Грейдл.
— Зачем писать плагин ради одного билда?
Это какой-то странный вопрос. Зачем писать таски ради одного билда? Зачем писать билд ради одного билда? Наверное ты имел ввиду «зачем выносить логику в отдельные классы, заворачивать их в джар, публиковать джар и потом дергать его из билда, если на самом деле реюза никакого не предвидится?» На этот вопрос я могу ответить: Плагины в Грейде, в отличие от Мавена, не обязательно должны быть отдельнособранными джарами. Это могут быть классы в специальной директории в проекте, или даже другие скрипты, в которых будут прописаны таски.
— Зачем вообще груви, если билд скрипт это просто конфигурация?
Не знаю. А где ты увидел Груви? Билд скрипты на Грейдле это не Груви, а Грейдл DSL, а вот он уже потому что он намного удобней, чем XML.
— А зачем тогда в грейдл добавили апи анта?
Это не дрейдл добавил. Объект анта существует в Груви. И в грейдле он нужен для того, чтобы дёргать таски анта из старого билда во время постепенного перехода на Грейдл.
— Зачем писать плагин ради одного билда?
Это какой-то странный вопрос. Зачем писать таски ради одного билда? Зачем писать билд ради одного билда? Наверное ты имел ввиду «зачем выносить логику в отдельные классы, заворачивать их в джар, публиковать джар и потом дергать его из билда, если на самом деле реюза никакого не предвидится?» На этот вопрос я могу ответить: Плагины в Грейде, в отличие от Мавена, не обязательно должны быть отдельнособранными джарами. Это могут быть классы в специальной директории в проекте, или даже другие скрипты, в которых будут прописаны таски.
— Зачем вообще груви, если билд скрипт это просто конфигурация?
Не знаю. А где ты увидел Груви? Билд скрипты на Грейдле это не Груви, а Грейдл DSL, а вот он уже потому что он намного удобней, чем XML.
Билд ради билда — это чистое передергивание, какая есть реальная нужда писать плагины ради одного билда? Сам грейдл как раз пишет, что плагины нужны для реюза.
Если писать весь функционал в плагинах, то грейдл скрипт превратится в конфигурацию для плагинов, так он сейчас и выглядит в андроид студии, залезть подправить циферки или вписать новую зависимость. И мягко говоря не летает.
Грейдл DSL все равно ведь расширение груви, разве не так? Поддержка редактирования в ИДЕ сильно хромает. Таким образом, для конечного пользователя разницы нет никакой, в каком файле что править.
Если писать весь функционал в плагинах, то грейдл скрипт превратится в конфигурацию для плагинов, так он сейчас и выглядит в андроид студии, залезть подправить циферки или вписать новую зависимость. И мягко говоря не летает.
Грейдл DSL все равно ведь расширение груви, разве не так? Поддержка редактирования в ИДЕ сильно хромает. Таким образом, для конечного пользователя разницы нет никакой, в каком файле что править.
я же объяснил, плагины могут быть просто отдельными скриптами, в которые пользователи не лезут своими шаловливыми ручками
Именно так, это и есть декларативный билд. Я не знаю, с чего ты взял, что он не летает, когда летает еще как.
Ну и что, что расширение Груви? Для пользователей, которые не знают Груви, это совершенно отдельный язык для описания билда. И им совершенно все равно, реализован он на Груви, на Джаваскрипте, или на Ассемблере. Для них это прозрачная деталь реализации. А разница для конечного пользователя есть только в том, насколько DSL хорош — удобен, гибок, понятен, и так далее. Так получилось, что на Груви писать DSL-ы удобно и просто, вот и всё.
А вот те, кто пишут плагины наслаждаются всеми плюшками Груви, если хотят, или сурово кодят на Джаве, если не хотят.
Именно так, это и есть декларативный билд. Я не знаю, с чего ты взял, что он не летает, когда летает еще как.
Ну и что, что расширение Груви? Для пользователей, которые не знают Груви, это совершенно отдельный язык для описания билда. И им совершенно все равно, реализован он на Груви, на Джаваскрипте, или на Ассемблере. Для них это прозрачная деталь реализации. А разница для конечного пользователя есть только в том, насколько DSL хорош — удобен, гибок, понятен, и так далее. Так получилось, что на Груви писать DSL-ы удобно и просто, вот и всё.
А вот те, кто пишут плагины наслаждаются всеми плюшками Груви, если хотят, или сурово кодят на Джаве, если не хотят.
Да, факт что нормальный DSL на java не сделать. Так что логичный выбор языков groovy, scala, ruby для DSL как первый вариант или своей граматики и парсеров на основе нее как второй вариант, либо yaml/xml/json и код валидирующий/выполняющий эту конфигурацию
То, что народ повсеместно в мавеновских хмлах фигачит ант-таск-плагины и начинает писать код на хмле это тоже не ахти как декларативно.
При правильном использовании, Грейдл деклеративен не менее чем Мавен. Ну, а то, что народ молотками шурупы забивает, это увы и ах. «Технологии — идеальны, а вот люди — мудаки»(с).
При правильном использовании, Грейдл деклеративен не менее чем Мавен. Ну, а то, что народ молотками шурупы забивает, это увы и ах. «Технологии — идеальны, а вот люди — мудаки»(с).
О, боги! Это родом из maven — aether и там твоя аватарка
И главный груви фреймворк для веб grails.io/post/40093552028/road-to-grails-23-improved-dependency-resolution
И главный груви фреймворк для веб grails.io/post/40093552028/road-to-grails-23-improved-dependency-resolution
Еще один момент — в грейдле нет стандартов как в мавене. Там говорят — можно всё! И все делают как им нравится. В мавен проект приходишь — делаешь clean install и у тебя готовое приложение.
В каждом гредл проекте тебе нужно ковырять билд скрипт чтобы понять правила конкретного монастыря.
В каждом гредл проекте тебе нужно ковырять билд скрипт чтобы понять правила конкретного монастыря.
Да откуда же вы эту хуню берете-то, а?! Где в Грейдле говорят «можно всё»?! Конечно там есть стандарты. Есть и стандартный layout, и стандартный lifecycle, и стандарт artifact metadata.
И нет, большинство Грейдл проектов одинаковы, и все очень похожи.
И нет, большинство Грейдл проектов одинаковы, и все очень похожи.
Что значит откуда? Приходишь в 90% опенсорсных проектов и там получаешь квест аля ант. Как ближайший пример — почти все дженкинс плагины, которые собираются гредлом. То что там есть стандарты о которых никто не знает, потому что они слаборекомендательные — это значит именно «можно все».
То, что в каких-то проектах у вас квест, не значит, что в Грейдле говорят, что «можно всё». И о том, что там есть стандарты, знает любой, кто знает что-либо о Грейдле. С этого начинаются доки, с этого начинаются тренинги и презентации.
Это идеальный мир) Если тул разрешает многое, на многих проектах начинается анархия
Возможно, что лучше был бы даже плагин для ИДЕ, который подсвечивал бы зависимости, для которых есть более новые версии. Похожим образом сделано для грейдла в андроид студии. Менять все версии за раз черевато сайдэффектами, лучше осознанно обновлять и тестировать по одному.
Меня давно мучает вопрос почему создатели грейдла выбрали груви, а не, скажем, яваскрипт? Можно было сделать АПИ для билдов прямо на яве, тогда можно было бы описать весь билд на том же языке и предельно четко, да, его пришлось бы компилировать, но это можно автоматизировать.
Меня давно мучает вопрос почему создатели грейдла выбрали груви, а не, скажем, яваскрипт? Можно было сделать АПИ для билдов прямо на яве, тогда можно было бы описать весь билд на том же языке и предельно четко, да, его пришлось бы компилировать, но это можно автоматизировать.
Вы Java и Javascript не путайте — разные совсем языки.
Я их и не путал, в первом случае яваскрипт, во втором ява.
Тогда поясните пожалуйста данный кусок текста:
«Меня давно мучает вопрос почему создатели грейдла выбрали груви, а не, скажем, яваскрипт? Можно было сделать АПИ для билдов прямо на яве, тогда можно было бы описать весь билд на том же языке и предельно четко, да, его пришлось бы компилировать, но это можно автоматизировать. „
«Меня давно мучает вопрос почему создатели грейдла выбрали груви, а не, скажем, яваскрипт? Можно было сделать АПИ для билдов прямо на яве, тогда можно было бы описать весь билд на том же языке и предельно четко, да, его пришлось бы компилировать, но это можно автоматизировать. „
1. Вместо груви использовать яваскрипт, он тоже динамический и более распространенный.
2. Почему бы не сделать билдсистему на яве(Java)? Максимальная гибкость, разработчики знают идеально, работает быстро, статическая типизация.
2. Почему бы не сделать билдсистему на яве(Java)? Максимальная гибкость, разработчики знают идеально, работает быстро, статическая типизация.
В таком виде — действительно не возникает ощущения что вы приравниваете эти языки друг к другу… Вам следовало сразу абзац разбить на два, либо иным способом более чётко провести границу между совершенно разными предложениями.
1. Потому что он не похож на Джаву (см. собвственный второй коммент).
2. Поотму что Джава ужасный инструмент для построения DSL (намного хуже, чем Груви), и ужасный инструмент для описания метадаты (намного хуже, чем ХМЛ). Но на вопрос «почему бы не сделать» ответ «сделали и не одну». Гугль тебе в помощь.
2. Поотму что Джава ужасный инструмент для построения DSL (намного хуже, чем Груви), и ужасный инструмент для описания метадаты (намного хуже, чем ХМЛ). Но на вопрос «почему бы не сделать» ответ «сделали и не одну». Гугль тебе в помощь.
Не похож на яву — ну и что? Он все равно куда более известный, чем груви, плюс есть jvm имплементация.
Хуже или лучше — это твои личные эмоции. К примеру, в ИДЕ поддержка грейдл ДСЛ на нуле, даже хуже чем XML, андроид студия не в состоянии подсветить банальную ошибку в скрипте без его запуска, нет никакого хелпа или автокомплита.
Ты похоже не понял, я спрашивал, почему бы сам билд не описать на яве, а не только сам тул.
Хуже или лучше — это твои личные эмоции. К примеру, в ИДЕ поддержка грейдл ДСЛ на нуле, даже хуже чем XML, андроид студия не в состоянии подсветить банальную ошибку в скрипте без его запуска, нет никакого хелпа или автокомплита.
Ты похоже не понял, я спрашивал, почему бы сам билд не описать на яве, а не только сам тул.
То есть как «ну и что»? Ну и то, что 9 миллионов девелоперов (или сколько там нынче) будут чувствовать себя намного лучше в знакомом синтаксисе, чем в незнакомом.
Хуже или лучше это факты, и к эмоциям отношения не имеет. Если в языке нет поддержки скриптов, создания ассивов и мапов на лету, алиасинга классов, и везде нужны точки с запятыми, этот язык не подходит для DSL. Извините.
К поддержке ИДЕ это не имеет никакого отношения. Точнее имеет, но обратное от того, что ты пытаешься доказать. То, что ИДЕЯ по умолчанию не понимает, что это за синтаксис такой означает, что ДСЛ хороший, а не плохой.
И билд не описать на Джаве, потому что билд описывается ДСЛ-ом, а Джава плохой язык для создания ДСЛ-ов.
Хуже или лучше это факты, и к эмоциям отношения не имеет. Если в языке нет поддержки скриптов, создания ассивов и мапов на лету, алиасинга классов, и везде нужны точки с запятыми, этот язык не подходит для DSL. Извините.
К поддержке ИДЕ это не имеет никакого отношения. Точнее имеет, но обратное от того, что ты пытаешься доказать. То, что ИДЕЯ по умолчанию не понимает, что это за синтаксис такой означает, что ДСЛ хороший, а не плохой.
И билд не описать на Джаве, потому что билд описывается ДСЛ-ом, а Джава плохой язык для создания ДСЛ-ов.
UFO just landed and posted this here
Sign up to leave a comment.
Управление версиями зависимостей в Maven проекте