Как я могу использовать Maven для автоматизации нескольких сборок?
Мне нужно управлять несколькими проектами, такими как A1..A5 и B1..B3. Каждый из B зависит от определенного набора As. Таким образом, я могу запускать maven вручную на каждом A, затем на каждом B, чтобы создавать все банки. Запуск Maven в одном из B даже не приведет к предварительной компиляции требуемого As.
Есть ли какое-нибудь решение сделать это только с Maven без дополнительных инструментов, таких как сценарии оболочки или Ant?
И просто для предотвращения ответов типа «переместить папку A в папку B»: все папки находятся в одном каталоге на одном уровне. Это не может быть изменено, потому что над этими проектами работают разные команды, и каждый проект имеет свой собственный репозиторий GIT.
Вы должны использовать такой инструмент, как Jenkins, чтобы сначала построить восходящие зависимости (все A), а затем построить нисходящие зависимости. Вы пытаетесь автоматизировать CI / CD с помощью Maven, что не является вариантом использования Maven.
Если вы можете разделить все A и B, вы можете использовать их как модули. И иметь один родительский пом. Сборка родительского помпона также построит все детские помпы.
Jenkins и TeamCity позволяют настроить сборку таким образом, что, если какая-либо из зависимостей перестраивается, сборка для зависимого проекта запускается автоматически.
Не очень понятно, чего вы хотите. Хотите собрать все в одной команде? Или любой B с автоматической перекомпиляцией всех необходимых As, или B без перекомпиляции As (с использованием последней успешной сборки ..)?
Я должен создать файл WAR для каждого B, который также включает некоторые из A-jar. Например. B1 включает A1 и A2, а B2 включает A2 и A3.
Ответы 2
Вы можете заставить его работать так:
- создать «сборку агрегатора»: проект POM, в котором отдельные проекты A1 ... A5 и B1 ... B3 перечислены как
<modules>, зарегистрированные в отдельном репозитории git. - в этом репозитории git настройте подмодули git, которые указывают на другие репозитории
При запуске сборки в проекте агрегатора Maven автоматически определит правильный порядок сборки на основе зависимостей включенных проектов.
Например, учитывая следующие зависимости:
B1 uses A1 and A2
B2 uses A2 and A3
B3 uses A3, A4 and A5
Maven может предложить порядок сборки A1, A2, B1, A3, B2, A4, A5, B3.
Используя параметры командной строки Maven, сборку агрегатора можно даже запустить как «перестроить A3 и все, что его использует» или «перестроить все необходимое для B1, а затем для самого B1».
Однако все это может потребовать, чтобы отдельные проекты унаследовали от агрегатора POM, что может или не может быть осуществимо в вашей ситуации в зависимости от того, как выглядят ваши POM.
Структура каталогов может выглядеть так:
Звучит многообещающе. Итак, у меня есть папка "aggregate", которая содержит только pom.xml. Как он должен выглядеть, чтобы строить цели из других проектов? В моей ситуации должно быть возможно, что все As и B наследуются от этого агрегатора pom, но не могут наследовать между ними.
Если я правильно понимаю ваш вопрос, это будет так же просто, как вызвать mvn <goals and parameters go here> в каталоге aggregator. Затем Maven определит порядок сборки и выполнит заданные цели для всех проектов, которые являются модулями сборки агрегатора.
Привет, Йенс. Не могли бы вы привести небольшой пример? У меня есть несколько проектов микросервисов (назовем их от A1 до An). Все они используют некоторые (очень немногие) общие службы. Я поместил их в проект B1. B1 также содержит закрытый ключ, используемый для аутентификации JWT. Но ключ должен быть в наличии в каждом топоре. Любые идеи?
B1 (с названием, например, «микросервисы») должен иметь <packaging>pom</packaging> и список <modules>, который я упомянул в своем ответе. Он не создаст файл JAR, поэтому ваш закрытый ключ аутентификации JWT должен находиться в отдельном проекте C1 (с названием, например, «общий» или «общий»). Затем в pom B1 добавьте зависимость к C1. Поскольку каждый микросервис Axe наследуется от pom B1, он также получает эту зависимость. Наконец, вам следует добавить еще один проект R1 (с именем, например, «root»), также с упаковкой pom, который действует как агрегатор для своих modules B1 и C1. R1 находится в корне структуры каталогов вашего проекта.
Обратите внимание, что жесткое кодирование закрытого ключа в исходниках вашего проекта звучит как плохая идея, но это тема для другого поста.
Если As и B действительно являются разными проектами, вам понадобится какой-нибудь другой инструмент, например Jenkins, для управления и оркестровки ваших сборок. В частности, вы будете делать независимые выпуски As и B, поэтому вам нужно, чтобы сборки Maven оставались независимыми.
Нет, не думаю. Вам понадобится еще один инструмент.