Знаток: веб-проекты Объединения

У меня есть продолжающий набор проектов Знатока:

  • Ядро PM
  • Сеть PM (с зависимостью к Ядру PM)
Теперь, этот проект используется для нескольких клиентов, но для каждого клиента существуют некоторые небольшие различия: главным образом различия в конфигурационных файлах, но некоторых клиентах также требуют дополнительных файлов Java (который не может быть установлен для других клиентов).

Я рассматривал несколько альтернатив о том, как поддерживать это со знатоком, но все еще ищу идеальное решение.

Лучшее решение, о котором я могу думать, состоит в том, чтобы создать отдельный проект знатока для каждого клиента (например, PM-CLIENT1...), который содержит только клиент определенные конфигурационные файлы и дополнительные файлы Java или jsp's.... Следующий шаг должен был бы рассмотреть веб-проект PM и клиентский проект как один веб-проект, означая: имейте их объединенный (упакованный) в 1 военный файл с файлами из клиентского проекта, имеющего приоритет по файлам из веб-проекта PM.

Более конкретный: выполнение mvn package на PM-Client1 взял бы все с сети PM, добавить/заменить файлы от PM-Client1 и затем упаковать это в единственную войну.

Таким образом, вопрос: как достигнуть этого со знатоком?

5
задан Stijn Geukens 24 January 2015 в 20:36
поделиться

3 ответа

Да, это можно сделать с помощью накладок . Образец на веб-странице - это именно то, о чем вы говорите.

Для структуры проекта можно использовать нечто подобное:

.
|-- 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- classes.jar, который затем можно будет объявить зависимым в проекте PM-Client1 (с помощью области видимости , предусмотренной ). Для получения более подробной информации обратитесь к MWAR-73 и MWAR-131. Это также обсуждается в FAQ плагина войны. Обратите внимание, что это не рекомендуется, правильным было бы переместить классы в отдельный модуль (и это другое решение, о котором я хотел бы упомянуть).

UPDATE (201001018): Я попробовал параметр attachClasses и он работает с версией 2.1-beta-1 плагина.

4
ответ дан 14 December 2019 в 13:36
поделиться

Вы могли использовать , профили видят http://maven.apache.org/guides/mini/guide-building-for-different-environments.html и используют классификаторы для различения артефакты от различных сборок для той же версии. В этой установке вы могли создать дополнительные дополнительные модули для каждого из ваших клиентов определенное удовлетворение требованиям заказчика в соответствии с родительским проектом т.е.
+ PM
++ Ядро PM
++ Сеть PM
++ PM-Client1
++ PM-Client2

Или вы могли посмотреть на использование использования плагин блока знатока

1
ответ дан 14 December 2019 в 13:36
поделиться
1
ответ дан 14 December 2019 в 13:36
поделиться
Другие вопросы по тегам:

Похожие вопросы: