Управление версиями зависимостей в Maven проекте

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

Управление версиями зависимостей можно разделить на три части:
  1. версия родительского проекта (если имеется);
  2. версия зависимостей;
  3. версия используемых расширений 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.
Share post

Similar posts

Comments 137

    –3
    Скажите, вам не кажется что тема мувена неактуальна? Даже для ван Зил избегает своего детища.
      +1
      тот же Spring Boot его использует и по сей день
        –1
        Ну а как же, его много кто использует, только вот слезть с него не так то просто, история с коболом повторяется. Если вы в здравом уме и у вас есть выбор для нового проекта между gradle/sbt и maven, вы скорее всего выберете что то из первых двух(даже если они совместимы с репозиториями мувена), ван Зил наверное тоже.

        Я с 2010 года слышу о революции в мувене о проекте полиглот, но никакой революции не было и быть не могло.
          0
          Основная причина этого было то что до появления Maven 3.3.1 Core Extensions для использования проекта polyglot приходилось патчить сам maven. Сейчас дело с ним налаживается
            0
            Там, вроде бы, не все так просто с обратной совместимостью, заявленной еще в далеком 2010. Это только пока версия 0.1.5, и нет гарантий что она не зачахнет еще на несколько лет как версия до этого.
              0
              Очень часто есть trade-off и обратная совместимость зависит от того оставлять ли старое говнище или убирать его)

              Все возможно. Но прошлая версия зачахла, так как со стороны энтерпрайз не было большого интереса к этой фиче
                0
                Продолжая тему maven habrahabr.ru/post/264415
                Репозитарий maven делает возможным подгрузку модулей в существующее java приложение без его модификации.
                Use case очень похож на Groovy Grape.
          +2
          Spring boot его использует только потому что Dave Syer — упёртый фанатик. Перед SpringOne 2 года назад, когда релиз поджимал, ни у кого не было времени и сил с ним спорить. Все остальные проекты Spring давно уже на Грейдле.
            0
            Разгадка почему они на maven, кроется в магии из пакета github.com/spring-projects/spring-boot/tree/master/spring-boot-cli/src/main/java/org/springframework/boot/cli/compiler/autoconfigure
            При том что они активно используют Groovy, они все же выбрали maven. Зря вы клеймите фанатизмом
              0
              Я говорил с Дейвом, и я говорил с его шефом Йоргеном об этом. Дейв сказал, что он любит и знает Мавен, и хотя его все уговаривали, что на Грейдле это можно все сделать тоже, у него нет ни сил ни желания учить эту хипстерскую хуету, а Йорген сказал, что поскольку время поджимало, он разрешил не насиловать Дейва Грейдлом и дать ему сделать то, что он знает.
                0
                Барух, понимаешь что я не бухал с этими людьми. Но как увижу — сразу узнаю)))
                  0
                  Ну зато я бухал, и все тебе уже рассказал как есть. Попытки притянуть туда рационал о том, что Мавен был выбран, а не Грейдл, из за какой-то функциональности, которая, якобы доступна только в первом, и никак её не решить со вторым, они, конечно, оправданы для тех, кто не знает этой кухни. А кто знает, тот понимает, что Дейв — немножко фанатик, и объясняется всё именно этим.
                    0
                    Понимаешь, я это проверить не смогу и стараюсь критически воспринимать рассказы. Ты считаешь что человек, который отлично владеет технологией и успешно использует её вместо того чтобы использовать «хипстерскую хуету» — априори фанатик?
                      0
                      Ну это рассказы от первого лица, так что можешь верить. А можешь и не верить. Он фанатик не потому что использует Мавен, а потому что вся экосистема Спринга перешла на Грейдл по определенным причинам, а он даже не стал проверять, имеет ли смысл делать Бут на Грейдле. Ответ «я люблю Мавен, он делает то, что мне надо, и я не буду учить ничего другого» свидетельствует о некотором фанатизме, и не априори.
                        +1
                        Мне Папа Римский сказал что groovy — благодать, а gradle — мракобесие. Так что можешь верить, а можешь и не верить.
                        Просто наш спор не очень конструктивен, так как ты advocate евангелист gradle и это твой хлеб.

                        Переход на любую технологию должен происходить исходя из ее области применимости, уровня владения этой технологией командой, возможности модификации и адаптации под задачу, уровня поддержки IDE, в некоторых проектах «безобразно, но единообразно» лучше чем можно мешать императивно с декларативным «из коробки» и т.п.
                          0
                          Я так понимаю, проблема твоего доверия к моим словам кроется в том, что ты считаешь, что я advocate евангелист gradle? Ну так эту проблему очень просто решить: я не advocate евангелист gradle, и никогда им не был.

                          Под вторым твоим параграфом я подпишусь полностью. Исходя из всех этих причин все проекты Спринга перешли на Грейдл. За исключением Бута, по причинам, которые я описал выше.
                            0
                            >>Ну так эту проблему очень просто решить: я не advocate евангелист gradle, и никогда им не был.
                            Разгадка в конфликте интересов maven сentral и bintray!? Это твой хлеб?
                              0
                              Нет, Бинтрей прекрасно работает с Мавеном, а Мавен не имеет прямого отношения к Централу.
                              Разгадка в том, что я (да и не только я) считаю Грейдл лучшим решением.
                              Не надо везде искать теорий заговора и подковёрных интересов.
                                0
                                Но в maven зашит по умолчанию maven central, а не не jcenter bintray как в gradle
                                  0
                                  Игорь, тут прям thread открытий чудных. В Грейдл не зашит Бинтрей. Туда вообще ничего не зашито, разработчики выбирают лучший репозиторий, и с ним работают. Безусловно, когда появляется такая свобода выбора, большинство выбирают Бинтрей. Но это не дефолт, и нигде не прописано.

                                  Я даже не знаю как еще это объяснить. У меня нет никаких скрытых мотивов предпочитать Грейдл Мавену. Ну вот абсолютно никаких. JFrog-у совершенно параллельны системы сборки.
                                    0
                                    Да, извини, попутал: в groovy grape (groovy-2.4.4.jar!/groovy/grape/defaultGrapeConfig.xml) по умолчанию его приоритет выше других
                                          <ibiblio name="jcenter" root="https://jcenter.bintray.com/" m2compatible="true"/>
                                    

                                      0
                                      В Гейпе — да. И каким образом наличие дефолта в Грейпе делает меня необъективным при спорах Мавен/Грейдл?
                                        +1
                                        Объяснил свой промах. Конечно grape никак не связан с твоей предвзятостью к мавену
                                          0
                                          Особенно если учесть, что предвзятости не существует.
                                            0
                                            Я тебе не верю)
                                              –1
                                              Ну я даже не знаю, как тебе еще доказать, что никакого интереса от продвижения Грейдла у меня нет. Ты уже предположил все возможные теории заговора между мной, Джейфрогом и Грейдлом, и я уже опроверг их все. Ещё идеи будут?
                                                –1
                                                чем больше ты будешь пытаться доказать, тем сильнее будет уверенность оппонента в том, что интерес у тебя таки есть. Оно тебе надо?
                                                  0
                                                  Я предположил лишь лежащие на поверхности мотивы. Сложно тебе верить, когда называешь фанатом того, у кого другие предпочтения по билд системе. Но при этом занимаешь должность java advocate в компании заинтересованной в gradle/groovy и их комьюнити
                                –1
                                >>все проекты Спринга перешли на Грейдл
                                Вполне может быть политическим решением
                                  0
                                  Я тебе говорю из первых рук, что нет. Что решение чисто технологическое.
              –1
              В чем смысл минусовать, ведь вопрос по существу. Как можно построить конструктивный диалог если меньшинство не будет выражать свое мнение из за опасения быть заминусовоным?
                +2
                А вы видите конструктивный диалог в этом комментарии? Там стандартное начало всякого холивара: «х — гавно». Почему такое мнение, с кем сравнивается, какие недостатки преимущества — ничего не описано. И вы хотите, чтобы люди ему плюсы ставили?
                  0
                  Нет не хочу, речь не о плюсах, читайте внимательнее. Не знаю где вы там холивар усмотрели, я этого не имел ввиду.
                    +1
                    Я могу сказать, чего я там НЕ увидел, а не увидел я там конструктивного диалога. Больше на вброс похоже.
              +5
              Не очень понятно зачем слезать с мавена. Мавен отличный инструмент, прекрасно справляющийся со своими задачами. И не говорите про развесистость xml. Много вермишели можно и на груви и на скале написать.
                +1
                если у тебя многомодульный разнопрофильный проект, то удобнее тот же gradle будет в последующем.
                но если у тебя простой одномодульный проект, то Maven за глаза.

                а встречается и такое: в Hybris используется сразу ant + gradle + maven (в его формате описаны зависимости).
                  –1
                  Cobol, vbscript, etc тоже отличные инструменты, они прекрасно справляются со своими задачами зачем с них слазить.

                  Вопрос, скажите а как мувен способен уберечь вас от jar-hell когда у вас есть две зависимости A и B которые ссылаются на зависимость C, правда на разные версии. Но вот беда C между эти двумя версиями сменила тоже название артифрукта. Результат плачевен, мувен не справляется со своей прямой задачей, да и никогда с ней не справлялся.

                  Он устарел морально и физически, в нем еще куча неудобностей, таких как иерархия проектов или централизация.
                    +1
                    Повторюсь как когда-то дискутировал здесь с jbaruch, что разные версии зависимости «C» — это беда платформы jvm, а не мавена конкретно. А эксклуды — просто костыль. jigsaw в jdk9 решит эту проблему, как и OSGI решает ее сегодня

                    Если бы мавен не справлялся со своей задачей, то не просуществовал до сих пор с таким количеством проектов на нем. В нем есть сильные и слабые стороны, как в любой технологии
                      +1
                      На мой взгляд он просуществовал столько лет из за отсутствия конкурентов. В нем были допущены ошибки на концептуальном уровне, и данные ошибки плавают от версии к версии, что в конце концов и парализовало развитие проекта на долгие годы. Мало того что ван Зил не хотел обращать внимание на свои упущения так он еще дальше увязал в них и тянул за собой пользователей мувена. Один из ярких примеров при переходе с 2 на 3 версию, а давай ка братец вместо того что бы скачивать половину интернета будем, внимание, скачивать ее параллельно, ведь так быстрее.
                        0
                        Если вы правы, то он должен уже исченуть. Ведь Ivy и Gradle уже существуют
                          0
                          уважаемый vba, вам есть что ответить по существу?
                            –1
                            Да конечно. Дальше можно углубляться в размышления что если бы… Да оппоненты у мувена сейчас есть. Ведь не реально уговорить какой нибудь сбербанк потратить кучу денег на просто переход с мувена на gradle только по прихоти программистов. А вот обновится с одной версии на другую это проходит не так болезненно.

                            Ведь cobol или coldfusion живее всех живых, и до сих пор можно видеть анонсы о поиске специалистов, кстати с очень достойной оплатой. Для исчезновения или перерождения мувена понадобится несколько десятилетий.
                              0
                              За редкую легасятину всегда хорошо платят. Тут вопрос только в том, что Maven3 — это не легаси)

                              Потратив кучу денег на переход, надо быть еще уверенным, что это не сломает что-либо, что весь инструментарий и IDE поддерживает не только редактирование билд скриптов, но и рефакторинг и т.п., что технология завтра не зачахнет

                              Время покажет, если через десятилетия будет эта платформа
                                –1
                                Простите, не напомните в каком году выпустили не-легаси версию Maven3, в 2008 или в 2009?
                                  0
                                  Да разве это легаси? maven aether — ядерный компонент maven3 так вообще state of the art для разрешения зависимостей.
                                  Тот же Grape из последнего groovy использует более легасятный ivy provider. Комманда spring boot с трудом вкрутила в groovy aether провайдер для grape
                                    0
                                    Кстати по мне так определение legacy тут не особо уместно, ибо у него немного другое значение. Я больше тяготею к термину устаревший.

                                    Мне кажется что мувен третей версии устарел. Я так понимаю что вам так не кажется, тогда следуя вашей логике можно сказать что ivy не устарел.

                                    Часто бывало что команда spring не блистала дальновидностью.
                                      0
                                      Укажите пожалуйста, где именно из моей логики следует что ivy не устарел

                                      >Часто бывало что команда spring не блистала дальновидностью.
                                      Это ваше личное мнение? Можно примеры!?
                                        –3
                                        Ну как же, возраст не показатель, отсутствие пульса не показатель да и концептуальные упущения путешествующие из n-1 в n не показатель тогда ivy не устарел. Что тогда для вас считается основанием полагать устарел он или нет?

                                        Про spring source, особо не буду говорить ибо оффтоп и времени на это нет, вам так разве не кажется?
                                          0
                                          >Про spring source, особо не буду говорить ибо оффтоп и времени на это нет, вам так разве не кажется?
                                          Вы использовали это как аргумент в споре и при резонном вопросе сразу же закрыли обсуждение.

                                          >>Что тогда для вас считается основанием полагать устарел он или нет?
                                          Мнения людей, столкнувшихся с ограничениями в разрешении зависимостей из-за ivy в groovy Grape, которые невозможно обойти при использовании ivy.

                                          Я считаю что Grape — очень ценный для многих применений в groovy скриптах, но ivy тормозит его повсеместное применение
                          +1
                          Насчет проблем jvm я частично не соглашусь, ведь есть же плагины-костыли для мувена которые проверяют classpath на «дубликаты».
                            +1
                            maven enforcer плагин делает это. Изначальную ущербность плоского classpath решают либо иерархическими загрузчиками классов, либо ждем jigsaw — модульность на уровне платформы jvm
                          0
                          Расскажите пожалуйста, что вы имели в виду под централизацией
                            0
                            Имеется в виду использование различных репозиториев, чем их больше тем время скачивания увеличивается. Костыль для этого сводился к установке одного центрального, буфер репозитория. Я сейчас не помню что за фирма сопровождала данный проект.
                              0
                              Да полно решений про зеркалирование sonatype, artifactory. Никто не мешает в проекте указывать свой список repository!?)
                              jcenter не гнушаются использовать в gradle, хотя по сути это тоже центральный репозитарий
                                0
                                Мне кажется, решение это когда производитель (в данном случае мувен) гарантирует вам что данное решение им поддерживается и все будет работать как следует при переходе от версии к версии. Иначе это workaround, по моему.
                                  0
                                  А разве repositories>repository не работает между версиями?

                                  mirrorOf тоже вроде работает как прокси для внешних репозитариев в изолированной сети, если его использовать по назначению
                                    0
                                    Я не знаю, я бы не стал полагаться просто на авось в данной ситуации. Обычно мажорные релизы на то и мажорные что не соблюдают обратной совместимости, и могут все поломать включая repositories>repository и mirrorOf итд.
                                      0
                                      Из ваших слов следует что если выпускается мажорный релиз, то теряется обратная совместимость и можно даже не вникать в детали, а сразу спорить
                                        0
                                        Нет, увы, не следует, вы опять читаете между строк, вы не обратили внимание на слово «могут»? Тема исчерпана.
                                          0
                                          Вы искусно меняете тему разговора и закрываете обсуждение, когда вам это выгодно!?
                                      0
                                      mirrorOf плох тем, что де-факто запрещает использовать больше чем один репозиторий, даже когда они все приходят из правильного места. Это гильотина от головной боли.
                                      0
                                      Это какая-то полная ерунда. Это все равно, что сказать, что от Оракла теперь требуется гарантия поддержки всех Джава библиотек в мире, и что они будут работать как следует при переходе к следущей версии.
                                      Почему один из инструментов экосистемы (Мавен) должен гарантировать поддержку другого (бинарного репозитория)?!
                                        0
                                        >>Почему один из инструментов экосистемы (Мавен) должен гарантировать поддержку другого (бинарного репозитория)?!
                                        Потому что в противном случае случается то, что было в ant — когда все зависимости качались wget и добавлялись в scm проекта
                                          0
                                          Я не спорю, что они должны работать по стандарту. Я спорю, что они обязательно должны приходить из одного источника и гарантировать поддержку. Потому что это обязательно означает, что универсального репозитория создать невозжно, ибо Мавеноский репозиторий можно получить только от Мавена, Нугетовский только от Микрософота, Рубийский только от х.з. кого, и так далее.
                                            0
                                            >>Я спорю, что они обязательно должны приходить из одного источника и гарантировать поддержку
                                            А зачем тогда jfrog пытается подсадить всех на bintray!? Не поверю в этом контексте в альтруизм, тут уже шкурный интерес прослеживается
                                              0
                                              Мы никого не пытаемся пересадить. Мы предлагаем продукт, который объективно лучше, чем конкуренция. Кто хочет — пересаживается, кто хочет — нет.
                                              Никакого альтруизма нет, и шкурный интерес, конечно есть. Только не тот, который ты думаешь. Всё девелоперы опенсорца, которые публикуют бесплатно пакеты в Бинтрей — не последние люди в компаниях, которые будут за большие деньги строить свой download center на Бинтрее благодаря рекомендации тех самых девелоперов опенсорца.
                                              Это простая, честная и банальная модель, которую никто не скрывает.
                                                0
                                                Gradle такой же продукт, со своими преимуществами и слабыми сторонами. Не надо идеализировать технологию.

                                                Но модель работы Бинтрей понятна. Тут каждый волен выбирать. В любом случае спасибо за честный ответ!!!
                                                  0
                                                  Никто не идеализирует технологию. У Грейдла хватает недостатков. Он просто лучше, чем конкретно Мавен в большинстве случаев.
                                                  На счет «каждый волен выбирать» не понял, это про что?
                                                    0
                                                    >>Никто не идеализирует технологию. У Грейдла хватает недостатков. Он просто лучше, чем конкретно Мавен в большинстве случаев.
                                                    Тут опять же кому как удобнее. Тем более что затраты времени на написание и поддержание билдскрипта должны быть минимальны. Сложно будет объяснить бизнесу что это вместо работы команда(которая мало знакома с gradle) билд скрипт пишет днями
                                                      0
                                                      Опять двадцатьпять. Когда в скрипте нет тасков, то он короток, лаконичен, и требует меньшей поддержки, чем мавеновские хмл-ные простыни.
                                                        0
                                                        Ну это все слова… Повторюсь что бизнесу все равно насколько лаконичен билд. Им главное чтобы ПО работало и приносило прибыль. И если команда будет ковырять gradle изо дня в день, всех уволят!
                                                          0
                                                          И если будут ковырять Мавен, и уволят точно так-же. С чего ты взял, что Грейдл нужно ковырять больше?
                                                          Ровно наоборот, тривиальные вещи решаются в Грейдле так же легко как и в Мавене, а вот на нетривиальные, на которые в Мавене тратятся дни, в Грейдле решаются за часы.
                                                            0
                                                            Да ну, найти человека реально знающего Maven гораздо проще чем эксперта по gradle. Аргумент про часы и дни притянут за уши
                                                      0
                                                      >>На счет «каждый волен выбирать» не понял, это про что?
                                                      Волен выбирать готовый бинтрей или самому поддерживать подобную инфраструктуру
                                                        0
                                                        А, ну это конечно. Обычно, правда, трудоемкие аспекты, которые не являются core, педпочитают buy instead of build, но дело хозяйское, да.
                                      0
                                      Единственный костыль в использовании организационного прокси это то, что в Мавене разрешено прописывать источники зависимостей в метадате пакета. Всё остальное в этом подходе ни костыль ни разу.
                                    0
                                    как мувен способен уберечь вас от jar-hell когда у вас есть две зависимости A и B которые ссылаются на зависимость C, правда на разные версии. Но вот беда C между эти двумя версиями сменила тоже название артифрукта

                                    Мы для этого используем maven-duplicate-finder-plugin
                                    0
                                    Все таки gradle vs maven не совсем корректно сравнивать. Так как maven — это декларативный подход к сборке проекта, хоть и со многими ограничениями.
                                    И maven эволюционирует с тем же Polyglot, для тех кому хочется намешать императивных комманд с декларативными в процесс сборки или писать его конфигурацию на том языке, который ему нравится, вместо xml
                                      0
                                      Так же как и не стоит сравнивать sbt/maven, ivy/maven или maven2/maven3, зависит в каком контексте идет сравнение.
                                        +1
                                        Вы искажаете факты. Например maven2/3 почти одно и то же для конечного пользователя.
                                        Повторюсь еще раз сравнивать что лучше можно лишь в одной категории. Вряд ли кто будет всерьез сравнивать карьерный самосвал и легковой автомобиль или подводную лодку с самолетом
                                          –2
                                          Нет вы не правы, читайте внимательнее. Все вышеуказанное в той или иной мере одно и тоже для конечного пользователя. Я право не совсем понял что вы хотели сказать этим: «Повторюсь еще раз сравнивать что лучше можно лишь в одной категории».

                                          Да и если мы уже перешли на личностное, то я, увы, вынужден покинуть данный топик. Я думаю я свою точку зрения высказал, вы свою тоже. Тема исчерпана. Всего хорошего.
                                            0
                                            Очень жаль что у вас закончились аргументы и вы решили покинуть обсуждение в разгар спора
                                        +1
                                        Грейдл, если что, ни разу не менее декларативный чем Мавен.
                                          0
                                          То что народ повсеместно в билдах мешает груви код и gradle dsl это декларативно?
                                            0
                                            «Декларативная сборка подразумевает написание программистом функционального и логического алгоритма для исполнения» (источник)
                                            что в Maven, что в Gradle это именно так. Только в Maven это через конфигурацию в xml файле, а в Gradle через Groovy-код в сборочном скрипте.
                                              0
                                              Не совсем так, так как смесь груви кода и конфигурации это нечто иное чем декларативное описание сборки. В случае maven — то что если тебе нужно написать часть билда в императивном стиле, то приходится писать свой плагин для этого. И конфигурация остается декларативной
                                                0
                                                В Gradle как раз применяется подход «программирование в ограничениях». разве нет?
                                                  0
                                                  Можно пример? В конфигурацию билда gradle можно вставлять произвольный groovy код и gradle не анализирует AST программы. Так что не вижу противоречий со своим прошлым высказыванием.
                                                    0
                                                    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)
                                                        }
                                                    

                                                    Разве это декларативный подход?
                                                      0
                                                      Нет, и тому кто это писал надо руки оторвать. Как, например и тому, кто писал вот эти 35247 помов.
                                                        +1
                                                        Это да, тонко подмечено!) Только в maven — это выглядет извращением, а в gradle — фича.
                                                        В любом случае я согласен, что многое зависит от умения правильно готовить билд
                                                          +1
                                                          Нифига это не фича. Грейдл говорит прямым текстом, фунционал тасков надо писать в плагинах, а не фигачить в скрипт. Ровно как в Мавене.
                                                            0
                                                            Если что-то не запрещается и ограничивается на уровне системы, это очень часто используется «начинающими пользователями»
                                                              +1
                                                              Ой, да ладно, народ учится прикручивать антран чуть ли не сразу после того, как выясняется, что кроме дефолтного лайфсайкла нужно еще что либо. Траектория именно такая:
                                                              — ой как няшно всё работает из коробки
                                                              — ой, а вот тут мне нужно кое что еще, где я пишу код, который это делает?
                                                              — то есть как нельзя? Но я же в анте так делал!
                                                              — а, ну вот, можно же антран. А дальше я знаю.
                                                                0
                                                                Кстати, не факт что по той ссылке все что ты выслал, все относится к хачным ант скриптам.
                                                                Достаточно частый usecase — это замена шел скрипта в билде, например регэксп реплейс из анта
                                                                  0
                                                                  Вот что мене действительно понравилось в груви — это работа с процессами из коробки «ls».execute()
                                                                    0
                                                                    Тебе еще очень много что понравится, когда ты с этим столкнешься. Ну, или, почитаешь специально.
                                                                      0
                                                                      Я сейчас как раз в groovy по локти.
                                                                      Получается ты согласен, что не все вызовы ант плагинов по той ссылке относятся к императивному куску билда?
                                                                        0
                                                                        Конечно не все. На вскидку, процентов 90.
                                                                          0
                                                                          Вдруг только 10%!? Никто не считал же
                                                                            0
                                                                            Ой, да ладно. Мы все прекрасно знаем для чего в большинстве проектов добавляется антран.
                                                                              0
                                                                              Я всегда за такое по рукам бил) Как и за комиты jar в scm
                                                                              Так что у нас с тобой разный опыт применения antrun plugin
                                                                                0
                                                                                Так я за таски в гредл скриптах тоже бъю по рукам. К сожалению это не значит, что так никто не делает, и это ровным счетом ничего не доказывает. Есть очевидный абьюз, и я тебе только что показал, как он широко распространен.
                                                                                  0
                                                                                  Ты лишь показал сколько вхождений слова antrun на github, без анализа содержимого antrun и сказал что в 90% это императивные инструкции в билде основываясь на собственных предположениях и убеждениях
                                                                                0
                                                                                Запуск шелл-скрипта?
                                                                                  +1
                                                                                    +1
                                                                                    Внезапно… Спасибо. Года два назад искал — не смог найти этот плагин, пришлось наворачивать конфигурацию антрана…
                                                                  0
                                                                  А зачем тогда в грейдл добавили апи анта? Зачем писать плагин ради одного билда? Зачем вообще груви, если билд скрипт это просто конфигурация?
                                                                    +1
                                                                    Прекрасные, прекрасные вопросы.
                                                                    — А зачем тогда в грейдл добавили апи анта?
                                                                    Это не дрейдл добавил. Объект анта существует в Груви. И в грейдле он нужен для того, чтобы дёргать таски анта из старого билда во время постепенного перехода на Грейдл.

                                                                    — Зачем писать плагин ради одного билда?
                                                                    Это какой-то странный вопрос. Зачем писать таски ради одного билда? Зачем писать билд ради одного билда? Наверное ты имел ввиду «зачем выносить логику в отдельные классы, заворачивать их в джар, публиковать джар и потом дергать его из билда, если на самом деле реюза никакого не предвидится?» На этот вопрос я могу ответить: Плагины в Грейде, в отличие от Мавена, не обязательно должны быть отдельнособранными джарами. Это могут быть классы в специальной директории в проекте, или даже другие скрипты, в которых будут прописаны таски.

                                                                    — Зачем вообще груви, если билд скрипт это просто конфигурация?
                                                                    Не знаю. А где ты увидел Груви? Билд скрипты на Грейдле это не Груви, а Грейдл DSL, а вот он уже потому что он намного удобней, чем XML.
                                                                      0
                                                                      Билд ради билда — это чистое передергивание, какая есть реальная нужда писать плагины ради одного билда? Сам грейдл как раз пишет, что плагины нужны для реюза.

                                                                      Если писать весь функционал в плагинах, то грейдл скрипт превратится в конфигурацию для плагинов, так он сейчас и выглядит в андроид студии, залезть подправить циферки или вписать новую зависимость. И мягко говоря не летает.

                                                                      Грейдл DSL все равно ведь расширение груви, разве не так? Поддержка редактирования в ИДЕ сильно хромает. Таким образом, для конечного пользователя разницы нет никакой, в каком файле что править.
                                                                        0
                                                                        я же объяснил, плагины могут быть просто отдельными скриптами, в которые пользователи не лезут своими шаловливыми ручками

                                                                        Именно так, это и есть декларативный билд. Я не знаю, с чего ты взял, что он не летает, когда летает еще как.

                                                                        Ну и что, что расширение Груви? Для пользователей, которые не знают Груви, это совершенно отдельный язык для описания билда. И им совершенно все равно, реализован он на Груви, на Джаваскрипте, или на Ассемблере. Для них это прозрачная деталь реализации. А разница для конечного пользователя есть только в том, насколько DSL хорош — удобен, гибок, понятен, и так далее. Так получилось, что на Груви писать DSL-ы удобно и просто, вот и всё.
                                                                        А вот те, кто пишут плагины наслаждаются всеми плюшками Груви, если хотят, или сурово кодят на Джаве, если не хотят.
                                                                        –1
                                                                        Да, факт что нормальный DSL на java не сделать. Так что логичный выбор языков groovy, scala, ruby для DSL как первый вариант или своей граматики и парсеров на основе нее как второй вариант, либо yaml/xml/json и код валидирующий/выполняющий эту конфигурацию
                                                        0
                                                        То, что народ повсеместно в мавеновских хмлах фигачит ант-таск-плагины и начинает писать код на хмле это тоже не ахти как декларативно.
                                                        При правильном использовании, Грейдл деклеративен не менее чем Мавен. Ну, а то, что народ молотками шурупы забивает, это увы и ах. «Технологии — идеальны, а вот люди — мудаки»(с).
                                                          0
                                                          О, боги! Это родом из maven — aether и там твоя аватарка
                                                          И главный груви фреймворк для веб grails.io/post/40093552028/road-to-grails-23-improved-dependency-resolution
                                                            0
                                                            Что лишь доказывает еще раз, что я прекрасно знаю все плюсы и минусы.

                                                            А вот Грейлз ты напрасно притащил, они с третьей версии переползли полностью на Грейдл, потому что попытки впаять Азер в Гант были ужас-ужас. Мы в Бинтрее с этим намучались не то слово как.
                                                              0
                                                              Похоже что доказывает что jfrog использует в проекте aether

                                                              Использование aether в spring boot в груви скриптах — успешно, это все же не ivy с его детскими болезнями
                                                                0
                                                                Нам пришлось хакать aether для нашего Maven plugin-а. Нигде больше мы его не используем.
                                                                Снял я с нас жуткий поклёп? :)
                                                      0
                                                      Еще один момент — в грейдле нет стандартов как в мавене. Там говорят — можно всё! И все делают как им нравится. В мавен проект приходишь — делаешь clean install и у тебя готовое приложение.
                                                      В каждом гредл проекте тебе нужно ковырять билд скрипт чтобы понять правила конкретного монастыря.
                                                        +1
                                                        Да откуда же вы эту хуйню берете-то, а?! Где в Грейдле говорят «можно всё»?! Конечно там есть стандарты. Есть и стандартный layout, и стандартный lifecycle, и стандарт artifact metadata.
                                                        И нет, большинство Грейдл проектов одинаковы, и все очень похожи.
                                                          +1
                                                          Что значит откуда? Приходишь в 90% опенсорсных проектов и там получаешь квест аля ант. Как ближайший пример — почти все дженкинс плагины, которые собираются гредлом. То что там есть стандарты о которых никто не знает, потому что они слаборекомендательные — это значит именно «можно все».
                                                            0
                                                            То, что в каких-то проектах у вас квест, не значит, что в Грейдле говорят, что «можно всё». И о том, что там есть стандарты, знает любой, кто знает что-либо о Грейдле. С этого начинаются доки, с этого начинаются тренинги и презентации.
                                                              +1
                                                              Это идеальный мир) Если тул разрешает многое, на многих проектах начинается анархия
                                                                +1
                                                                Тул не «разрешает многое», а тул «позволяет многое». Для тех, кому действительно нужно то, что дефолты из коробки не дают.
                                                                Но да, любой спор о Грейдле упирается в отсутвие «build nazi plugin», который запрещает писать таски в билд скрипте проекта.
                                                                  +1
                                                                  Накидайте пожалуйста линков, чтобы тыкать в них носом горе-меинтейнеров?
                                                                    0
                                                                    Линков на что?
                                                                      +2
                                                                      На мифические правила и стандарты
                                                  –1
                                                  Возможно, что лучше был бы даже плагин для ИДЕ, который подсвечивал бы зависимости, для которых есть более новые версии. Похожим образом сделано для грейдла в андроид студии. Менять все версии за раз черевато сайдэффектами, лучше осознанно обновлять и тестировать по одному.

                                                  Меня давно мучает вопрос почему создатели грейдла выбрали груви, а не, скажем, яваскрипт? Можно было сделать АПИ для билдов прямо на яве, тогда можно было бы описать весь билд на том же языке и предельно четко, да, его пришлось бы компилировать, но это можно автоматизировать.
                                                    0
                                                    Вы Java и Javascript не путайте — разные совсем языки.
                                                      0
                                                      Я их и не путал, в первом случае яваскрипт, во втором ява.
                                                        0
                                                        Тогда поясните пожалуйста данный кусок текста:
                                                        «Меня давно мучает вопрос почему создатели грейдла выбрали груви, а не, скажем, яваскрипт? Можно было сделать АПИ для билдов прямо на яве, тогда можно было бы описать весь билд на том же языке и предельно четко, да, его пришлось бы компилировать, но это можно автоматизировать. „
                                                          0
                                                          1. Вместо груви использовать яваскрипт, он тоже динамический и более распространенный.
                                                          2. Почему бы не сделать билдсистему на яве(Java)? Максимальная гибкость, разработчики знают идеально, работает быстро, статическая типизация.
                                                            0
                                                            В таком виде — действительно не возникает ощущения что вы приравниваете эти языки друг к другу… Вам следовало сразу абзац разбить на два, либо иным способом более чётко провести границу между совершенно разными предложениями.
                                                              0
                                                              1. Потому что он не похож на Джаву (см. собвственный второй коммент).
                                                              2. Поотму что Джава ужасный инструмент для построения DSL (намного хуже, чем Груви), и ужасный инструмент для описания метадаты (намного хуже, чем ХМЛ). Но на вопрос «почему бы не сделать» ответ «сделали и не одну». Гугль тебе в помощь.
                                                                +1
                                                                Не похож на яву — ну и что? Он все равно куда более известный, чем груви, плюс есть jvm имплементация.

                                                                Хуже или лучше — это твои личные эмоции. К примеру, в ИДЕ поддержка грейдл ДСЛ на нуле, даже хуже чем XML, андроид студия не в состоянии подсветить банальную ошибку в скрипте без его запуска, нет никакого хелпа или автокомплита.

                                                                Ты похоже не понял, я спрашивал, почему бы сам билд не описать на яве, а не только сам тул.
                                                                  –1
                                                                  То есть как «ну и что»? Ну и то, что 9 миллионов девелоперов (или сколько там нынче) будут чувствовать себя намного лучше в знакомом синтаксисе, чем в незнакомом.

                                                                  Хуже или лучше это факты, и к эмоциям отношения не имеет. Если в языке нет поддержки скриптов, создания ассивов и мапов на лету, алиасинга классов, и везде нужны точки с запятыми, этот язык не подходит для DSL. Извините.
                                                                  К поддержке ИДЕ это не имеет никакого отношения. Точнее имеет, но обратное от того, что ты пытаешься доказать. То, что ИДЕЯ по умолчанию не понимает, что это за синтаксис такой означает, что ДСЛ хороший, а не плохой.

                                                                  И билд не описать на Джаве, потому что билд описывается ДСЛ-ом, а Джава плохой язык для создания ДСЛ-ов.
                                                    • UFO just landed and posted this here

                                                      Only users with full accounts can post comments. Log in, please.