Пользователь
29 марта 2013 в 19:12

Разработка → Ant + Ivy VS Maven: давайте жить дружно recovery mode

В этой статье я не буду развивать очередной холивар на тему, что круче. Скорее, будет проведен сравнительный обзор, опираясь на точку зрения самого Apache* и личного опыта нашей команды Build Factory. Обращаю внимание, что речь идет о большом Enterprise. Это означает, что в учет не берутся юзкейсы, когда вчера решили — сегодня уже должно быть сделано. Зато в учет берутся очень большие размеры проекта, распределенные по всему миру команды разработчиков и прочие прелести.
Очень часто можно услышать мнение, что Ant сам по себе с Maven сравнивать нельзя. А вот Ant + Ivy уже может составить конкуренцию Maven. Отчасти это правда.

* Написал сие, ибо помню, где-то сами Apache говорили, что пришло время Maven, старайтесь отходить от Ant. Но так и не смог найти искомое.

Увы, всем известно, что в большинстве компаний/проектов таким аспектом, как Build Management, занимаются сами разработчики. Потому и мнение разработчиков на эту тему в интернетах доминирует. Я читал множество статей с детальным анализом всех плюсов и минусов использования обеих систем, и становилось печально. Основная преследуемая цель этих статей была — скомпилировать код. Ну иногда еще сделать архив, инсталляцию, и залить это все куда-то на фтп или задеплоить на Tomcat. Удобное управление зависимостями, естественно, весьма удобная фича, потому берется в расчет. И все. И потом Ant + Ivy начинают сравнивать с Maven.
Для многих, наверное, станет неожиданностью, что кроме DEV и QA есть еще TL, PM, PO, PSO, Support, CPE, L10N, Installation, дизайнеры, и много других мест, откуда приходит контент, который тоже должен стать частью дистрибутива продукта. Исходя из этого открытия, становится понятно, что оставлять власть над процессом у DEV не есть… эффективно. Потому в больших проектах и есть отдельные команды Build Factory. Но это уже тема совсем для другой истории.
Возвращаясь же к нашей теме, мы пришли к самому главному тезису этой статьи. Ant — это просто Build Tool, Maven — это уже Project Management Tool.
Отлично, теперь, отталкиваясь от этого тезиса, мы будем сравнивать две системы уже совершенно по другому.
Я очень часто видел, как людей пытаются научить пользоваться Maven, объясняя на примере Ant. Т.е. показывают, как делать вещи, которые все привыкли делать Ant'ом, в Maven. И показывают это на примере сравнения build.xml и pom.xml.
Но сравнивать эти два файла в корне не правильно.
Wiki:
Maven, в отличие от другого сборщика проектов Apache Ant, обеспечивает декларативную, а не императивную сборку проекта.

Другими словами, в build.xml мы описываем наши таргеты, последовательно объявляя другие таргеты, что очень похоже на последовательное выполнение команд. Процесс написания build.xml есть ни что иное, как написание скрипта сборки. Одни таргеты мы объединяем в другие, что создает подобие вызова функций, правда не явно — а через иерархию зависимостей. Мы полностью дизайним весь процесс сборки.
В pom.xml у нас нет такой свободы. На самом деле, Maven уже заранее знает, что делать с вашим проектом, если этот проект имеет соответствующую структуру. В pom.xml мы просто описываем проект — это засереализованная в XML информация. И для успешного использования Maven, получается, нам нужно понимать все эти lifecycles, phases и прочие вещи. Нам нужно выучить, что же Maven от нас требует и как он работает, и описать наш проект в pom.xml. В этом обычно и кроется проблема. Обычно в DEV командах подобное «ограничение свободы» воспринимается крайне негативно. Вместо того, что бы задизайнить свою фичу, приходится вникать в то, как работает чужой код, загонять себя в рамки этих ограничений, ну и так далее. Зачем?
Ну, во первых, ограничение свободы само по себе не так уж и плохо. Развивая эту тему, мы можем скатиться до холивара Assembler VS Java, но мы этого делать не будем. Мы просто вспомним, как часто мы видим .classpath и файлы IDE в SCM. Как трудно порой разобраться в этом хитросплетении инклудов build.xml, как трудно это дебажить. Как трудно понять, какой из модулей собирается раньше, и почему этот jar не попал в war. А когда одни только сорцы весят ~3Gb, мы будем тратить наши человекочасы на оптимизацию процесса сборки. Мы будем тратить их так-же на дизайн солюшна, когда наши менеджеры придумают новую интеграцию с другим продуктом, когда изменят принципы локализации или доставки сервис-паков. Вообщем, много головной боли.
А теперь постарайтесь воспринять то, что навязывает нам Maven, не как ограничение свободы, а как некую стандартизацию. Оглянитесь, используя Maven, мы можем интегрироваться в CI System, в SCM, в Issue tracker, Backlog, метрики, да куда угодно. Можем делать релиз продукта одной кнопкой. Ведь все это стало возможным именно благодаря этой стандартизации (конечно, это возможно сделать и с Ant, но какой ценой?). А процесс оптимизации процесса сборки теперь в 90% случаев — это разделение одного модуля на несколько более мелких, которые могут собираться параллельно. Интеграция с другими участниками development process тоже заметно упростилась и стала прозрачной — у каждой команды может быть свой Maven репозиторий (либо один общий корпоративный), и мы лишь по решению топ-менеджеров меняем версии артефактов в pom.xml.

