Управление версиями зависимостей можно разделить на три части:
- версия родительского проекта (если имеется);
- версия зависимостей;
- версия используемых расширений Maven.
Самая простая задача — это обновление версии родительского проекта. Достаточно в корне вашего проекта запустить команду:
mvn versions:update-parent
Для того, чтобы иметь возможность обновлять версии остальных зависимостей, их версии необходимо в явном виде описать как переменные в разделе properties проекта Maven. Зависимости, версии которых описаны без ссылки на переменную, обновить таким образом не получится.
Это же относится и к версиям всех используемых вами расширений. Таким образом, нужно явно прописать в проекте все используемые расширения с вынесением их версий в переменные, после чего их версии тоже начнут обновляться.
В результате, все наши зависимости и расширения будут выглядеть таким образом:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://maven.apache.org/POM/4.0.0"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<properties>
<spring.version>4.2.0.RELEASE</spring.version>
<maven-clean.version>2.6.1</maven-clean.version>
</properties>
<dependencies>
<!-- Spring Framework -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>${spring.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clean-plugin</artifactId>
<executions>
<execution>
<id>auto-clean</id>
<phase>initialize</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clean-plugin</artifactId>
<version>${maven-clean.version}</version>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
Чтобы разобраться с тем, какие ещё расширения мы не указали явным образом, нам нужно воспользоваться командой:
mvn versions:display-plugin-updates
по результатам работы которой можно узнать, какие ещё расширения не прописаны в вашем проекте и версиями которых вы не управляете. Так же будет указано, какую минимальную версию Maven необходимо указать в вашем проекте для корректной работы всех расширений.
Важно отметить, что зависимости, которые включаются в ваш проект через родительский проект, не будут обновлять версии пока вы их явно не включите в список зависимостей своего проекта, перенеся из родительского. Это может быть полезно, если в своём проекте вы хотите иметь отличный набор версий чем предоставляет готовый родительский проект.
После выполнения всех описанных выше операций мы можем непосредственно обновить все версии описанные нами как переменные, запустив команду:
mvn versions:update-properties
Далее вы можете просмотреть список внесённых расширением правок в Maven проект и принять решение об их целесообразности.
Просматривая список предложенных новых версий, вы очень быстро обнаружите, что там начинаются появляться не финальные версии зависимостей, которые скорее всего вам не нужны. Для описания, какие версии при обновлении вы бы хотели пропускать, служит специальный файл, где можно описать исключения в виде конкретных версий или regex выражений для конкретных зависимостей или их групп.
Создадим файл maven-version-rules.xml в корне проекта с таким содержимым:
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
comparisonMethod="maven"
xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 http://www.mojohaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
<rules>
<rule groupId="org.hibernate">
<ignoreVersions>
<ignoreVersion type="regex">.*Alpha.*</ignoreVersion>
<ignoreVersion type="regex">.*Beta.*</ignoreVersion>
<ignoreVersion type="regex">.*[.]CR.*</ignoreVersion>
</ignoreVersions>
</rule>
</rules>
</ruleset>
И подключим его:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<configuration>
<generateBackupPoms>false</generateBackupPoms>
<rulesUri>file://${project.basedir}/maven-version-rules.xml</rulesUri>
</configuration>
</plugin>
В результате, вы можете захотеть создать такой файл update.bat (как вариант, update.sh) для обновления версий в будущем:
call mvn versions:update-parent versions:update-properties
или только:
call mvn versions:update-properties
Нужно отметить, что такие проекты как Spring IO platform и Spring Boot в своих родительских проектах уже предоставляют актуальные и протестированные на совместимость версии очень большого количества библиотек, что позволяет использовать их в своих проектах без указание конкретной версии.
Все исходники доступны на GitHub.
Комментарии (137)
Lanwen
11.08.2015 12:30+5Не очень понятно зачем слезать с мавена. Мавен отличный инструмент, прекрасно справляющийся со своими задачами. И не говорите про развесистость xml. Много вермишели можно и на груви и на скале написать.
Borz
11.08.2015 12:39+1если у тебя многомодульный разнопрофильный проект, то удобнее тот же gradle будет в последующем.
но если у тебя простой одномодульный проект, то Maven за глаза.
а встречается и такое: в Hybris используется сразу ant + gradle + maven (в его формате описаны зависимости).
vba
11.08.2015 12:40-1Cobol, vbscript, etc тоже отличные инструменты, они прекрасно справляются со своими задачами зачем с них слазить.
Вопрос, скажите а как мувен способен уберечь вас от jar-hell когда у вас есть две зависимости A и B которые ссылаются на зависимость C, правда на разные версии. Но вот беда C между эти двумя версиями сменила тоже название артифрукта. Результат плачевен, мувен не справляется со своей прямой задачей, да и никогда с ней не справлялся.
Он устарел морально и физически, в нем еще куча неудобностей, таких как иерархия проектов или централизация.
igor_suhorukov
11.08.2015 13:08+1Повторюсь как когда-то дискутировал здесь с jbaruch, что разные версии зависимости «C» — это беда платформы jvm, а не мавена конкретно. А эксклуды — просто костыль. jigsaw в jdk9 решит эту проблему, как и OSGI решает ее сегодня
Если бы мавен не справлялся со своей задачей, то не просуществовал до сих пор с таким количеством проектов на нем. В нем есть сильные и слабые стороны, как в любой технологииvba
11.08.2015 13:18+1На мой взгляд он просуществовал столько лет из за отсутствия конкурентов. В нем были допущены ошибки на концептуальном уровне, и данные ошибки плавают от версии к версии, что в конце концов и парализовало развитие проекта на долгие годы. Мало того что ван Зил не хотел обращать внимание на свои упущения так он еще дальше увязал в них и тянул за собой пользователей мувена. Один из ярких примеров при переходе с 2 на 3 версию, а давай ка братец вместо того что бы скачивать половину интернета будем, внимание, скачивать ее параллельно, ведь так быстрее.
igor_suhorukov
11.08.2015 13:22Если вы правы, то он должен уже исченуть. Ведь Ivy и Gradle уже существуют
igor_suhorukov
11.08.2015 13:37уважаемый vba, вам есть что ответить по существу?
vba
11.08.2015 13:57-1Да конечно. Дальше можно углубляться в размышления что если бы… Да оппоненты у мувена сейчас есть. Ведь не реально уговорить какой нибудь сбербанк потратить кучу денег на просто переход с мувена на gradle только по прихоти программистов. А вот обновится с одной версии на другую это проходит не так болезненно.
Ведь cobol или coldfusion живее всех живых, и до сих пор можно видеть анонсы о поиске специалистов, кстати с очень достойной оплатой. Для исчезновения или перерождения мувена понадобится несколько десятилетий.igor_suhorukov
11.08.2015 14:05За редкую легасятину всегда хорошо платят. Тут вопрос только в том, что Maven3 — это не легаси)
Потратив кучу денег на переход, надо быть еще уверенным, что это не сломает что-либо, что весь инструментарий и IDE поддерживает не только редактирование билд скриптов, но и рефакторинг и т.п., что технология завтра не зачахнет
Время покажет, если через десятилетия будет эта платформаvba
11.08.2015 14:25-1Простите, не напомните в каком году выпустили не-легаси версию Maven3, в 2008 или в 2009?
igor_suhorukov
11.08.2015 14:31Да разве это легаси? maven aether — ядерный компонент maven3 так вообще state of the art для разрешения зависимостей.
Тот же Grape из последнего groovy использует более легасятный ivy provider. Комманда spring boot с трудом вкрутила в groovy aether провайдер для grapevba
11.08.2015 14:41Кстати по мне так определение legacy тут не особо уместно, ибо у него немного другое значение. Я больше тяготею к термину устаревший.
Мне кажется что мувен третей версии устарел. Я так понимаю что вам так не кажется, тогда следуя вашей логике можно сказать что ivy не устарел.
Часто бывало что команда spring не блистала дальновидностью.igor_suhorukov
11.08.2015 14:48Укажите пожалуйста, где именно из моей логики следует что ivy не устарел
>Часто бывало что команда spring не блистала дальновидностью.
Это ваше личное мнение? Можно примеры!?vba
11.08.2015 15:00-3Ну как же, возраст не показатель, отсутствие пульса не показатель да и концептуальные упущения путешествующие из n-1 в n не показатель тогда ivy не устарел. Что тогда для вас считается основанием полагать устарел он или нет?
Про spring source, особо не буду говорить ибо оффтоп и времени на это нет, вам так разве не кажется?igor_suhorukov
11.08.2015 15:14>Про spring source, особо не буду говорить ибо оффтоп и времени на это нет, вам так разве не кажется?
Вы использовали это как аргумент в споре и при резонном вопросе сразу же закрыли обсуждение.
>>Что тогда для вас считается основанием полагать устарел он или нет?
Мнения людей, столкнувшихся с ограничениями в разрешении зависимостей из-за ivy в groovy Grape, которые невозможно обойти при использовании ivy.
Я считаю что Grape — очень ценный для многих применений в groovy скриптах, но ivy тормозит его повсеместное применение
vba
11.08.2015 13:25+1Насчет проблем jvm я частично не соглашусь, ведь есть же плагины-костыли для мувена которые проверяют classpath на «дубликаты».
igor_suhorukov
11.08.2015 13:35+1maven enforcer плагин делает это. Изначальную ущербность плоского classpath решают либо иерархическими загрузчиками классов, либо ждем jigsaw — модульность на уровне платформы jvm
igor_suhorukov
11.08.2015 13:16Расскажите пожалуйста, что вы имели в виду под централизацией
vba
11.08.2015 13:21Имеется в виду использование различных репозиториев, чем их больше тем время скачивания увеличивается. Костыль для этого сводился к установке одного центрального, буфер репозитория. Я сейчас не помню что за фирма сопровождала данный проект.
igor_suhorukov
11.08.2015 13:25Да полно решений про зеркалирование sonatype, artifactory. Никто не мешает в проекте указывать свой список repository!?)
jcenter не гнушаются использовать в gradle, хотя по сути это тоже центральный репозитарийvba
11.08.2015 14:01Мне кажется, решение это когда производитель (в данном случае мувен) гарантирует вам что данное решение им поддерживается и все будет работать как следует при переходе от версии к версии. Иначе это workaround, по моему.
igor_suhorukov
11.08.2015 14:09А разве repositories>repository не работает между версиями?
mirrorOf тоже вроде работает как прокси для внешних репозитариев в изолированной сети, если его использовать по назначениюvba
11.08.2015 14:32Я не знаю, я бы не стал полагаться просто на авось в данной ситуации. Обычно мажорные релизы на то и мажорные что не соблюдают обратной совместимости, и могут все поломать включая repositories>repository и mirrorOf итд.
igor_suhorukov
11.08.2015 14:50Из ваших слов следует что если выпускается мажорный релиз, то теряется обратная совместимость и можно даже не вникать в детали, а сразу спорить
vba
11.08.2015 15:08Нет, увы, не следует, вы опять читаете между строк, вы не обратили внимание на слово «могут»? Тема исчерпана.
igor_suhorukov
11.08.2015 15:16Вы искусно меняете тему разговора и закрываете обсуждение, когда вам это выгодно!?
jbaruch
12.08.2015 03:54mirrorOf плох тем, что де-факто запрещает использовать больше чем один репозиторий, даже когда они все приходят из правильного места. Это гильотина от головной боли.
jbaruch
12.08.2015 03:56Это какая-то полная ерунда. Это все равно, что сказать, что от Оракла теперь требуется гарантия поддержки всех Джава библиотек в мире, и что они будут работать как следует при переходе к следущей версии.
Почему один из инструментов экосистемы (Мавен) должен гарантировать поддержку другого (бинарного репозитория)?!igor_suhorukov
12.08.2015 09:53>>Почему один из инструментов экосистемы (Мавен) должен гарантировать поддержку другого (бинарного репозитория)?!
Потому что в противном случае случается то, что было в ant — когда все зависимости качались wget и добавлялись в scm проектаjbaruch
12.08.2015 20:55Я не спорю, что они должны работать по стандарту. Я спорю, что они обязательно должны приходить из одного источника и гарантировать поддержку. Потому что это обязательно означает, что универсального репозитория создать невозжно, ибо Мавеноский репозиторий можно получить только от Мавена, Нугетовский только от Микрософота, Рубийский только от х.з. кого, и так далее.
igor_suhorukov
13.08.2015 09:33>>Я спорю, что они обязательно должны приходить из одного источника и гарантировать поддержку
А зачем тогда jfrog пытается подсадить всех на bintray!? Не поверю в этом контексте в альтруизм, тут уже шкурный интерес прослеживаетсяjbaruch
13.08.2015 20:31Мы никого не пытаемся пересадить. Мы предлагаем продукт, который объективно лучше, чем конкуренция. Кто хочет — пересаживается, кто хочет — нет.
Никакого альтруизма нет, и шкурный интерес, конечно есть. Только не тот, который ты думаешь. Всё девелоперы опенсорца, которые публикуют бесплатно пакеты в Бинтрей — не последние люди в компаниях, которые будут за большие деньги строить свой download center на Бинтрее благодаря рекомендации тех самых девелоперов опенсорца.
Это простая, честная и банальная модель, которую никто не скрывает.igor_suhorukov
15.08.2015 15:53Gradle такой же продукт, со своими преимуществами и слабыми сторонами. Не надо идеализировать технологию.
Но модель работы Бинтрей понятна. Тут каждый волен выбирать. В любом случае спасибо за честный ответ!!!jbaruch
17.08.2015 23:18Никто не идеализирует технологию. У Грейдла хватает недостатков. Он просто лучше, чем конкретно Мавен в большинстве случаев.
На счет «каждый волен выбирать» не понял, это про что?igor_suhorukov
18.08.2015 00:40>>Никто не идеализирует технологию. У Грейдла хватает недостатков. Он просто лучше, чем конкретно Мавен в большинстве случаев.
Тут опять же кому как удобнее. Тем более что затраты времени на написание и поддержание билдскрипта должны быть минимальны. Сложно будет объяснить бизнесу что это вместо работы команда(которая мало знакома с gradle) билд скрипт пишет днямиjbaruch
18.08.2015 02:38Опять двадцатьпять. Когда в скрипте нет тасков, то он короток, лаконичен, и требует меньшей поддержки, чем мавеновские хмл-ные простыни.
igor_suhorukov
18.08.2015 13:32Ну это все слова… Повторюсь что бизнесу все равно насколько лаконичен билд. Им главное чтобы ПО работало и приносило прибыль. И если команда будет ковырять gradle изо дня в день, всех уволят!
jbaruch
21.08.2015 03:13И если будут ковырять Мавен, и уволят точно так-же. С чего ты взял, что Грейдл нужно ковырять больше?
Ровно наоборот, тривиальные вещи решаются в Грейдле так же легко как и в Мавене, а вот на нетривиальные, на которые в Мавене тратятся дни, в Грейдле решаются за часы.igor_suhorukov
23.08.2015 23:49Да ну, найти человека реально знающего Maven гораздо проще чем эксперта по gradle. Аргумент про часы и дни притянут за уши
igor_suhorukov
18.08.2015 00:41>>На счет «каждый волен выбирать» не понял, это про что?
Волен выбирать готовый бинтрей или самому поддерживать подобную инфраструктуруjbaruch
18.08.2015 02:40А, ну это конечно. Обычно, правда, трудоемкие аспекты, которые не являются core, педпочитают buy instead of build, но дело хозяйское, да.
jbaruch
12.08.2015 03:53Единственный костыль в использовании организационного прокси это то, что в Мавене разрешено прописывать источники зависимостей в метадате пакета. Всё остальное в этом подходе ни костыль ни разу.
relgames
11.08.2015 19:53как мувен способен уберечь вас от jar-hell когда у вас есть две зависимости A и B которые ссылаются на зависимость C, правда на разные версии. Но вот беда C между эти двумя версиями сменила тоже название артифрукта
Мы для этого используем maven-duplicate-finder-plugin
igor_suhorukov
11.08.2015 13:11Все таки gradle vs maven не совсем корректно сравнивать. Так как maven — это декларативный подход к сборке проекта, хоть и со многими ограничениями.
И maven эволюционирует с тем же Polyglot, для тех кому хочется намешать императивных комманд с декларативными в процесс сборки или писать его конфигурацию на том языке, который ему нравится, вместо xmlvba
11.08.2015 14:43Так же как и не стоит сравнивать sbt/maven, ivy/maven или maven2/maven3, зависит в каком контексте идет сравнение.
igor_suhorukov
11.08.2015 14:53+1Вы искажаете факты. Например maven2/3 почти одно и то же для конечного пользователя.
Повторюсь еще раз сравнивать что лучше можно лишь в одной категории. Вряд ли кто будет всерьез сравнивать карьерный самосвал и легковой автомобиль или подводную лодку с самолетомvba
11.08.2015 15:05-2Нет вы не правы, читайте внимательнее. Все вышеуказанное в той или иной мере одно и тоже для конечного пользователя. Я право не совсем понял что вы хотели сказать этим: «Повторюсь еще раз сравнивать что лучше можно лишь в одной категории».
Да и если мы уже перешли на личностное, то я, увы, вынужден покинуть данный топик. Я думаю я свою точку зрения высказал, вы свою тоже. Тема исчерпана. Всего хорошего.igor_suhorukov
11.08.2015 15:18Очень жаль что у вас закончились аргументы и вы решили покинуть обсуждение в разгар спора
jbaruch
12.08.2015 03:51+1Грейдл, если что, ни разу не менее декларативный чем Мавен.
igor_suhorukov
12.08.2015 09:50То что народ повсеместно в билдах мешает груви код и gradle dsl это декларативно?
Borz
12.08.2015 10:49«Декларативная сборка подразумевает написание программистом функционального и логического алгоритма для исполнения» (источник)
что в Maven, что в Gradle это именно так. Только в Maven это через конфигурацию в xml файле, а в Gradle через Groovy-код в сборочном скрипте.igor_suhorukov
12.08.2015 11:04Не совсем так, так как смесь груви кода и конфигурации это нечто иное чем декларативное описание сборки. В случае maven — то что если тебе нужно написать часть билда в императивном стиле, то приходится писать свой плагин для этого. И конфигурация остается декларативной
Borz
12.08.2015 11:36В Gradle как раз применяется подход «программирование в ограничениях». разве нет?
igor_suhorukov
12.08.2015 12:00Можно пример? В конфигурацию билда gradle можно вставлять произвольный groovy код и gradle не анализирует AST программы. Так что не вижу противоречий со своим прошлым высказыванием.
igor_suhorukov
12.08.2015 12:03github.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) }
Разве это декларативный подход?jbaruch
12.08.2015 20:49Нет, и тому кто это писал надо руки оторвать. Как, например и тому, кто писал вот эти 35247 помов.
igor_suhorukov
12.08.2015 21:08+1Это да, тонко подмечено!) Только в maven — это выглядет извращением, а в gradle — фича.
В любом случае я согласен, что многое зависит от умения правильно готовить билдjbaruch
12.08.2015 21:19+1Нифига это не фича. Грейдл говорит прямым текстом, фунционал тасков надо писать в плагинах, а не фигачить в скрипт. Ровно как в Мавене.
igor_suhorukov
12.08.2015 21:50Если что-то не запрещается и ограничивается на уровне системы, это очень часто используется «начинающими пользователями»
jbaruch
12.08.2015 22:01+1Ой, да ладно, народ учится прикручивать антран чуть ли не сразу после того, как выясняется, что кроме дефолтного лайфсайкла нужно еще что либо. Траектория именно такая:
— ой как няшно всё работает из коробки
— ой, а вот тут мне нужно кое что еще, где я пишу код, который это делает?
— то есть как нельзя? Но я же в анте так делал!
— а, ну вот, можно же антран. А дальше я знаю.igor_suhorukov
12.08.2015 23:06Кстати, не факт что по той ссылке все что ты выслал, все относится к хачным ант скриптам.
Достаточно частый usecase — это замена шел скрипта в билде, например регэксп реплейс из анта
igor_suhorukov
12.08.2015 23:08Вот что мене действительно понравилось в груви — это работа с процессами из коробки «ls».execute()
jbaruch
13.08.2015 01:00Тебе еще очень много что понравится, когда ты с этим столкнешься. Ну, или, почитаешь специально.
igor_suhorukov
13.08.2015 10:03Я сейчас как раз в groovy по локти.
Получается ты согласен, что не все вызовы ант плагинов по той ссылке относятся к императивному куску билда?jbaruch
13.08.2015 20:32Конечно не все. На вскидку, процентов 90.
igor_suhorukov
15.08.2015 15:48Вдруг только 10%!? Никто не считал же
jbaruch
17.08.2015 23:19Ой, да ладно. Мы все прекрасно знаем для чего в большинстве проектов добавляется антран.
igor_suhorukov
18.08.2015 00:44Я всегда за такое по рукам бил) Как и за комиты jar в scm
Так что у нас с тобой разный опыт применения antrun pluginjbaruch
18.08.2015 02:42Так я за таски в гредл скриптах тоже бъю по рукам. К сожалению это не значит, что так никто не делает, и это ровным счетом ничего не доказывает. Есть очевидный абьюз, и я тебе только что показал, как он широко распространен.
igor_suhorukov
18.08.2015 13:36Ты лишь показал сколько вхождений слова antrun на github, без анализа содержимого antrun и сказал что в 90% это императивные инструкции в билде основываясь на собственных предположениях и убеждениях
kemsky
13.08.2015 11:37А зачем тогда в грейдл добавили апи анта? Зачем писать плагин ради одного билда? Зачем вообще груви, если билд скрипт это просто конфигурация?
jbaruch
13.08.2015 20:38+1Прекрасные, прекрасные вопросы.
— А зачем тогда в грейдл добавили апи анта?
Это не дрейдл добавил. Объект анта существует в Груви. И в грейдле он нужен для того, чтобы дёргать таски анта из старого билда во время постепенного перехода на Грейдл.
— Зачем писать плагин ради одного билда?
Это какой-то странный вопрос. Зачем писать таски ради одного билда? Зачем писать билд ради одного билда? Наверное ты имел ввиду «зачем выносить логику в отдельные классы, заворачивать их в джар, публиковать джар и потом дергать его из билда, если на самом деле реюза никакого не предвидится?» На этот вопрос я могу ответить: Плагины в Грейде, в отличие от Мавена, не обязательно должны быть отдельнособранными джарами. Это могут быть классы в специальной директории в проекте, или даже другие скрипты, в которых будут прописаны таски.
— Зачем вообще груви, если билд скрипт это просто конфигурация?
Не знаю. А где ты увидел Груви? Билд скрипты на Грейдле это не Груви, а Грейдл DSL, а вот он уже потому что он намного удобней, чем XML.kemsky
13.08.2015 21:41Билд ради билда — это чистое передергивание, какая есть реальная нужда писать плагины ради одного билда? Сам грейдл как раз пишет, что плагины нужны для реюза.
Если писать весь функционал в плагинах, то грейдл скрипт превратится в конфигурацию для плагинов, так он сейчас и выглядит в андроид студии, залезть подправить циферки или вписать новую зависимость. И мягко говоря не летает.
Грейдл DSL все равно ведь расширение груви, разве не так? Поддержка редактирования в ИДЕ сильно хромает. Таким образом, для конечного пользователя разницы нет никакой, в каком файле что править.jbaruch
13.08.2015 22:21я же объяснил, плагины могут быть просто отдельными скриптами, в которые пользователи не лезут своими шаловливыми ручками
Именно так, это и есть декларативный билд. Я не знаю, с чего ты взял, что он не летает, когда летает еще как.
Ну и что, что расширение Груви? Для пользователей, которые не знают Груви, это совершенно отдельный язык для описания билда. И им совершенно все равно, реализован он на Груви, на Джаваскрипте, или на Ассемблере. Для них это прозрачная деталь реализации. А разница для конечного пользователя есть только в том, насколько DSL хорош — удобен, гибок, понятен, и так далее. Так получилось, что на Груви писать DSL-ы удобно и просто, вот и всё.
А вот те, кто пишут плагины наслаждаются всеми плюшками Груви, если хотят, или сурово кодят на Джаве, если не хотят.
igor_suhorukov
15.08.2015 15:56-1Да, факт что нормальный DSL на java не сделать. Так что логичный выбор языков groovy, scala, ruby для DSL как первый вариант или своей граматики и парсеров на основе нее как второй вариант, либо yaml/xml/json и код валидирующий/выполняющий эту конфигурацию
jbaruch
12.08.2015 20:26То, что народ повсеместно в мавеновских хмлах фигачит ант-таск-плагины и начинает писать код на хмле это тоже не ахти как декларативно.
При правильном использовании, Грейдл деклеративен не менее чем Мавен. Ну, а то, что народ молотками шурупы забивает, это увы и ах. «Технологии — идеальны, а вот люди — мудаки»(с).igor_suhorukov
12.08.2015 23:32О, боги! Это родом из maven — aether и там твоя аватарка
И главный груви фреймворк для веб grails.io/post/40093552028/road-to-grails-23-improved-dependency-resolutionjbaruch
13.08.2015 01:06Что лишь доказывает еще раз, что я прекрасно знаю все плюсы и минусы.
А вот Грейлз ты напрасно притащил, они с третьей версии переползли полностью на Грейдл, потому что попытки впаять Азер в Гант были ужас-ужас. Мы в Бинтрее с этим намучались не то слово как.igor_suhorukov
13.08.2015 09:38Похоже что доказывает что jfrog использует в проекте aether
Использование aether в spring boot в груви скриптах — успешно, это все же не ivy с его детскими болезнямиjbaruch
13.08.2015 20:42Нам пришлось хакать aether для нашего Maven plugin-а. Нигде больше мы его не используем.
Снял я с нас жуткий поклёп? :)
Lanwen
14.08.2015 13:52Еще один момент — в грейдле нет стандартов как в мавене. Там говорят — можно всё! И все делают как им нравится. В мавен проект приходишь — делаешь clean install и у тебя готовое приложение.
В каждом гредл проекте тебе нужно ковырять билд скрипт чтобы понять правила конкретного монастыря.jbaruch
14.08.2015 20:42+1Да откуда же вы эту хуйню берете-то, а?! Где в Грейдле говорят «можно всё»?! Конечно там есть стандарты. Есть и стандартный layout, и стандартный lifecycle, и стандарт artifact metadata.
И нет, большинство Грейдл проектов одинаковы, и все очень похожи.Lanwen
15.08.2015 16:50+1Что значит откуда? Приходишь в 90% опенсорсных проектов и там получаешь квест аля ант. Как ближайший пример — почти все дженкинс плагины, которые собираются гредлом. То что там есть стандарты о которых никто не знает, потому что они слаборекомендательные — это значит именно «можно все».
jbaruch
17.08.2015 23:13То, что в каких-то проектах у вас квест, не значит, что в Грейдле говорят, что «можно всё». И о том, что там есть стандарты, знает любой, кто знает что-либо о Грейдле. С этого начинаются доки, с этого начинаются тренинги и презентации.
igor_suhorukov
18.08.2015 00:30+1Это идеальный мир) Если тул разрешает многое, на многих проектах начинается анархия
jbaruch
18.08.2015 00:33+1Тул не «разрешает многое», а тул «позволяет многое». Для тех, кому действительно нужно то, что дефолты из коробки не дают.
Но да, любой спор о Грейдле упирается в отсутвие «build nazi plugin», который запрещает писать таски в билд скрипте проекта.
kemsky
12.08.2015 02:34-1Возможно, что лучше был бы даже плагин для ИДЕ, который подсвечивал бы зависимости, для которых есть более новые версии. Похожим образом сделано для грейдла в андроид студии. Менять все версии за раз черевато сайдэффектами, лучше осознанно обновлять и тестировать по одному.
Меня давно мучает вопрос почему создатели грейдла выбрали груви, а не, скажем, яваскрипт? Можно было сделать АПИ для билдов прямо на яве, тогда можно было бы описать весь билд на том же языке и предельно четко, да, его пришлось бы компилировать, но это можно автоматизировать.
webkumo
12.08.2015 21:43Вы Java и Javascript не путайте — разные совсем языки.
kemsky
13.08.2015 11:29Я их и не путал, в первом случае яваскрипт, во втором ява.
webkumo
13.08.2015 12:54Тогда поясните пожалуйста данный кусок текста:
«Меня давно мучает вопрос почему создатели грейдла выбрали груви, а не, скажем, яваскрипт? Можно было сделать АПИ для билдов прямо на яве, тогда можно было бы описать весь билд на том же языке и предельно четко, да, его пришлось бы компилировать, но это можно автоматизировать. „kemsky
13.08.2015 13:481. Вместо груви использовать яваскрипт, он тоже динамический и более распространенный.
2. Почему бы не сделать билдсистему на яве(Java)? Максимальная гибкость, разработчики знают идеально, работает быстро, статическая типизация.webkumo
13.08.2015 14:11В таком виде — действительно не возникает ощущения что вы приравниваете эти языки друг к другу… Вам следовало сразу абзац разбить на два, либо иным способом более чётко провести границу между совершенно разными предложениями.
jbaruch
13.08.2015 20:451. Потому что он не похож на Джаву (см. собвственный второй коммент).
2. Поотму что Джава ужасный инструмент для построения DSL (намного хуже, чем Груви), и ужасный инструмент для описания метадаты (намного хуже, чем ХМЛ). Но на вопрос «почему бы не сделать» ответ «сделали и не одну». Гугль тебе в помощь.kemsky
15.08.2015 16:09+1Не похож на яву — ну и что? Он все равно куда более известный, чем груви, плюс есть jvm имплементация.
Хуже или лучше — это твои личные эмоции. К примеру, в ИДЕ поддержка грейдл ДСЛ на нуле, даже хуже чем XML, андроид студия не в состоянии подсветить банальную ошибку в скрипте без его запуска, нет никакого хелпа или автокомплита.
Ты похоже не понял, я спрашивал, почему бы сам билд не описать на яве, а не только сам тул.jbaruch
17.08.2015 23:24-1То есть как «ну и что»? Ну и то, что 9 миллионов девелоперов (или сколько там нынче) будут чувствовать себя намного лучше в знакомом синтаксисе, чем в незнакомом.
Хуже или лучше это факты, и к эмоциям отношения не имеет. Если в языке нет поддержки скриптов, создания ассивов и мапов на лету, алиасинга классов, и везде нужны точки с запятыми, этот язык не подходит для DSL. Извините.
К поддержке ИДЕ это не имеет никакого отношения. Точнее имеет, но обратное от того, что ты пытаешься доказать. То, что ИДЕЯ по умолчанию не понимает, что это за синтаксис такой означает, что ДСЛ хороший, а не плохой.
И билд не описать на Джаве, потому что билд описывается ДСЛ-ом, а Джава плохой язык для создания ДСЛ-ов.
guai
12.08.2015 12:16Согласен с первым каментом. Мавен — это кладовка черных ящиков, единственный способ делать с которыми что-то полезное, — google-driven-development
vba
Скажите, вам не кажется что тема мувена неактуальна? Даже для ван Зил избегает своего детища.
Borz
тот же Spring Boot его использует и по сей день
vba
Ну а как же, его много кто использует, только вот слезть с него не так то просто, история с коболом повторяется. Если вы в здравом уме и у вас есть выбор для нового проекта между gradle/sbt и maven, вы скорее всего выберете что то из первых двух(даже если они совместимы с репозиториями мувена), ван Зил наверное тоже.
Я с 2010 года слышу о революции в мувене о проекте полиглот, но никакой революции не было и быть не могло.
igor_suhorukov
Основная причина этого было то что до появления Maven 3.3.1 Core Extensions для использования проекта polyglot приходилось патчить сам maven. Сейчас дело с ним налаживается
vba
Там, вроде бы, не все так просто с обратной совместимостью, заявленной еще в далеком 2010. Это только пока версия 0.1.5, и нет гарантий что она не зачахнет еще на несколько лет как версия до этого.
igor_suhorukov
Очень часто есть trade-off и обратная совместимость зависит от того оставлять ли старое говнище или убирать его)
Все возможно. Но прошлая версия зачахла, так как со стороны энтерпрайз не было большого интереса к этой фиче
igor_suhorukov
Продолжая тему maven habrahabr.ru/post/264415
Репозитарий maven делает возможным подгрузку модулей в существующее java приложение без его модификации.
Use case очень похож на Groovy Grape.
jbaruch
Spring boot его использует только потому что Dave Syer — упёртый фанатик. Перед SpringOne 2 года назад, когда релиз поджимал, ни у кого не было времени и сил с ним спорить. Все остальные проекты Spring давно уже на Грейдле.
igor_suhorukov
Разгадка почему они на maven, кроется в магии из пакета github.com/spring-projects/spring-boot/tree/master/spring-boot-cli/src/main/java/org/springframework/boot/cli/compiler/autoconfigure
При том что они активно используют Groovy, они все же выбрали maven. Зря вы клеймите фанатизмом
jbaruch
Я говорил с Дейвом, и я говорил с его шефом Йоргеном об этом. Дейв сказал, что он любит и знает Мавен, и хотя его все уговаривали, что на Грейдле это можно все сделать тоже, у него нет ни сил ни желания учить эту хипстерскую хуету, а Йорген сказал, что поскольку время поджимало, он разрешил не насиловать Дейва Грейдлом и дать ему сделать то, что он знает.
igor_suhorukov
Барух, понимаешь что я не бухал с этими людьми. Но как увижу — сразу узнаю)))
jbaruch
Ну зато я бухал, и все тебе уже рассказал как есть. Попытки притянуть туда рационал о том, что Мавен был выбран, а не Грейдл, из за какой-то функциональности, которая, якобы доступна только в первом, и никак её не решить со вторым, они, конечно, оправданы для тех, кто не знает этой кухни. А кто знает, тот понимает, что Дейв — немножко фанатик, и объясняется всё именно этим.
igor_suhorukov
Понимаешь, я это проверить не смогу и стараюсь критически воспринимать рассказы. Ты считаешь что человек, который отлично владеет технологией и успешно использует её вместо того чтобы использовать «хипстерскую хуету» — априори фанатик?
jbaruch
Ну это рассказы от первого лица, так что можешь верить. А можешь и не верить. Он фанатик не потому что использует Мавен, а потому что вся экосистема Спринга перешла на Грейдл по определенным причинам, а он даже не стал проверять, имеет ли смысл делать Бут на Грейдле. Ответ «я люблю Мавен, он делает то, что мне надо, и я не буду учить ничего другого» свидетельствует о некотором фанатизме, и не априори.
igor_suhorukov
Мне Папа Римский сказал что groovy — благодать, а gradle — мракобесие. Так что можешь верить, а можешь и не верить.
Просто наш спор не очень конструктивен, так как ты advocate евангелист gradle и это твой хлеб.
Переход на любую технологию должен происходить исходя из ее области применимости, уровня владения этой технологией командой, возможности модификации и адаптации под задачу, уровня поддержки IDE, в некоторых проектах «безобразно, но единообразно» лучше чем можно мешать императивно с декларативным «из коробки» и т.п.
jbaruch
Я так понимаю, проблема твоего доверия к моим словам кроется в том, что ты считаешь, что я advocate евангелист gradle? Ну так эту проблему очень просто решить: я не advocate евангелист gradle, и никогда им не был.
Под вторым твоим параграфом я подпишусь полностью. Исходя из всех этих причин все проекты Спринга перешли на Грейдл. За исключением Бута, по причинам, которые я описал выше.
igor_suhorukov
>>Ну так эту проблему очень просто решить: я не advocate евангелист gradle, и никогда им не был.
Разгадка в конфликте интересов maven сentral и bintray!? Это твой хлеб?
jbaruch
Нет, Бинтрей прекрасно работает с Мавеном, а Мавен не имеет прямого отношения к Централу.
Разгадка в том, что я (да и не только я) считаю Грейдл лучшим решением.
Не надо везде искать теорий заговора и подковёрных интересов.
igor_suhorukov
Но в maven зашит по умолчанию maven central, а не не jcenter bintray как в gradle
jbaruch
Игорь, тут прям thread открытий чудных. В Грейдл не зашит Бинтрей. Туда вообще ничего не зашито, разработчики выбирают лучший репозиторий, и с ним работают. Безусловно, когда появляется такая свобода выбора, большинство выбирают Бинтрей. Но это не дефолт, и нигде не прописано.
Я даже не знаю как еще это объяснить. У меня нет никаких скрытых мотивов предпочитать Грейдл Мавену. Ну вот абсолютно никаких. JFrog-у совершенно параллельны системы сборки.
igor_suhorukov
Да, извини, попутал: в groovy grape (groovy-2.4.4.jar!/groovy/grape/defaultGrapeConfig.xml) по умолчанию его приоритет выше других
jbaruch
В Гейпе — да. И каким образом наличие дефолта в Грейпе делает меня необъективным при спорах Мавен/Грейдл?
igor_suhorukov
Объяснил свой промах. Конечно grape никак не связан с твоей предвзятостью к мавену
jbaruch
Особенно если учесть, что предвзятости не существует.
igor_suhorukov
Я тебе не верю)
jbaruch
Ну я даже не знаю, как тебе еще доказать, что никакого интереса от продвижения Грейдла у меня нет. Ты уже предположил все возможные теории заговора между мной, Джейфрогом и Грейдлом, и я уже опроверг их все. Ещё идеи будут?
Borz
чем больше ты будешь пытаться доказать, тем сильнее будет уверенность оппонента в том, что интерес у тебя таки есть. Оно тебе надо?
igor_suhorukov
Я предположил лишь лежащие на поверхности мотивы. Сложно тебе верить, когда называешь фанатом того, у кого другие предпочтения по билд системе. Но при этом занимаешь должность java advocate в компании заинтересованной в gradle/groovy и их комьюнити
igor_suhorukov
>>все проекты Спринга перешли на Грейдл
Вполне может быть политическим решением
jbaruch
Я тебе говорю из первых рук, что нет. Что решение чисто технологическое.
vba
В чем смысл минусовать, ведь вопрос по существу. Как можно построить конструктивный диалог если меньшинство не будет выражать свое мнение из за опасения быть заминусовоным?
webkumo
А вы видите конструктивный диалог в этом комментарии? Там стандартное начало всякого холивара: «х — гавно». Почему такое мнение, с кем сравнивается, какие недостатки преимущества — ничего не описано. И вы хотите, чтобы люди ему плюсы ставили?
vba
Нет не хочу, речь не о плюсах, читайте внимательнее. Не знаю где вы там холивар усмотрели, я этого не имел ввиду.
Suvitruf
Я могу сказать, чего я там НЕ увидел, а не увидел я там конструктивного диалога. Больше на вброс похоже.