Реактор — всего лишь агрегатор, который объединяет в один билд несколько модулей. Но он не меняет концепцию.
Вот это да. Слона то вы и не заметили. Самая главная фича реактора — зависимость от сорцев, а не от джаров! Это меняет все. Это совершенно другой уровень coupling-а. Если при разработке отдельных проектов, каждый джар этих проектов является самостоятельной единицей, со своей версией и со своим release cycle, то при зависимости от сорцев (в реакторе), джары каждого модуля имеют значение только в случае, если все они построились. Иначе — они бесполезны, потому что другие модули от них (от джаров) не зависят.
эти 9 модулей должны быть задеплоены
Зачем? Что с ними делать? От них нельзя зависеть, и они не часть продукта.
Тот же дженкинс умеет видеть модули в продукте по отдельности, анализировать метрики по отдельности, даже мейлы слать на каждый модуль отдельно.
Я-ж не говорю не прогонять репорты и не посылать мейлы на каждый модуль. Я говорю — не деплоить его в отдельности в репозиторий, потому что он там бесполезен (см. выше).
Ну и прекрасно. Давайте теперь возьмем пример, при котором зависимость от сорцев (реактор) а не от джара. Такое вообще кошерно, или использовать multi-module maven build это не maven-way?
Так это-ж не разные. Есть lifecycle, который я люблю. package, install, deploy. Одного и того-же проекта. Т.е. один билд. Я и хочу запустить его один раз, и получить atomic deploy (последний этап в lifecycle, который включает в себя все остальные). Могу, нет?
У меня нет билда модуля. У меня есть билд проекта. Сами модули не имеют смысла, потому что они оба часть одного реактора. Это значит, что они зависят от сорцев, а не от джара. Джар в данном случае — бесполезный мусор, потому что он не часть продукта (продукт не собрался), и никто от него не зависит (UI зависит от сорцев, а не от джара, ибо они в одном реакторе).
О, поздравляю, именно такую задачу я и решал недавно, генерируя xml в target, потом его оттуда читая и используя deploy-file
Боже мой, мне это читать даже больно! Вы считаете, что build tool который вас заставляет писать такие адские костыли это как раз тот фреймворк, с которым вы хотите работать?
И делается это не так, а подавлением deploy плагина.. Но все равно, все через жопу, все ужасно, все больно. Не хочу.
Неудачная сборка кого-го то одного модуля не должна препятствовать деплю остальных успешных модулей.
Вот это вообще странное заявление. Например, у меня есть 2 модуля — backend и ui. Backend прошел и задеплоился, UI упал. Чего мне делать с джаром backend-а?
ну вот у меня есть Jenkins, например, в котором я хочу чтобы снепшоты строились, и деплоились в Artifactory, только если все модули прошли. Как мне это сконфигурировать?
Да я с удовольствием оглянуться. Подскажите мне the Maven way.
Итак, я хочу atomic deploys в multi-module билде. Чтобы все артифакты деплоились не после каждого модуля, а в конце всего билда.
Слушаю ваше решение.
Вот это фреймворкит в лучшем виде — вы (как пример идеолога Мавена) еще не знаете, что именно я хочу сделать с этими плагинами, но уже запретили. Разве посмотреть как они пробежали и что сделали из другого плагина каким-то образом противоречит изоляции? Я не собираюсь их вызывать, не собираюсь менять драгоценный цикл, все что мне нужно, это собрать информацию. Но нет, нельзя!
К тому-же, засериализовать в target директорию какой-то xml всегда можно, что бы потом оттуда прочитать, в том-же билде.
Я когда вот такое вижу, вспоминаю эпизод из советского детства. Стоял я как-то три дня в очереди за чемоданами, и когда их наконец завезли, объявили, что будут давать по одному в руки. Какой-то мужик очень громко этим возмущался (благо уже можно было), а я недоумевал — «чего это он? Ведь так просто — приедет вся семья, и каждому по одному в руки!»
Это я к тому, что фреймворк, в котором такие костыли являются нормой, обречен.
Я думаю, что проблема в том, что вы рассматриваете билд как сейф, который надо закрывать бронированной дверью. А я — как газон, на котором все приглашаются отдохнуть.
Ну, да ладно. Пусть цветут сто цветов, Мавен никуда не уходит, хотя я думаю, что процентов 70 рынка потеряет Грейдлу в ближайшие два года.
Ограничения составляет вовсе не JVM а контейнер впрыскивания зависимостей (ох, блин). Если я не могу в моем плагине использовать другой плагин (сконфигурированый в том-же билде), то эта система плагинов — ацтой.
Тут у нас с вами полный концензус, никто и не предлагает творить магию в конфигурации билда Грейдла.
По плагинам — к сожалению, из-за зашоренности Мавена возможности плагина весьма ограничены, и легкость их написания, как бы так сказать, ее нет. Вот прямо нынче я пишу совсем нетревиальный плагин для Мавена, аналог нашего плагина для Грейдла, так вот это земля и небо, день и ночь и ад и Израиль.
Мавен не был стандартом всегда, правда? Переход на Мавен с Анта был намного более болезненным, чем переход с Мавена на Грейдл (конвенции те-же, как структуры проекта, так и артифактов, зависимостей и репозиториев).
Я думаю, я понимаю. И я ни в коем случае не предлагаю вам учить девелоперов писать плагины для Грейдла. Я предлагаю вам учить девелоперов не писать таски в билде.
Ну, если вы спустили с цепи antrunner, то вы пытаетесь вылечить фреймворкит. Вы-ж понимаете, antrunner это бэкдор, который ломает всю идеологию Мавена, и от души насыпает imperative в ваш declarative. Проблема в том, что поскольку этого никто не ожидал, никаких заготовок под эти порции имератива нет, и начинается ад — императивный код в xml-е.
Конкретно по моим примерам:
В моих доках есть примеры кода (это тесты). Мне нужно, чтобы при сборке документации, этот код выполнялся, а то вдруг мы чего сломали, а потом попадал в доки.
Нестандартные релизы — превращение снапшотов в релизы без пересборки, например. Нестандартные схемы версий. ЧуднЫе операции над сорц-контролем во время релизов. Да мало-ли? Все, о чем не подумали Джейсон и компания.
Ну, вы-ж не один build-nazimaster на них всех. Вот каждый свои 50 и учит. И по рукам за косяки, пока не научатся не срать на газоне (да что-ж такое со мной сегодня!)
Вот это да. Слона то вы и не заметили. Самая главная фича реактора — зависимость от сорцев, а не от джаров! Это меняет все. Это совершенно другой уровень coupling-а. Если при разработке отдельных проектов, каждый джар этих проектов является самостоятельной единицей, со своей версией и со своим release cycle, то при зависимости от сорцев (в реакторе), джары каждого модуля имеют значение только в случае, если все они построились. Иначе — они бесполезны, потому что другие модули от них (от джаров) не зависят.
эти 9 модулей должны быть задеплоены
Зачем? Что с ними делать? От них нельзя зависеть, и они не часть продукта.
Тот же дженкинс умеет видеть модули в продукте по отдельности, анализировать метрики по отдельности, даже мейлы слать на каждый модуль отдельно.
Я-ж не говорю не прогонять репорты и не посылать мейлы на каждый модуль. Я говорю — не деплоить его в отдельности в репозиторий, потому что он там бесполезен (см. выше).
Боже мой, мне это читать даже больно! Вы считаете, что build tool который вас заставляет писать такие адские костыли это как раз тот фреймворк, с которым вы хотите работать?
И делается это не так, а подавлением deploy плагина.. Но все равно, все через жопу, все ужасно, все больно. Не хочу.
Неудачная сборка кого-го то одного модуля не должна препятствовать деплю остальных успешных модулей.
Вот это вообще странное заявление. Например, у меня есть 2 модуля — backend и ui. Backend прошел и задеплоился, UI упал. Чего мне делать с джаром backend-а?
Итак, я хочу atomic deploys в multi-module билде. Чтобы все артифакты деплоились не после каждого модуля, а в конце всего билда.
Слушаю ваше решение.
К тому-же, засериализовать в target директорию какой-то xml всегда можно, что бы потом оттуда прочитать, в том-же билде.
Я когда вот такое вижу, вспоминаю эпизод из советского детства. Стоял я как-то три дня в очереди за чемоданами, и когда их наконец завезли, объявили, что будут давать по одному в руки. Какой-то мужик очень громко этим возмущался (благо уже можно было), а я недоумевал — «чего это он? Ведь так просто — приедет вся семья, и каждому по одному в руки!»
Это я к тому, что фреймворк, в котором такие костыли являются нормой, обречен.
Ну, да ладно. Пусть цветут сто цветов, Мавен никуда не уходит, хотя я думаю, что процентов 70 рынка потеряет Грейдлу в ближайшие два года.
По плагинам — к сожалению, из-за зашоренности Мавена возможности плагина весьма ограничены, и легкость их написания, как бы так сказать, ее нет. Вот прямо нынче я пишу совсем нетревиальный плагин для Мавена, аналог нашего плагина для Грейдла, так вот это земля и небо, день и ночь и ад и Израиль.
Конкретно по моим примерам:
В моих доках есть примеры кода (это тесты). Мне нужно, чтобы при сборке документации, этот код выполнялся, а то вдруг мы чего сломали, а потом попадал в доки.
Нестандартные релизы — превращение снапшотов в релизы без пересборки, например. Нестандартные схемы версий. ЧуднЫе операции над сорц-контролем во время релизов. Да мало-ли? Все, о чем не подумали Джейсон и компания.
nazimaster на них всех. Вот каждый свои 50 и учит. И по рукам за косяки, пока не научатся не срать на газоне (да что-ж такое со мной сегодня!)