Почему-же, в таком случае, спросите вы, все еще так много говорят об Ant? Как я уже сказал в названии статьи — давайте жить дружно. Давайте просто осознаем, что Ant и Maven прежде всего совершенно разные инструменты. Если у вас простой маленький проект, и нет сильного Project Management'а — вам, верноятно, можно обойтись без Maven. Тем более, если вы с ним не знакомы — ведь вам придется потратить время на изучение. Кроме того, большие монструозные продукты, как правило, очень медлительны и неповоротливы. Именно по этой причине многие из них до сих пор используют Ant. Возможно, менеджеры не видят необходимости мигрировать на Maven, а возможно это legacy продукт (или его версия), который просто поддерживается, и не более. Потому Ant будет востребован и никуда не денется. Но если вы уже знаете, как использовать Maven — используйте его. Это поможет вам потом в будущем не встать на грабли. Все-таки Java и Ant — это в принципе одно и то-же поколение, а Maven создавался значительно позже — вобрав в себя весь накопленный опыт прошедших лет.

Полезные ссылки:
Ivy сравнивает себя с Maven: ant.apache.org/ivy/m2comparison.html
Сравнение от codehaus: docs.codehaus.org/display/MAVEN/Feature+Comparisons
Еще одна интересная точка зрения: xhab.blogspot.com/2006/09/antivy-vs-maven-my-biased-opinion.html
Dmytro Kryvenko @LLIbIcpEP
карма
0,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (90)

  • +2
    Круче — Gradle!
    • –1
      Опять-же, это build tool.
  • 0
    У Maven'a есть свойство, вообще характерное для сильно стандартизованных систем: то, что вписывается в стандарт, делается невероятно легко и просто; шаг в сторону — и начинаются муки. То же самое относится и к тем случаям, когда возникает проблема со сборкой. У Maven'a это случается редко, но на диагностику могут уйти дни. Я столкнулся с ситуацией, когда из-за небольшого расхождения в версиях Maven'a на разных машинах сборка шла в чуть ином порядке, и это влияло на результат. Угробил два дня на то, чтобы понять, в чём же проблема.
    • +2
      >> шаг в сторону — и начинаются муки
      Ничто не мешает писать свои плагины к maven (это очень просто). Плюс есть gmaven-plugin/maven-antrun-plugin, в которых можно делать все, что угодно.

      >> сборка шла в чуть ином порядке
      Проекты не в том порядке или goal'ы не в том порядке? Если первое, то правильно прописывайте зависимости. Если второе, то просто не привязывайте к одной фазе два и более goal'a.
      • 0
        Если я правильно помню ту проблему, то получилось так. Собирали очень большой Flex-проект (виртуальный мир). Всё работало хорошо, но вдруг начиная с какого-то момента сборка на CI-сервере начала содержать некие странные ошибки, в то время как та же сборка, проводимая локально, работала как надо. Как выяснилось, на сервере каким-то образом обновился Maven, и при компиляции проекта он стал указывать библиотеки не в том порядке.

        Понятно, что вообще-то проект должен быть нечувствителен к порядку библиотек. Но выяснилась эта проблема на довольно поздней стадии, и время, потраченное на ее диагностику + время на поиск решения мне попортили много крови.
        • 0
          >> компиляции проекта он стал указывать библиотеки не в том порядке
          А, понятно. Чтобы такого не происходило, можно использовать maven-enforcer-plugin с опцией dependencyConvergence=true.
          • 0
            Спасибо, буду иметьэтот плагин в виду. Однако мне всё же хотелось бы иметь возможность директивно указать порядок — на случай аварийного цейтнота, когда решить проблему нужно срочно, и делать правильно просто нет времени.
            • 0
              На такие случаи нужно просто тщательнее следить за билд-сервером, и не допускать таких спонтанных обновлений. И держать под рукой снапшот системы.
        • 0
          У меня была схожая проблема с джавой и юнит-тестами. Тест кейс был завязан на имена методов и порядок выполнения был важен. Обновился до 1.7 — тесты валятся, оказалось теперь они выполняются в хаотичном порядке (или сортируются по другим принципам, не помню). Это была моя архитектурная проблема из-за недостатка знаний.
          Уверен, картина схожая. Странно, что билд зависит от порядка подключения библиотек.
          • 0
            Тест кейс был завязан на имена методов и порядок выполнения был важен

            Это была моя архитектурная проблема из-за недостатка знаний.


            Может быть с точки зрения build manager это и была «твоя» проблема. Ибо «не поломать» в принципе важно.
            Но на самом деле проблема в том, что полагаться на порядок выполнения юнит-тестов, в корне неправильный подход. Так что тут уже камень в огород разработчиков продукта.
            • 0
              Все верно, но камень именно в мой огород — это был мой pet project и мои юнит тесты :)
            • 0
              почему?

              например я могу сперва протестировать один метод на его работу, а потом другой метод, который в себе используется первый.

              К примеру (Spring), у меня есть тест testDb2DataSource. И есть тест testDb2Sequence, который выполнится только после testDb2DataSource, потому как, если DataSource не поднимается, то смысл мне тестировать как будет в нём отрабатывать кастомизированный Sequence?
          • 0
            В TestNG решается указанием зависимостей через dependsOnGroups или dependsOnMethods
            • 0
              Это решается независимостью тестовых методов друг от друга. Каждый тест — это должно быть одно логическое действие. И если один метод зависит от результатов выполнения другого метода — это плохой тест кейс.
              • 0
                выше написал пример зависимости. или первоначальная проверка подключения и последующая проверка работы кода для данного подключения плохой тест кейс?..
                • 0
                  Да, это плохой тест кейс, полагаться в одном тесте на проверку из другого теста. Каждый тест должен быть выполнен в clean environment. Если смысловая нагрузка конкретного теста в том, что-бы проверить, как чебурашка готовит завтрак, этот тест не должен зависеть от того, как чебурашка проснется. Тест должен быть построен так, что-бы мы гарантированно имели проснувшуюся чебурашку, готовую делать завтрак. Для этого используют Mock объекты. В вашем случае testDb2Sequence должен использовать их, а не результат работы testDb2DataSource.
                  • 0
                    тогда в каком случае применяется dependsOnMethods/dependsOnGroups? можно на том же примере с Чебурашкой и завтраком? :)
                    • 0
                      Мы все еще говорим о JUnit? Каждый живет по своим правилам. Методологий тестирования так-же много, как и методологий разработки.
                      • 0
                        нет, я с самого начала указал, что говорю про TestNG
                        • 0
                          Но я еще раньше говорил о проблеме в JUnit, а потом вы мне как решение предложили TestNG. Вы всегда решаете архитектурные проблемы сменой платформы на ту, где проблема является вполне нормальным поведением?
                          • 0
                            разве смена JUnit на TestNG является сменой платформы а не расширением используемой?
                            лично я считаю, если можно безболезненно заменить одну библиотеку другой и при этом получить доп. функционал, то её можно и даже нужно заменить, чем изобретать «костыли».

                            вот смена maven на ant+ivy в любом направлении — смена платформы

                            UPD. ествественно, что смена библиотеки только ради смены мною не приветствуется
                            • 0
                              В самом начале статьи говориться, что речь в первую очередь о большом интерпрайзе. Тут у нас не будут менять JUnit на TestNG потому что обновили джаву и тесты стали выполняться не в том порядке. Решение обновить джаву обычно принимается ооочень долго и ставиться в backlog так, что бы до релиза осталось куча времени разгребать проблемы. В статье как-раз пища для размышлений, а не призыв срочно менять Ant на Maven. Это совершенно две разные ситуации. Если по каким-либо причинам в проекте был выбран JUnit — надо придерживаться его правил игры, а не менять на TestNG, потому что там обнаружилась одна нужная фича. Переход на TestNG будет долго обсуждаться менеджерами и архитекторами, и тут еще большой вопрос — что быстрее, исправить архитектурные проблемы тест кейсов или дождаться всех аппрувов и переписать тесты с использованием нового фреймворка.
    • 0
      Да, действительно такие ограничения инструмента. Но решить можно многое и даже без собственных плагинов. Не всегда это лаконично, правда
  • +1
    А ещё слёзы наворачиваются видеть файлы проекта под Version Control. Именно возможность открывать помки как описание проекта в той же IDEA обычно делает небывалый фурор, особенно для flexmojos проектов.

    А в сторону всегда можно отойти используя Maven Ant Plugin, к слову:)
  • 0
    Не думал, что ещё где-то ходят споры ant vs maven, особенно, в контексте крупных проектов. Вроде как все переключились на споры maven vs gradle :). Как-то раз писал build.xml для сборки большого иерархического проекта. Это боль, особенно, управление classpath.

    Кастомизация maven не настолько уж сложна. Писал как-то maven-плагин для I10N, который форкал .properties файлы с нужными суффиксами во всех модулях проекта, вставляя заглушки локализации, собирал по всем модулям информацию о ключах и их значениях для всех локалей в сводную Excel-табличку, с которой могли работать переводчики, и позволял автоматически перенести ключи из этой таблички обратно в .properties файлы. Ушло всего несколько дней, при условии моей первоначальной неознакомленности с внутренностями maven.

    Генерация проектных файлов для IDE из pom.xml очень радует, правда, IDEA весьма неплохо понимает проекты на ant.

    Хотел посмотреть на Gradle, но как-то всё руки не доходят.
    • 0
      Gradle, который снова дает нам свободу, чем и завлекает разработчиков. Я впонле ясно написал, чем свобода плоха (с точки зрения инженера Build Factory). Как было сказано в статье, pom.xml — это описание проекта в формате XML. Что мы имеем с Gradle? Groovy, опять ЯП и кучу свободы.
      А интеграция как-же? Не забывайте, что размер Maven комьюнити значительно больше Gradle (пока). Но Gradle дает нам свободу дизайнить билд так, как нам нужно, не думая о других командах, и о том, что им может понадобится в этом всем нашем коде разобраться.
      • 0
        Вы явно пропустили в чем вся соль в Gradle. Он такой-же деклеративный, как и Maven, это такое же описание проекта (в Groovy). Никто и никогда не советовал пользоваться мощью ЯП для написания логики в билд файле. Вот, Ханс об этом — www.gradleware.com/news/blog/fighting-common-misconception-gradle-isnt-imperative
        • 0
          Тем не менее, отступить от стандарта легко и просто прямо в билд файле, что будет добавлять работы в Build Factory, когда какой то девелопер решит, что он лучше знает. А с мавеном не так просто — надо плагин написать, задеплоить его в соответствующий корпоративный репозиторий (на что права нужны), и так далее. Спорить более подробно я не буду, опыта с Gradle не так много. За ссылку спасибо.
          • 0
            Я понимаю ваш порыв все запретить, чтобы не насрали, но может лучше научить не срать?

            Хм, грубо получилось, извините. Ничего личного, надеюсь вы понимаете, что я имею ввиду — давайте учится не вытаптывать газон, а не запрещать на нем отдыхать.
            • 0
              Я абсолютно согласен с таким подходом. Когда команда ну человек 50 максимум. А когда она разбросана по всему миру, и измеряется тысячами… поди научи.
              • 0
                Ну, вы-ж не один build-nazimaster на них всех. Вот каждый свои 50 и учит. И по рукам за косяки, пока не научатся не срать на газоне (да что-ж такое со мной сегодня!)
                • 0
                  Я боюсь, вы не понимаете, насколько быстро растет сложность и падает скорость синхронизации узлов девелопмент-центра с увеличением размера этого центра и введения понятия распределенной разработки. Давайте тогда верстальщиков учить код править так, как им надо? Не дадите? Почему? Ааа, у вас метрики, эстимейты, архитектуру обсудить нужно?
                  У нас тоже есть свои архитекторы, менеджеры, бэклоги, метрики, лонг-терм гоалы и так далее. Вы думаете, впускать в этот процесс девелоперов хорошо отразиться на общих сроках выполнения задач и метриках? Думаете, девелоперы лучше знать будут, то хорошо для QA и менеджеров? Я думаю, что каждый должен заниматься своим делом. Мы не обслуживающий персонал, призванный ублажать и облегчать жизнь девелоперам, мы такие же девелоперы. И каждый должен делать свою работу.
                  • 0
                    Я думаю, я понимаю. И я ни в коем случае не предлагаю вам учить девелоперов писать плагины для Грейдла. Я предлагаю вам учить девелоперов не писать таски в билде.
                    • 0
                      Но Грейдл все таки ЯП, и это возможно. А запретный плод сладок. И это так искусительно. И если мы не будем тратить 30% рабочего времени на мониторинг и модерирование билд файлов, это будет просто замечательно.
                      А Мавен своей декларативностью и не-ЯПобразием сразу отбивает все желание самодеяльничать. И тогда в случае необходимости, девелоперы идут к нам. И в большинстве случаев предлагаемое ими решение ущемляет интересы других команд или доменов, и вообще не по фен-шую.
                      Но ладно, давайте оставим эту тему, я думаю мы друг друга поняли. А как на счет порога вхождения? Мавен — стандарт, найти человека, ориентирующегося в этом стандарте — легко. Грейдл дает нам такой стандарт? Или нам нужно будет придумывать свою архитектуру процесса сборки, а потом каждого новенького кроме всего прочего еще и обучать нашей архитектуре и конвеншнам?
                      • 0
                        Мавен не был стандартом всегда, правда? Переход на Мавен с Анта был намного более болезненным, чем переход с Мавена на Грейдл (конвенции те-же, как структуры проекта, так и артифактов, зависимостей и репозиториев).
                        • 0
                          Под стандартом я имел ввиду конвеншны — четкий стандартный лайф цайкл, и тому подобные вещи, которые мавен нам диктует. Грейдл диктует то-же самое, но в то же время, пожалуйста, пишите код в конфигурационном файле билда. Не похоже ли это на бронированную дверь посреди поля, без стены и так далее? Хочешь — воспользуйся ключем и пройди в дверь. Нет — сделай шаг в лево и обойди ее.
                          • 0
                            Я думаю, что проблема в том, что вы рассматриваете билд как сейф, который надо закрывать бронированной дверью. А я — как газон, на котором все приглашаются отдохнуть.
                            Ну, да ладно. Пусть цветут сто цветов, Мавен никуда не уходит, хотя я думаю, что процентов 70 рынка потеряет Грейдлу в ближайшие два года.
              • 0
                и в с помощью Maven можно неплохо «насрать» в проекте даже с теми плагинами, что есть в репозитарии. факт.
                • 0
                  В предыдущей ветке читайте, про отбивание желания декларативностью и т.д.
                  • 0
                    читал.
                    но вот пример, с которым столкнулся.

                    с помощью jaxb2-maven-plugin генерится source коды, нужные только на этапе сборки. «по дефолту» генерятся в src/main/java. в итоге, их генерация «рушит» success для checkstyle-плагина — приходится для этих пакетов/классов прописывать ignore-списки

                    решил путём «донастройки» aspect-плагина на генерацию в target/generated-sources/jaxb + добавил плагин build-helper-maven-plugin, который «натравил» (add-source) на эту директорию.

                    и где тут декларативность нарушена/отсутствует?
                    • 0
                      FIX: jaxb2-maven-plugin «по дефолту» генерит всё правильно — в target/generated-sources/jaxb — просто «кто-то» переопределял outputDirectory на неправильный путь.
                      • 0
                        Ну так все правильно сделано. В чем вопрос то был? В мавене точно так же можно все поломать, если сильно захотеть. Но это не ЯП, не так искушает.
                        • 0
                          это не вопрос был, а комментарий к «А с мавеном не так просто — надо плагин написать, задеплоить его в соответствующий корпоративный репозиторий (на что права нужны), и так далее.»
  • 0
    Чего реально не хватает — это аналога sbt/gradle над maven а не над ivy. Ибо xml описание достаточно убого и многословно, в том же sbt всё указывается понятнее и красивее, но при этом суть мавена мне кажется правильной — программировать для сборки не нужно.
    • 0
      Как не хватает? Берете polyglot-maven, и вперед. А, он же умер, не родившись? Ну, это потому что фреймворкит не вылечишь, заменив язык дескриптора.
      • 0
        Ух ты, даже не знал про этот проект, спасибо за просвещение. А в чём, по вашему мнению, заключается фреймворкит мавена?
        • 0
          Ну, прям по книжке — безумно легко начать делать стандартные вещи, страшно больно делать что-то не by the book. В какой-то момент, когда переходишь от обязательных вещей (компилятция, сборка джара) к желательным (генерация документации, проверка валидности примеров в документации, нестандартные релизы, и т.д.), решаешь, что ну его нафиг, игра не стоит свеч. В итоге автоматизация проекта страдает, вместо того, чтобы выигрывать из-за использования фреймворка.
          • 0
            Странно, у меня ровно обратное ощущение от мавена. Нужна докуменация? Джавадок-плагин. Не подходид джавадок, нужен доксиджен — доксиджен плагин. Нужно копировать файлы на ftp? antrunner и копипаста антовского таска в три строки. Про проверку примеров в документации — это я вообще плохо понимаю о чём речь — если о поддержке документации в актуальном состоянии, то не знаю, как это вообще можно автоматизировать. Однако если можно через ант и нельзя через мавен — то на то есть антраннер, опять-таки. Нестандартные релизы — тоже не очень понятно что такое. Если имеются ввиду релизы под разные платформы — то на то профили есть… Мне ровно один раз за последние 5 лет пришлось что-то реально писать для того, чтобы мавен заработал — генератор экслипсовских фич. Но такой штуки не умела ни одна билд-система делать и, видать, никому оно не надо…
            • 0
              Ну, если вы спустили с цепи antrunner, то вы пытаетесь вылечить фреймворкит. Вы-ж понимаете, antrunner это бэкдор, который ломает всю идеологию Мавена, и от души насыпает imperative в ваш declarative. Проблема в том, что поскольку этого никто не ожидал, никаких заготовок под эти порции имератива нет, и начинается ад — императивный код в xml-е.

              Конкретно по моим примерам:
              В моих доках есть примеры кода (это тесты). Мне нужно, чтобы при сборке документации, этот код выполнялся, а то вдруг мы чего сломали, а потом попадал в доки.

              Нестандартные релизы — превращение снапшотов в релизы без пересборки, например. Нестандартные схемы версий. ЧуднЫе операции над сорц-контролем во время релизов. Да мало-ли? Все, о чем не подумали Джейсон и компания.
              • 0
                Все описанные проблемы легко решаются своим кастомным кодом — плагинами. И мне кажется, гораздо безопаснее написать свой плагин и объявить его декларативно, чем начать творить магию прямо в конфигурации билда.
                • 0
                  Тут у нас с вами полный концензус, никто и не предлагает творить магию в конфигурации билда Грейдла.
                  По плагинам — к сожалению, из-за зашоренности Мавена возможности плагина весьма ограничены, и легкость их написания, как бы так сказать, ее нет. Вот прямо нынче я пишу совсем нетревиальный плагин для Мавена, аналог нашего плагина для Грейдла, так вот это земля и небо, день и ночь и ад и Израиль.
                  • 0
                    Чем же плагины ограничены? Это обычный джава код, все ограничение составляет JVM. И писать, как по мне, вовсе не сложно. Да, понимаю, на Градле легче, но в соседнем топике мы с вами это уже обсуждаем…
                    • 0
                      Ограничения составляет вовсе не JVM а контейнер впрыскивания зависимостей (ох, блин). Если я не могу в моем плагине использовать другой плагин (сконфигурированый в том-же билде), то эта система плагинов — ацтой.
                      • 0
                        Ну почему? Если вы о переиспользовании кода, то пожалуйста, сделайте этот код отдельным артифактом и подтягивайте зависимостью в оба плагина. Если вы о прямом, кхм, использовании одного плагина в другом… но это же в корне нарушает всю идею жизненного цикла. Я вижу в этой изолированности только фичу. К тому-же, засериализовать в target директорию какой-то xml всегда можно, что бы потом оттуда прочитать, в том-же билде.
                        • 0
                          Вот это фреймворкит в лучшем виде — вы (как пример идеолога Мавена) еще не знаете, что именно я хочу сделать с этими плагинами, но уже запретили. Разве посмотреть как они пробежали и что сделали из другого плагина каким-то образом противоречит изоляции? Я не собираюсь их вызывать, не собираюсь менять драгоценный цикл, все что мне нужно, это собрать информацию. Но нет, нельзя!

                          К тому-же, засериализовать в target директорию какой-то xml всегда можно, что бы потом оттуда прочитать, в том-же билде.
                          Я когда вот такое вижу, вспоминаю эпизод из советского детства. Стоял я как-то три дня в очереди за чемоданами, и когда их наконец завезли, объявили, что будут давать по одному в руки. Какой-то мужик очень громко этим возмущался (благо уже можно было), а я недоумевал — «чего это он? Ведь так просто — приедет вся семья, и каждому по одному в руки!»

                          Это я к тому, что фреймворк, в котором такие костыли являются нормой, обречен.
                          • 0
                            Да, противоречит. Опять про дверь в поле…
                            С xml в target, я и не говорил, что это изящное решение. Я просто сказал, что это возможно, если очень хочется. А вообще, если хочется чего-нибудь такого, нужно остановиться, оглянуться, и подумать еще раз. Скорее всего вы собрались делать что-то не правильно.
                            • 0
                              Да я с удовольствием оглянуться. Подскажите мне the Maven way.
                              Итак, я хочу atomic deploys в multi-module билде. Чтобы все артифакты деплоились не после каждого модуля, а в конце всего билда.
                              Слушаю ваше решение.
                              • 0
                                я с maven мало, но решение в виде основное направление — сборка и отдельный профиль на деплой?
                                • 0
                                  не понял, если честно. Можно по-подробней?
                                  • 0
                                    т.е. основной запуск это package, а с подключением профиля «deploy-all» выполнять только deploy уже готовых пакетов, пропуская test/package этапы.

                                    лично у меня отдельные профили на deploy библиотек, deploy/redeploy приложения. запускаю либо по одному профилю, либо сразу оба (не считая профилей, в которых только properties для нужных серверов)

                                    либо я не так вас понимаю.
                                    • 0
                                      ну вот у меня есть Jenkins, например, в котором я хочу чтобы снепшоты строились, и деплоились в Artifactory, только если все модули прошли. Как мне это сконфигурировать?
                                      • 0
                                        Parameterized Trigger Plugin?

                                        Job на test и Job на deploy
                                • 0
                                  Deploy конечно в таком случае не запустит сборку заного, но некоторые фазы все таки будут выполнены повторно.
                                  • 0
                                    если не нужно, чтобы выполнился какой-то плагин, то всегда есть «execution > phase:none»
                              • 0
                                О, поздравляю, именно такую задачу я и решал недавно, генерируя xml в target, потом его оттуда читая и используя deploy-file. Пришлось. Но по хорошему, да, это не maven way в корне. Модули проекта должны быть самостоятельны. Неудачная сборка кого-го то одного модуля не должна препятствовать деплю остальных успешных модулей.
                                • 0
                                  О, поздравляю, именно такую задачу я и решал недавно, генерируя xml в target, потом его оттуда читая и используя deploy-file
                                  Боже мой, мне это читать даже больно! Вы считаете, что build tool который вас заставляет писать такие адские костыли это как раз тот фреймворк, с которым вы хотите работать?
                                  И делается это не так, а подавлением deploy плагина.. Но все равно, все через жопу, все ужасно, все больно. Не хочу.

                                  Неудачная сборка кого-го то одного модуля не должна препятствовать деплю остальных успешных модулей.
                                  Вот это вообще странное заявление. Например, у меня есть 2 модуля — backend и ui. Backend прошел и задеплоился, UI упал. Чего мне делать с джаром backend-а?
                                  • 0
                                    Вообще-то это менеджеры заставляют меня писать такие адские костыли. Они считают, что повторный validation pom.xml — это часть нового билда. Была бы моя воля, я бы не писал такие адские костыли, а сделал так, как предлагает Borz. Это и есть настоящее правильное решение.
                                    • 0
                                      а, то есть запускать один и тот-же билд 3 раза, что-бы получить atomic deploy — это и есть правильное решение. Ого.
                                      • 0
                                        Ну почему один и тот-же билд? Если это один и тот-же конфигурационный файл билда, но разные фазы\гоалы\профили — это по вашему один и тот же билд?
                                        • 0
                                          Так это-ж не разные. Есть lifecycle, который я люблю. package, install, deploy. Одного и того-же проекта. Т.е. один билд. Я и хочу запустить его один раз, и получить atomic deploy (последний этап в lifecycle, который включает в себя все остальные). Могу, нет?
                                          • 0
                                            А теперь снова возвращаемся к теме, нужен ли вам atomic deploy, и правильно ли это.
                                  • 0
                                    Чего мне делать с джаром backend-а?
                                    Ничего. Он успешен. Занавес, всем спасибо, все свободны. Продолжаем итерацию\спринт или что у вас там.
                                    • 0
                                      Он успешен, но бесполезен. Я собираю продукт, а не абстрактные джары в вакууме. Jar backend-a без ui-a — мусор. Зачем мне мусор в репозитории?
                                      • 0
                                        Это не мусор, это билд N#100500 модуля foobar. С тем же успехом можно говорить, я собираю продукт для релиза, зачем мне его собирать каждый час\каждую ночь — мусор в дженкинсе, в репозитории итд.
                                        • 0
                                          У меня нет билда модуля. У меня есть билд проекта. Сами модули не имеют смысла, потому что они оба часть одного реактора. Это значит, что они зависят от сорцев, а не от джара. Джар в данном случае — бесполезный мусор, потому что он не часть продукта (продукт не собрался), и никто от него не зависит (UI зависит от сорцев, а не от джара, ибо они в одном реакторе).
                                          • 0
                                            Либо вы не понимаете смысл разделения на модули, либо у вас на модули продукт разделен от балды, либо и то и другое вместе. Модуль — это логическая еденица продукта. Я уже молчу о том, что успех\падение билда этого модуля может фигурировать в каких-либо метриках команды, которая занимается этим модулем. Но как-же дебаг? Вдруг кому-то понадобится именно этой версии модуль для воспроизведения какого-то хитрого сценария?
                                            • 0
                                              Давайте сначала тогда. В чем разница между двумя проектами, которые друг от друга зависят, и двумя модулями, прописанными в одном реакторе?
                                              • 0
                                                Уровнем абстракции. Зависит от того, что вы разрабатываете — фреймворк, библиотеку, или продукт. Один единственный модуль вашего продукта А может точно так-же подтягиваться как зависимость к совершенно другому продукту Б в компании. И как мы нарушаем метрику и цикл разработки этого другого продукта Б, если вдруг билд этого модуля в продукте А был успешен, но не задеплоен, потому что atomic deploy мы так любим?
                                                • 0
                                                  Ну и прекрасно. Давайте теперь возьмем пример, при котором зависимость от сорцев (реактор) а не от джара. Такое вообще кошерно, или использовать multi-module maven build это не maven-way?
                                                  • 0
                                                    И в чем разница то? Билд 9 из 10 модулей в продукте — успешен, и эти 9 модулей должны быть задеплоены. Билд самого продукта завален. Вот и все. Тот же дженкинс умеет видеть модули в продукте по отдельности, анализировать метрики по отдельности, даже мейлы слать на каждый модуль отдельно. Реактор — всего лишь агрегатор, который объединяет в один билд несколько модулей. Но он не меняет концепцию.
                                                    • 0
                                                      Реактор — всего лишь агрегатор, который объединяет в один билд несколько модулей. Но он не меняет концепцию.
                                                      Вот это да. Слона то вы и не заметили. Самая главная фича реактора — зависимость от сорцев, а не от джаров! Это меняет все. Это совершенно другой уровень coupling-а. Если при разработке отдельных проектов, каждый джар этих проектов является самостоятельной единицей, со своей версией и со своим release cycle, то при зависимости от сорцев (в реакторе), джары каждого модуля имеют значение только в случае, если все они построились. Иначе — они бесполезны, потому что другие модули от них (от джаров) не зависят.

                                                      эти 9 модулей должны быть задеплоены
                                                      Зачем? Что с ними делать? От них нельзя зависеть, и они не часть продукта.

                                                      Тот же дженкинс умеет видеть модули в продукте по отдельности, анализировать метрики по отдельности, даже мейлы слать на каждый модуль отдельно.
                                                      Я-ж не говорю не прогонять репорты и не посылать мейлы на каждый модуль. Я говорю — не деплоить его в отдельности в репозиторий, потому что он там бесполезен (см. выше).
                                                      • 0
                                                        А я вам скажу, что вы не правы. Джары не бесполезны. Это фича реализации реактора, которую можно и нужно использовать в билде продукта. Но с чего вы взяли, что модуль продукта, этот один из десяти, не может быть использован в другом продукте? Да даже его отдельный классифайр может быть использован. Может, и точка. В этом модуле может быть набор интерфейсов, который используется как API в другом продукте для интеграции с первым. Просто пример.
                                      • 0
                                        ну так сделайте так:
                                        1) модуль app
                                        2) подмодуль backend для модуля app
                                        3) подмодуль frontend для модуля app

                                        делайте сборку и deploy для app. При этом процедуру deploy-я опишите в app-модуле и будет вам счастие — app не дойдёт до deploy если не выполнится сборка любого из его дочерних модулей.
              • 0
                Не, антраннер это вариант для тех ленивых, которые не хотят написать свой плагин и предпочитают использовать готовый и протестированный код.
                Насчёт ваших примеров — не мне судить, но безусловно, мавен, в отличие от анта, предназначен для стандартизации а не наоборот. Зачем что-то делать без пересборки? релизами же должен заниматься CI сервер, а не разработчики. Для тестов есть surefire, который, обратно же, должен запускаться на билдсервере. Многие, в том числе я, считают, что код в комментариях зло. И вообще, меньше комментариев — лучше, ибо код должен быть самодокументирующимся. Конечно, я ничего не знаю про ваш проект и может быть вам и правда всё это не подходит — тогда, увы, мавен и правда не для вас. Но я всё-таки думаю, что лучше, наверное, написать пару свои можо, хоть с анта их перекатать и использовать мавен.
  • 0
    Сравнение последних версий инструментов по общему размеру бинарного кода в их каталогах:
    apache-ant-1.9.2 — 35,6 МиБ
    apache-maven-3.1.1 — 6,2 МиБ
    gradle-1.10 — 43,4 МиБ
    • 0
      О чем может говорить такое сравнение? Особенно учитывая, что мавен сам по себе всего-лишь сердце, и ничего делать не умеет, все даже стандартные вещи вроде компиляции и упаковки jar совершаются с помощью плагинов.
      • 0
        Размер бинарников, как правило, говорит об изначально заложенной функциональности и некоей самодостаточности. Правда, в ходе эксплуатации функциональность инструмента может повышаться самостоятельно (Maven, Gradle) или оставаться на том же уровне с вручную подложенными библиотеками и плагинами (Ant).
        • 0
          Да ни о чем не говорит изначальный размер бинарников. Плохая метрика, абсолютно не учитываяющая особенности архитектуры тех или иных приложений. Все равно, что сравнивать два продукта по размеру инсталлятора, когда у одного из продуктов инсталлятор сетевой — весит пол мегабайта и качает контент по сети.
    • 0
      не показатель.
      тот же Maven одних только плагинов для работы потом ещё минимум мегабайт на 20 выкачает после первого запуска.
      • 0
        Ant' ничего выкачивать не нужно. Он сам-в-себе.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.