Я пытаюсь организовать свой проект maven.
Допустим, мой проект называется "потрясающим".У «awesome» есть несколько артефактов, каждый из которых собран по-разному (например, некоторые из них могут быть построены с помощью какого-либо плагина, другие построены с некоторыми другими плагинами): в общем, эти конфигурации сборки конечны и ограничены (скажем, есть вбольшинство 3 различных способов создания артефакта), однако каждый артефакт может быть построен только с одной сборкой (например, артефакт utility создается с настройкой maven-jar-plugin определенным образом, в то время как артефакт client-ui создаетсяс maven-war-plugin, настроенным определенным образом).
Теперь я знаю, что мог бы организовать проект maven следующим образом:
awesome-root
|---jars
| |--- utility
| |--- client-model
| |--- task-model
| |--- supplier-model
| |--- client-logic
| |--- task-logic
| ---- supplier-logic
|---wars
|--- client-ui
|--- task-ui
---- supplier-ui
Таким образом, каждая конкретная сборка конфигурации может быть помещена внутрьраздел build --> plugins проектов jars и wars, в то время как общие свойства / управление зависимостями / управление подключаемыми модулями можно поместить в awesome-root.
Проблема: Я быстро понялчто разработчики генерируют артефакты, тесно связанные друг с другом, но с разными сборками.В предыдущем примере мы можем заметить, что артефакты можно сгруппировать другим способом:
awesome-root
|--- tasks
| |--- task-model
| |--- task-logic
| ---- task-ui
|--- clients
| |--- client-model
| |--- client-logic
| ---- client-ui
|--- supplier
| |--- supplier-model
| |--- supplier-logic
| ---- supplier-ui
|--- others
|--- utility
Основное преимущество этой группировки состоит в том, что tasks, clients и suppliers - это 3 разных, независимых программных секторов.Когда разработчику необходимо внести изменения, скажем, в client секторах, он получает все, что ему нужно, в небольшой части файловой системы (или на вкладке проводника проекта в IDE, например, Eclipse).Viceversa, в первом отображении, сектор программного обеспечения clients весь в хранилище проекта скремблируется.
Хотя это может не иметь большого значения, если «потрясающий» проект начинает становиться действительно большим, смножество артефактов и т. д., обнаружение, что все связанные части секторов clients начинают раздражать (не невозможно, в IDE для этой цели предлагается поиск).Я бы сказал, что вторая структура намного лучше, с точки зрения разработчика.
Тем не менее, кажется, что реализовать эту стратегию в maven сложно: основная трудность заключается в том, где разместить различные конфигурации сборки для каждого артефакта (например,*-ui должен быть построен иначе, чем *-model).
Может возникнуть соблазн поместить такие конфигурации в client-ui, client-logic, client-model, но это будет означать дублирование сборки конфигурации везде (например, client-ui, * 1045).*, task-ui имеет ту же конфигурацию сборки): если необходимо изменить конфигурацию сборки, вам нужно изменить все остальные копии;
Еще одним решением может быть объявление управления плагинамив awesome-root и они пишут определение плагина в каждом artifactId: хотя это кажется лучше, он все еще страдает от той же проблемы дублирования, что и в варианте 1;
Использование archetype для генерации poms справильная конфигурация сборки: то же, что и выше;
Профили: профили не наследуются и зависят только от системных свойств, а не от maven;
Мои вопросы :
Возможно ли создание второй структуры в Maven?Есть ли способ?
Если нет, нужно ли прикусить пулю и установить на первую конструкцию?
Есть ли альтернатива?(Я пытаюсь не предлагать проблему XY, приветствуется любая альтернатива);
Дополнительная информация :
- ОС:Ubuntu 18.04.3 (бионический), 64-битная
- Java-версия: openjdk 11.0.4 2019-07-16
- IDE: Eclipse 4.10.0
- плагин m2e: 1.10.0.20181127-2120
Спасибо за любой ответ