У меня есть продолжающий набор проектов Знатока:
Я рассматривал несколько альтернатив о том, как поддерживать это со знатоком, но все еще ищу идеальное решение.
Лучшее решение, о котором я могу думать, состоит в том, чтобы создать отдельный проект знатока для каждого клиента (например, PM-CLIENT1...), который содержит только клиент определенные конфигурационные файлы и дополнительные файлы Java или jsp's.... Следующий шаг должен был бы рассмотреть веб-проект PM и клиентский проект как один веб-проект, означая: имейте их объединенный (упакованный) в 1 военный файл с файлами из клиентского проекта, имеющего приоритет по файлам из веб-проекта PM.
Более конкретный: выполнение mvn package
на PM-Client1 взял бы все с сети PM, добавить/заменить файлы от PM-Client1 и затем упаковать это в единственную войну.
Таким образом, вопрос: как достигнуть этого со знатоком?
Да, это можно сделать с помощью накладок . Образец на веб-странице - это именно то, о чем вы говорите.
Для структуры проекта можно использовать нечто подобное:
. |-- PM-Core |-- PM-WebCommon (of type war, depends on core) |-- PM-Client1 (of type war, depends on webcommon) `-- PM-Client2 (of type war, depends on webcommon)
И использовать оверлеи в PM-Client1 и PM-Client2 для "слияния" их с PM-WebCommon и пакетных войн для каждого клиента.
UPDATE Я не буду описывать все подробности, но думаю, что объявление зависимости от войны с диапазоном типа runtime
требуется при использовании оверлея, так работает оверлей (на самом деле, вся эта штука с оверлеем - своего рода хакерство). Теперь, чтобы решить проблему затмения, одним из решений будет создание JAR, содержащего классы проекта PM-WebCommon. Для этого воспользуйтесь опциональным параметром attachClasses
и установите его в значение true
. Это подскажет maven создать PM-WebCommon-
, который затем можно будет объявить зависимым в проекте PM-Client1 (с помощью области видимости , предусмотренной
). Для получения более подробной информации обратитесь к MWAR-73 и MWAR-131. Это также обсуждается в FAQ плагина войны. Обратите внимание, что это не рекомендуется, правильным было бы переместить классы в отдельный модуль (и это другое решение, о котором я хотел бы упомянуть).
UPDATE (201001018): Я попробовал параметр attachClasses
и он работает с версией 2.1-beta-1 плагина.
Вы могли использовать , профили видят http://maven.apache.org/guides/mini/guide-building-for-different-environments.html и используют классификаторы для различения артефакты от различных сборок для той же версии.
В этой установке вы могли создать дополнительные дополнительные модули для каждого из ваших клиентов определенное удовлетворение требованиям заказчика в соответствии с родительским проектом т.е.
+ PM
++ Ядро PM
++ Сеть PM
++ PM-Client1
++ PM-Client2
Или вы могли посмотреть на использование использования плагин блока знатока
Сравнивают также ответы для вопроса различные ВОЕННЫЕ файлы, совместно используемые ресурсы .