Comments 90
Круче — Gradle!
У Maven'a есть свойство, вообще характерное для сильно стандартизованных систем: то, что вписывается в стандарт, делается невероятно легко и просто; шаг в сторону — и начинаются муки. То же самое относится и к тем случаям, когда возникает проблема со сборкой. У Maven'a это случается редко, но на диагностику могут уйти дни. Я столкнулся с ситуацией, когда из-за небольшого расхождения в версиях Maven'a на разных машинах сборка шла в чуть ином порядке, и это влияло на результат. Угробил два дня на то, чтобы понять, в чём же проблема.
>> шаг в сторону — и начинаются муки
Ничто не мешает писать свои плагины к maven (это очень просто). Плюс есть gmaven-plugin/maven-antrun-plugin, в которых можно делать все, что угодно.
>> сборка шла в чуть ином порядке
Проекты не в том порядке или goal'ы не в том порядке? Если первое, то правильно прописывайте зависимости. Если второе, то просто не привязывайте к одной фазе два и более goal'a.
Ничто не мешает писать свои плагины к maven (это очень просто). Плюс есть gmaven-plugin/maven-antrun-plugin, в которых можно делать все, что угодно.
>> сборка шла в чуть ином порядке
Проекты не в том порядке или goal'ы не в том порядке? Если первое, то правильно прописывайте зависимости. Если второе, то просто не привязывайте к одной фазе два и более goal'a.
Если я правильно помню ту проблему, то получилось так. Собирали очень большой Flex-проект (виртуальный мир). Всё работало хорошо, но вдруг начиная с какого-то момента сборка на CI-сервере начала содержать некие странные ошибки, в то время как та же сборка, проводимая локально, работала как надо. Как выяснилось, на сервере каким-то образом обновился Maven, и при компиляции проекта он стал указывать библиотеки не в том порядке.
Понятно, что вообще-то проект должен быть нечувствителен к порядку библиотек. Но выяснилась эта проблема на довольно поздней стадии, и время, потраченное на ее диагностику + время на поиск решения мне попортили много крови.
Понятно, что вообще-то проект должен быть нечувствителен к порядку библиотек. Но выяснилась эта проблема на довольно поздней стадии, и время, потраченное на ее диагностику + время на поиск решения мне попортили много крови.
>> компиляции проекта он стал указывать библиотеки не в том порядке
А, понятно. Чтобы такого не происходило, можно использовать maven-enforcer-plugin с опцией dependencyConvergence=true.
А, понятно. Чтобы такого не происходило, можно использовать maven-enforcer-plugin с опцией dependencyConvergence=true.
У меня была схожая проблема с джавой и юнит-тестами. Тест кейс был завязан на имена методов и порядок выполнения был важен. Обновился до 1.7 — тесты валятся, оказалось теперь они выполняются в хаотичном порядке (или сортируются по другим принципам, не помню). Это была моя архитектурная проблема из-за недостатка знаний.
Уверен, картина схожая. Странно, что билд зависит от порядка подключения библиотек.
Уверен, картина схожая. Странно, что билд зависит от порядка подключения библиотек.
Тест кейс был завязан на имена методов и порядок выполнения был важен
…
Это была моя архитектурная проблема из-за недостатка знаний.
Может быть с точки зрения build manager это и была «твоя» проблема. Ибо «не поломать» в принципе важно.
Но на самом деле проблема в том, что полагаться на порядок выполнения юнит-тестов, в корне неправильный подход. Так что тут уже камень в огород разработчиков продукта.
Все верно, но камень именно в мой огород — это был мой pet project и мои юнит тесты :)
почему?
например я могу сперва протестировать один метод на его работу, а потом другой метод, который в себе используется первый.
К примеру (Spring), у меня есть тест testDb2DataSource. И есть тест testDb2Sequence, который выполнится только после testDb2DataSource, потому как, если DataSource не поднимается, то смысл мне тестировать как будет в нём отрабатывать кастомизированный Sequence?
например я могу сперва протестировать один метод на его работу, а потом другой метод, который в себе используется первый.
К примеру (Spring), у меня есть тест testDb2DataSource. И есть тест testDb2Sequence, который выполнится только после testDb2DataSource, потому как, если DataSource не поднимается, то смысл мне тестировать как будет в нём отрабатывать кастомизированный Sequence?
В TestNG решается указанием зависимостей через dependsOnGroups или dependsOnMethods
Это решается независимостью тестовых методов друг от друга. Каждый тест — это должно быть одно логическое действие. И если один метод зависит от результатов выполнения другого метода — это плохой тест кейс.
выше написал пример зависимости. или первоначальная проверка подключения и последующая проверка работы кода для данного подключения плохой тест кейс?..
Да, это плохой тест кейс, полагаться в одном тесте на проверку из другого теста. Каждый тест должен быть выполнен в clean environment. Если смысловая нагрузка конкретного теста в том, что-бы проверить, как чебурашка готовит завтрак, этот тест не должен зависеть от того, как чебурашка проснется. Тест должен быть построен так, что-бы мы гарантированно имели проснувшуюся чебурашку, готовую делать завтрак. Для этого используют Mock объекты. В вашем случае testDb2Sequence должен использовать их, а не результат работы testDb2DataSource.
тогда в каком случае применяется dependsOnMethods/dependsOnGroups? можно на том же примере с Чебурашкой и завтраком? :)
Мы все еще говорим о JUnit? Каждый живет по своим правилам. Методологий тестирования так-же много, как и методологий разработки.
нет, я с самого начала указал, что говорю про TestNG
Но я еще раньше говорил о проблеме в JUnit, а потом вы мне как решение предложили TestNG. Вы всегда решаете архитектурные проблемы сменой платформы на ту, где проблема является вполне нормальным поведением?
разве смена JUnit на TestNG является сменой платформы а не расширением используемой?
лично я считаю, если можно безболезненно заменить одну библиотеку другой и при этом получить доп. функционал, то её можно и даже нужно заменить, чем изобретать «костыли».
вот смена maven на ant+ivy в любом направлении — смена платформы
UPD. ествественно, что смена библиотеки только ради смены мною не приветствуется
лично я считаю, если можно безболезненно заменить одну библиотеку другой и при этом получить доп. функционал, то её можно и даже нужно заменить, чем изобретать «костыли».
вот смена maven на ant+ivy в любом направлении — смена платформы
UPD. ествественно, что смена библиотеки только ради смены мною не приветствуется
В самом начале статьи говориться, что речь в первую очередь о большом интерпрайзе. Тут у нас не будут менять JUnit на TestNG потому что обновили джаву и тесты стали выполняться не в том порядке. Решение обновить джаву обычно принимается ооочень долго и ставиться в backlog так, что бы до релиза осталось куча времени разгребать проблемы. В статье как-раз пища для размышлений, а не призыв срочно менять Ant на Maven. Это совершенно две разные ситуации. Если по каким-либо причинам в проекте был выбран JUnit — надо придерживаться его правил игры, а не менять на TestNG, потому что там обнаружилась одна нужная фича. Переход на TestNG будет долго обсуждаться менеджерами и архитекторами, и тут еще большой вопрос — что быстрее, исправить архитектурные проблемы тест кейсов или дождаться всех аппрувов и переписать тесты с использованием нового фреймворка.
Да, действительно такие ограничения инструмента. Но решить можно многое и даже без собственных плагинов. Не всегда это лаконично, правда
А ещё слёзы наворачиваются видеть файлы проекта под Version Control. Именно возможность открывать помки как описание проекта в той же IDEA обычно делает небывалый фурор, особенно для flexmojos проектов.
А в сторону всегда можно отойти используя Maven Ant Plugin, к слову:)
А в сторону всегда можно отойти используя Maven Ant Plugin, к слову:)
Не думал, что ещё где-то ходят споры ant vs maven, особенно, в контексте крупных проектов. Вроде как все переключились на споры maven vs gradle :). Как-то раз писал build.xml для сборки большого иерархического проекта. Это боль, особенно, управление classpath.
Кастомизация maven не настолько уж сложна. Писал как-то maven-плагин для I10N, который форкал .properties файлы с нужными суффиксами во всех модулях проекта, вставляя заглушки локализации, собирал по всем модулям информацию о ключах и их значениях для всех локалей в сводную Excel-табличку, с которой могли работать переводчики, и позволял автоматически перенести ключи из этой таблички обратно в .properties файлы. Ушло всего несколько дней, при условии моей первоначальной неознакомленности с внутренностями maven.
Генерация проектных файлов для IDE из pom.xml очень радует, правда, IDEA весьма неплохо понимает проекты на ant.
Хотел посмотреть на Gradle, но как-то всё руки не доходят.
Кастомизация maven не настолько уж сложна. Писал как-то maven-плагин для I10N, который форкал .properties файлы с нужными суффиксами во всех модулях проекта, вставляя заглушки локализации, собирал по всем модулям информацию о ключах и их значениях для всех локалей в сводную Excel-табличку, с которой могли работать переводчики, и позволял автоматически перенести ключи из этой таблички обратно в .properties файлы. Ушло всего несколько дней, при условии моей первоначальной неознакомленности с внутренностями maven.
Генерация проектных файлов для IDE из pom.xml очень радует, правда, IDEA весьма неплохо понимает проекты на ant.
Хотел посмотреть на Gradle, но как-то всё руки не доходят.
Gradle, который снова дает нам свободу, чем и завлекает разработчиков. Я впонле ясно написал, чем свобода плоха (с точки зрения инженера Build Factory). Как было сказано в статье, pom.xml — это описание проекта в формате XML. Что мы имеем с Gradle? Groovy, опять ЯП и кучу свободы.
А интеграция как-же? Не забывайте, что размер Maven комьюнити значительно больше Gradle (пока). Но Gradle дает нам свободу дизайнить билд так, как нам нужно, не думая о других командах, и о том, что им может понадобится в этом всем нашем коде разобраться.
А интеграция как-же? Не забывайте, что размер Maven комьюнити значительно больше Gradle (пока). Но Gradle дает нам свободу дизайнить билд так, как нам нужно, не думая о других командах, и о том, что им может понадобится в этом всем нашем коде разобраться.
Вы явно пропустили в чем вся соль в Gradle. Он такой-же деклеративный, как и Maven, это такое же описание проекта (в Groovy). Никто и никогда не советовал пользоваться мощью ЯП для написания логики в билд файле. Вот, Ханс об этом — www.gradleware.com/news/blog/fighting-common-misconception-gradle-isnt-imperative
Тем не менее, отступить от стандарта легко и просто прямо в билд файле, что будет добавлять работы в Build Factory, когда какой то девелопер решит, что он лучше знает. А с мавеном не так просто — надо плагин написать, задеплоить его в соответствующий корпоративный репозиторий (на что права нужны), и так далее. Спорить более подробно я не буду, опыта с Gradle не так много. За ссылку спасибо.
Я понимаю ваш порыв все запретить, чтобы не насрали, но может лучше научить не срать?
Хм, грубо получилось, извините. Ничего личного, надеюсь вы понимаете, что я имею ввиду — давайте учится не вытаптывать газон, а не запрещать на нем отдыхать.
Хм, грубо получилось, извините. Ничего личного, надеюсь вы понимаете, что я имею ввиду — давайте учится не вытаптывать газон, а не запрещать на нем отдыхать.
Я абсолютно согласен с таким подходом. Когда команда ну человек 50 максимум. А когда она разбросана по всему миру, и измеряется тысячами… поди научи.
Ну, вы-ж не один build-nazimaster на них всех. Вот каждый свои 50 и учит. И по рукам за косяки, пока не научатся не срать на газоне (да что-ж такое со мной сегодня!)
Я боюсь, вы не понимаете, насколько быстро растет сложность и падает скорость синхронизации узлов девелопмент-центра с увеличением размера этого центра и введения понятия распределенной разработки. Давайте тогда верстальщиков учить код править так, как им надо? Не дадите? Почему? Ааа, у вас метрики, эстимейты, архитектуру обсудить нужно?
У нас тоже есть свои архитекторы, менеджеры, бэклоги, метрики, лонг-терм гоалы и так далее. Вы думаете, впускать в этот процесс девелоперов хорошо отразиться на общих сроках выполнения задач и метриках? Думаете, девелоперы лучше знать будут, то хорошо для QA и менеджеров? Я думаю, что каждый должен заниматься своим делом. Мы не обслуживающий персонал, призванный ублажать и облегчать жизнь девелоперам, мы такие же девелоперы. И каждый должен делать свою работу.
У нас тоже есть свои архитекторы, менеджеры, бэклоги, метрики, лонг-терм гоалы и так далее. Вы думаете, впускать в этот процесс девелоперов хорошо отразиться на общих сроках выполнения задач и метриках? Думаете, девелоперы лучше знать будут, то хорошо для QA и менеджеров? Я думаю, что каждый должен заниматься своим делом. Мы не обслуживающий персонал, призванный ублажать и облегчать жизнь девелоперам, мы такие же девелоперы. И каждый должен делать свою работу.
Я думаю, я понимаю. И я ни в коем случае не предлагаю вам учить девелоперов писать плагины для Грейдла. Я предлагаю вам учить девелоперов не писать таски в билде.
Но Грейдл все таки ЯП, и это возможно. А запретный плод сладок. И это так искусительно. И если мы не будем тратить 30% рабочего времени на мониторинг и модерирование билд файлов, это будет просто замечательно.
А Мавен своей декларативностью и не-ЯПобразием сразу отбивает все желание самодеяльничать. И тогда в случае необходимости, девелоперы идут к нам. И в большинстве случаев предлагаемое ими решение ущемляет интересы других команд или доменов, и вообще не по фен-шую.
Но ладно, давайте оставим эту тему, я думаю мы друг друга поняли. А как на счет порога вхождения? Мавен — стандарт, найти человека, ориентирующегося в этом стандарте — легко. Грейдл дает нам такой стандарт? Или нам нужно будет придумывать свою архитектуру процесса сборки, а потом каждого новенького кроме всего прочего еще и обучать нашей архитектуре и конвеншнам?
А Мавен своей декларативностью и не-ЯПобразием сразу отбивает все желание самодеяльничать. И тогда в случае необходимости, девелоперы идут к нам. И в большинстве случаев предлагаемое ими решение ущемляет интересы других команд или доменов, и вообще не по фен-шую.
Но ладно, давайте оставим эту тему, я думаю мы друг друга поняли. А как на счет порога вхождения? Мавен — стандарт, найти человека, ориентирующегося в этом стандарте — легко. Грейдл дает нам такой стандарт? Или нам нужно будет придумывать свою архитектуру процесса сборки, а потом каждого новенького кроме всего прочего еще и обучать нашей архитектуре и конвеншнам?
Мавен не был стандартом всегда, правда? Переход на Мавен с Анта был намного более болезненным, чем переход с Мавена на Грейдл (конвенции те-же, как структуры проекта, так и артифактов, зависимостей и репозиториев).
Под стандартом я имел ввиду конвеншны — четкий стандартный лайф цайкл, и тому подобные вещи, которые мавен нам диктует. Грейдл диктует то-же самое, но в то же время, пожалуйста, пишите код в конфигурационном файле билда. Не похоже ли это на бронированную дверь посреди поля, без стены и так далее? Хочешь — воспользуйся ключем и пройди в дверь. Нет — сделай шаг в лево и обойди ее.
Я думаю, что проблема в том, что вы рассматриваете билд как сейф, который надо закрывать бронированной дверью. А я — как газон, на котором все приглашаются отдохнуть.
Ну, да ладно. Пусть цветут сто цветов, Мавен никуда не уходит, хотя я думаю, что процентов 70 рынка потеряет Грейдлу в ближайшие два года.
Ну, да ладно. Пусть цветут сто цветов, Мавен никуда не уходит, хотя я думаю, что процентов 70 рынка потеряет Грейдлу в ближайшие два года.
и в с помощью Maven можно неплохо «насрать» в проекте даже с теми плагинами, что есть в репозитарии. факт.
В предыдущей ветке читайте, про отбивание желания декларативностью и т.д.
читал.
но вот пример, с которым столкнулся.
с помощью jaxb2-maven-plugin генерится source коды, нужные только на этапе сборки. «по дефолту» генерятся в src/main/java. в итоге, их генерация «рушит» success для checkstyle-плагина — приходится для этих пакетов/классов прописывать ignore-списки
решил путём «донастройки» aspect-плагина на генерацию в target/generated-sources/jaxb + добавил плагин build-helper-maven-plugin, который «натравил» (add-source) на эту директорию.
и где тут декларативность нарушена/отсутствует?
но вот пример, с которым столкнулся.
с помощью jaxb2-maven-plugin генерится source коды, нужные только на этапе сборки. «по дефолту» генерятся в src/main/java. в итоге, их генерация «рушит» success для checkstyle-плагина — приходится для этих пакетов/классов прописывать ignore-списки
решил путём «донастройки» aspect-плагина на генерацию в target/generated-sources/jaxb + добавил плагин build-helper-maven-plugin, который «натравил» (add-source) на эту директорию.
и где тут декларативность нарушена/отсутствует?
FIX: jaxb2-maven-plugin «по дефолту» генерит всё правильно — в target/generated-sources/jaxb — просто «кто-то» переопределял outputDirectory на неправильный путь.
Чего реально не хватает — это аналога sbt/gradle над maven а не над ivy. Ибо xml описание достаточно убого и многословно, в том же sbt всё указывается понятнее и красивее, но при этом суть мавена мне кажется правильной — программировать для сборки не нужно.
Как не хватает? Берете polyglot-maven, и вперед. А, он же умер, не родившись? Ну, это потому что фреймворкит не вылечишь, заменив язык дескриптора.
Ух ты, даже не знал про этот проект, спасибо за просвещение. А в чём, по вашему мнению, заключается фреймворкит мавена?
Ну, прям по книжке — безумно легко начать делать стандартные вещи, страшно больно делать что-то не by the book. В какой-то момент, когда переходишь от обязательных вещей (компилятция, сборка джара) к желательным (генерация документации, проверка валидности примеров в документации, нестандартные релизы, и т.д.), решаешь, что ну его нафиг, игра не стоит свеч. В итоге автоматизация проекта страдает, вместо того, чтобы выигрывать из-за использования фреймворка.
Странно, у меня ровно обратное ощущение от мавена. Нужна докуменация? Джавадок-плагин. Не подходид джавадок, нужен доксиджен — доксиджен плагин. Нужно копировать файлы на ftp? antrunner и копипаста антовского таска в три строки. Про проверку примеров в документации — это я вообще плохо понимаю о чём речь — если о поддержке документации в актуальном состоянии, то не знаю, как это вообще можно автоматизировать. Однако если можно через ант и нельзя через мавен — то на то есть антраннер, опять-таки. Нестандартные релизы — тоже не очень понятно что такое. Если имеются ввиду релизы под разные платформы — то на то профили есть… Мне ровно один раз за последние 5 лет пришлось что-то реально писать для того, чтобы мавен заработал — генератор экслипсовских фич. Но такой штуки не умела ни одна билд-система делать и, видать, никому оно не надо…
Ну, если вы спустили с цепи antrunner, то вы пытаетесь вылечить фреймворкит. Вы-ж понимаете, antrunner это бэкдор, который ломает всю идеологию Мавена, и от души насыпает imperative в ваш declarative. Проблема в том, что поскольку этого никто не ожидал, никаких заготовок под эти порции имератива нет, и начинается ад — императивный код в xml-е.
Конкретно по моим примерам:
В моих доках есть примеры кода (это тесты). Мне нужно, чтобы при сборке документации, этот код выполнялся, а то вдруг мы чего сломали, а потом попадал в доки.
Нестандартные релизы — превращение снапшотов в релизы без пересборки, например. Нестандартные схемы версий. ЧуднЫе операции над сорц-контролем во время релизов. Да мало-ли? Все, о чем не подумали Джейсон и компания.
Конкретно по моим примерам:
В моих доках есть примеры кода (это тесты). Мне нужно, чтобы при сборке документации, этот код выполнялся, а то вдруг мы чего сломали, а потом попадал в доки.
Нестандартные релизы — превращение снапшотов в релизы без пересборки, например. Нестандартные схемы версий. ЧуднЫе операции над сорц-контролем во время релизов. Да мало-ли? Все, о чем не подумали Джейсон и компания.
Все описанные проблемы легко решаются своим кастомным кодом — плагинами. И мне кажется, гораздо безопаснее написать свой плагин и объявить его декларативно, чем начать творить магию прямо в конфигурации билда.
Тут у нас с вами полный концензус, никто и не предлагает творить магию в конфигурации билда Грейдла.
По плагинам — к сожалению, из-за зашоренности Мавена возможности плагина весьма ограничены, и легкость их написания, как бы так сказать, ее нет. Вот прямо нынче я пишу совсем нетревиальный плагин для Мавена, аналог нашего плагина для Грейдла, так вот это земля и небо, день и ночь и ад и Израиль.
По плагинам — к сожалению, из-за зашоренности Мавена возможности плагина весьма ограничены, и легкость их написания, как бы так сказать, ее нет. Вот прямо нынче я пишу совсем нетревиальный плагин для Мавена, аналог нашего плагина для Грейдла, так вот это земля и небо, день и ночь и ад и Израиль.
Чем же плагины ограничены? Это обычный джава код, все ограничение составляет JVM. И писать, как по мне, вовсе не сложно. Да, понимаю, на Градле легче, но в соседнем топике мы с вами это уже обсуждаем…
Ограничения составляет вовсе не JVM а контейнер впрыскивания зависимостей (ох, блин). Если я не могу в моем плагине использовать другой плагин (сконфигурированый в том-же билде), то эта система плагинов — ацтой.
Ну почему? Если вы о переиспользовании кода, то пожалуйста, сделайте этот код отдельным артифактом и подтягивайте зависимостью в оба плагина. Если вы о прямом, кхм, использовании одного плагина в другом… но это же в корне нарушает всю идею жизненного цикла. Я вижу в этой изолированности только фичу. К тому-же, засериализовать в target директорию какой-то xml всегда можно, что бы потом оттуда прочитать, в том-же билде.
Вот это фреймворкит в лучшем виде — вы (как пример идеолога Мавена) еще не знаете, что именно я хочу сделать с этими плагинами, но уже запретили. Разве посмотреть как они пробежали и что сделали из другого плагина каким-то образом противоречит изоляции? Я не собираюсь их вызывать, не собираюсь менять драгоценный цикл, все что мне нужно, это собрать информацию. Но нет, нельзя!
К тому-же, засериализовать в target директорию какой-то xml всегда можно, что бы потом оттуда прочитать, в том-же билде.
Я когда вот такое вижу, вспоминаю эпизод из советского детства. Стоял я как-то три дня в очереди за чемоданами, и когда их наконец завезли, объявили, что будут давать по одному в руки. Какой-то мужик очень громко этим возмущался (благо уже можно было), а я недоумевал — «чего это он? Ведь так просто — приедет вся семья, и каждому по одному в руки!»
Это я к тому, что фреймворк, в котором такие костыли являются нормой, обречен.
К тому-же, засериализовать в target директорию какой-то xml всегда можно, что бы потом оттуда прочитать, в том-же билде.
Я когда вот такое вижу, вспоминаю эпизод из советского детства. Стоял я как-то три дня в очереди за чемоданами, и когда их наконец завезли, объявили, что будут давать по одному в руки. Какой-то мужик очень громко этим возмущался (благо уже можно было), а я недоумевал — «чего это он? Ведь так просто — приедет вся семья, и каждому по одному в руки!»
Это я к тому, что фреймворк, в котором такие костыли являются нормой, обречен.
Да, противоречит. Опять про дверь в поле…
С xml в target, я и не говорил, что это изящное решение. Я просто сказал, что это возможно, если очень хочется. А вообще, если хочется чего-нибудь такого, нужно остановиться, оглянуться, и подумать еще раз. Скорее всего вы собрались делать что-то не правильно.
С xml в target, я и не говорил, что это изящное решение. Я просто сказал, что это возможно, если очень хочется. А вообще, если хочется чего-нибудь такого, нужно остановиться, оглянуться, и подумать еще раз. Скорее всего вы собрались делать что-то не правильно.
Да я с удовольствием оглянуться. Подскажите мне the Maven way.
Итак, я хочу atomic deploys в multi-module билде. Чтобы все артифакты деплоились не после каждого модуля, а в конце всего билда.
Слушаю ваше решение.
Итак, я хочу atomic deploys в multi-module билде. Чтобы все артифакты деплоились не после каждого модуля, а в конце всего билда.
Слушаю ваше решение.
я с maven мало, но решение в виде основное направление — сборка и отдельный профиль на деплой?
не понял, если честно. Можно по-подробней?
т.е. основной запуск это package, а с подключением профиля «deploy-all» выполнять только deploy уже готовых пакетов, пропуская test/package этапы.
лично у меня отдельные профили на deploy библиотек, deploy/redeploy приложения. запускаю либо по одному профилю, либо сразу оба (не считая профилей, в которых только properties для нужных серверов)
либо я не так вас понимаю.
лично у меня отдельные профили на deploy библиотек, deploy/redeploy приложения. запускаю либо по одному профилю, либо сразу оба (не считая профилей, в которых только properties для нужных серверов)
либо я не так вас понимаю.
Deploy конечно в таком случае не запустит сборку заного, но некоторые фазы все таки будут выполнены повторно.
О, поздравляю, именно такую задачу я и решал недавно, генерируя xml в target, потом его оттуда читая и используя deploy-file. Пришлось. Но по хорошему, да, это не maven way в корне. Модули проекта должны быть самостоятельны. Неудачная сборка кого-го то одного модуля не должна препятствовать деплю остальных успешных модулей.
О, поздравляю, именно такую задачу я и решал недавно, генерируя xml в target, потом его оттуда читая и используя deploy-file
Боже мой, мне это читать даже больно! Вы считаете, что build tool который вас заставляет писать такие адские костыли это как раз тот фреймворк, с которым вы хотите работать?
И делается это не так, а подавлением deploy плагина.. Но все равно, все через жопу, все ужасно, все больно. Не хочу.
Неудачная сборка кого-го то одного модуля не должна препятствовать деплю остальных успешных модулей.
Вот это вообще странное заявление. Например, у меня есть 2 модуля — backend и ui. Backend прошел и задеплоился, UI упал. Чего мне делать с джаром backend-а?
Боже мой, мне это читать даже больно! Вы считаете, что build tool который вас заставляет писать такие адские костыли это как раз тот фреймворк, с которым вы хотите работать?
И делается это не так, а подавлением deploy плагина.. Но все равно, все через жопу, все ужасно, все больно. Не хочу.
Неудачная сборка кого-го то одного модуля не должна препятствовать деплю остальных успешных модулей.
Вот это вообще странное заявление. Например, у меня есть 2 модуля — backend и ui. Backend прошел и задеплоился, UI упал. Чего мне делать с джаром backend-а?
Вообще-то это менеджеры заставляют меня писать такие адские костыли. Они считают, что повторный validation pom.xml — это часть нового билда. Была бы моя воля, я бы не писал такие адские костыли, а сделал так, как предлагает Borz. Это и есть настоящее правильное решение.
а, то есть запускать один и тот-же билд 3 раза, что-бы получить atomic deploy — это и есть правильное решение. Ого.
Ну почему один и тот-же билд? Если это один и тот-же конфигурационный файл билда, но разные фазы\гоалы\профили — это по вашему один и тот же билд?
Чего мне делать с джаром backend-а?
Ничего. Он успешен. Занавес, всем спасибо, все свободны. Продолжаем итерацию\спринт или что у вас там.
Ничего. Он успешен. Занавес, всем спасибо, все свободны. Продолжаем итерацию\спринт или что у вас там.
Он успешен, но бесполезен. Я собираю продукт, а не абстрактные джары в вакууме. Jar backend-a без ui-a — мусор. Зачем мне мусор в репозитории?
Это не мусор, это билд N#100500 модуля foobar. С тем же успехом можно говорить, я собираю продукт для релиза, зачем мне его собирать каждый час\каждую ночь — мусор в дженкинсе, в репозитории итд.
У меня нет билда модуля. У меня есть билд проекта. Сами модули не имеют смысла, потому что они оба часть одного реактора. Это значит, что они зависят от сорцев, а не от джара. Джар в данном случае — бесполезный мусор, потому что он не часть продукта (продукт не собрался), и никто от него не зависит (UI зависит от сорцев, а не от джара, ибо они в одном реакторе).
Либо вы не понимаете смысл разделения на модули, либо у вас на модули продукт разделен от балды, либо и то и другое вместе. Модуль — это логическая еденица продукта. Я уже молчу о том, что успех\падение билда этого модуля может фигурировать в каких-либо метриках команды, которая занимается этим модулем. Но как-же дебаг? Вдруг кому-то понадобится именно этой версии модуль для воспроизведения какого-то хитрого сценария?
Давайте сначала тогда. В чем разница между двумя проектами, которые друг от друга зависят, и двумя модулями, прописанными в одном реакторе?
Уровнем абстракции. Зависит от того, что вы разрабатываете — фреймворк, библиотеку, или продукт. Один единственный модуль вашего продукта А может точно так-же подтягиваться как зависимость к совершенно другому продукту Б в компании. И как мы нарушаем метрику и цикл разработки этого другого продукта Б, если вдруг билд этого модуля в продукте А был успешен, но не задеплоен, потому что atomic deploy мы так любим?
Ну и прекрасно. Давайте теперь возьмем пример, при котором зависимость от сорцев (реактор) а не от джара. Такое вообще кошерно, или использовать multi-module maven build это не maven-way?
И в чем разница то? Билд 9 из 10 модулей в продукте — успешен, и эти 9 модулей должны быть задеплоены. Билд самого продукта завален. Вот и все. Тот же дженкинс умеет видеть модули в продукте по отдельности, анализировать метрики по отдельности, даже мейлы слать на каждый модуль отдельно. Реактор — всего лишь агрегатор, который объединяет в один билд несколько модулей. Но он не меняет концепцию.
Реактор — всего лишь агрегатор, который объединяет в один билд несколько модулей. Но он не меняет концепцию.
Вот это да. Слона то вы и не заметили. Самая главная фича реактора — зависимость от сорцев, а не от джаров! Это меняет все. Это совершенно другой уровень coupling-а. Если при разработке отдельных проектов, каждый джар этих проектов является самостоятельной единицей, со своей версией и со своим release cycle, то при зависимости от сорцев (в реакторе), джары каждого модуля имеют значение только в случае, если все они построились. Иначе — они бесполезны, потому что другие модули от них (от джаров) не зависят.
эти 9 модулей должны быть задеплоены
Зачем? Что с ними делать? От них нельзя зависеть, и они не часть продукта.
Тот же дженкинс умеет видеть модули в продукте по отдельности, анализировать метрики по отдельности, даже мейлы слать на каждый модуль отдельно.
Я-ж не говорю не прогонять репорты и не посылать мейлы на каждый модуль. Я говорю — не деплоить его в отдельности в репозиторий, потому что он там бесполезен (см. выше).
Вот это да. Слона то вы и не заметили. Самая главная фича реактора — зависимость от сорцев, а не от джаров! Это меняет все. Это совершенно другой уровень coupling-а. Если при разработке отдельных проектов, каждый джар этих проектов является самостоятельной единицей, со своей версией и со своим release cycle, то при зависимости от сорцев (в реакторе), джары каждого модуля имеют значение только в случае, если все они построились. Иначе — они бесполезны, потому что другие модули от них (от джаров) не зависят.
эти 9 модулей должны быть задеплоены
Зачем? Что с ними делать? От них нельзя зависеть, и они не часть продукта.
Тот же дженкинс умеет видеть модули в продукте по отдельности, анализировать метрики по отдельности, даже мейлы слать на каждый модуль отдельно.
Я-ж не говорю не прогонять репорты и не посылать мейлы на каждый модуль. Я говорю — не деплоить его в отдельности в репозиторий, потому что он там бесполезен (см. выше).
А я вам скажу, что вы не правы. Джары не бесполезны. Это фича реализации реактора, которую можно и нужно использовать в билде продукта. Но с чего вы взяли, что модуль продукта, этот один из десяти, не может быть использован в другом продукте? Да даже его отдельный классифайр может быть использован. Может, и точка. В этом модуле может быть набор интерфейсов, который используется как API в другом продукте для интеграции с первым. Просто пример.
ну так сделайте так:
1) модуль app
2) подмодуль backend для модуля app
3) подмодуль frontend для модуля app
делайте сборку и deploy для app. При этом процедуру deploy-я опишите в app-модуле и будет вам счастие — app не дойдёт до deploy если не выполнится сборка любого из его дочерних модулей.
1) модуль app
2) подмодуль backend для модуля app
3) подмодуль frontend для модуля app
делайте сборку и deploy для app. При этом процедуру deploy-я опишите в app-модуле и будет вам счастие — app не дойдёт до deploy если не выполнится сборка любого из его дочерних модулей.
Не, антраннер это вариант для тех ленивых, которые не хотят написать свой плагин и предпочитают использовать готовый и протестированный код.
Насчёт ваших примеров — не мне судить, но безусловно, мавен, в отличие от анта, предназначен для стандартизации а не наоборот. Зачем что-то делать без пересборки? релизами же должен заниматься CI сервер, а не разработчики. Для тестов есть surefire, который, обратно же, должен запускаться на билдсервере. Многие, в том числе я, считают, что код в комментариях зло. И вообще, меньше комментариев — лучше, ибо код должен быть самодокументирующимся. Конечно, я ничего не знаю про ваш проект и может быть вам и правда всё это не подходит — тогда, увы, мавен и правда не для вас. Но я всё-таки думаю, что лучше, наверное, написать пару свои можо, хоть с анта их перекатать и использовать мавен.
Насчёт ваших примеров — не мне судить, но безусловно, мавен, в отличие от анта, предназначен для стандартизации а не наоборот. Зачем что-то делать без пересборки? релизами же должен заниматься CI сервер, а не разработчики. Для тестов есть surefire, который, обратно же, должен запускаться на билдсервере. Многие, в том числе я, считают, что код в комментариях зло. И вообще, меньше комментариев — лучше, ибо код должен быть самодокументирующимся. Конечно, я ничего не знаю про ваш проект и может быть вам и правда всё это не подходит — тогда, увы, мавен и правда не для вас. Но я всё-таки думаю, что лучше, наверное, написать пару свои можо, хоть с анта их перекатать и использовать мавен.
Сравнение последних версий инструментов по общему размеру бинарного кода в их каталогах:
apache-ant-1.9.2 — 35,6 МиБ
apache-maven-3.1.1 — 6,2 МиБ
gradle-1.10 — 43,4 МиБ
apache-ant-1.9.2 — 35,6 МиБ
apache-maven-3.1.1 — 6,2 МиБ
gradle-1.10 — 43,4 МиБ
О чем может говорить такое сравнение? Особенно учитывая, что мавен сам по себе всего-лишь сердце, и ничего делать не умеет, все даже стандартные вещи вроде компиляции и упаковки jar совершаются с помощью плагинов.
Размер бинарников, как правило, говорит об изначально заложенной функциональности и некоей самодостаточности. Правда, в ходе эксплуатации функциональность инструмента может повышаться самостоятельно (Maven, Gradle) или оставаться на том же уровне с вручную подложенными библиотеками и плагинами (Ant).
Да ни о чем не говорит изначальный размер бинарников. Плохая метрика, абсолютно не учитываяющая особенности архитектуры тех или иных приложений. Все равно, что сравнивать два продукта по размеру инсталлятора, когда у одного из продуктов инсталлятор сетевой — весит пол мегабайта и качает контент по сети.
не показатель.
тот же Maven одних только плагинов для работы потом ещё минимум мегабайт на 20 выкачает после первого запуска.
тот же Maven одних только плагинов для работы потом ещё минимум мегабайт на 20 выкачает после первого запуска.
Sign up to leave a comment.
Ant + Ivy VS Maven: давайте жить дружно