2015-02-03 10 views
0

Я пытаюсь разработать решение, которое позволяет одному приложению Virgo обеспечить обратную совместимость для интеграции с несколькими версиями внешнего поставщика услуг.Возможно ли построить несколько версий одного и того же модуля?

Например, приложение, называемое PortalApp, представляет собой портал, который в настоящее время интегрируется с версией 3rdPartyApp версии 2.3. ThirdPartyApp v3.0 скоро выйдет с новыми функциями, поэтому новая версия PortalApp будет иметь функции, которые не будут работать со старой версией ThirdPartyApp.

Я не требую возможности динамически обслуживать обе версии во время выполнения, только один или другой. Я уже установил, что у меня могут быть две версии модуля в репозитории Virgo usr и загрузка того или другого на основе файла .plan, используемого при запуске сервера.

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

 
PortalApp 
- web-app 
- ThirdPartyProvider 

Есть целый ряд других модулей, которые зависят от ThirdPartyProvider, поэтому изменение артефакта бы разорвать эти цепи. Я бы хотел создать две разные версии одного и того же модуля. Что-то вроде этого:

 
PortalApp 
- web-app 
- - 1.0 
- - 2.0 
- ThirdPartyProvider 
- - 1.0 
- - 2.0 

Я попытался создать родительский pom.xml в веб-приложение (упаковка: POM), которые были определены как 1.0 и 2.0 в качестве модулей, но только один из них строит.

Может ли одна сборка проекта PortalApp построить обе версии модуля?

+0

Почему вы хотите построить 2 версии? один для версии 2.3, а другой для 3.0, который подходит? –

+0

Да. Это точно, Эдду. Проблемой является требование продолжать добавлять функциональные возможности для обеих версий. В противном случае я мог бы архивировать старый модуль и добавить шаг сборки, чтобы переместить его в репозиторий Virgo usr. – Tweeds

ответ

0

Нет, это невозможно (на самом деле это так, но вы действительно не хотели бы этого делать, потому что это мир боли). У pom есть тег версии, и это версия созданного артефакта.

Вместо этого вы должны создать проект с несколькими модулями с одним модулем для каждого веб-приложения, как и на вашей второй диаграмме, каждый из которых зависит от соответствующей версии ThirdPartyProvider. Затем вы определяете общий код из этих веб-приложений - обычно это создает две вещи: общее веб-приложение, от которого вы зависите от веб-приложения: 1 и веб-приложение: 2 (это создаст так называемое «наложение» ', который подталкивает содержимое общего в другие два приложения, но не перезаписывает существующие файлы) и общую библиотеку java, содержащую общие классы Java (в зависимости от того, как вы используете сторонний api, вам могут понадобиться два из этих слишком).

Затем вы создаете оба веб-приложения, создавая два артефакта, web-app-1.war и web-app-2.war, каждый из которых зависит от соответствующего ThridPartyProvider и от общих классов lib.

+0

Спасибо инженер.Это то, что я ожидал. Я надеялся, что я пропустил трюк или эксплоит в Maven, но решил, что мне придётся реализовать отдельные посты высшего уровня для каждой выпущенной версии. – Tweeds

0

Для того, чтобы сохранить все артефакты в одной и той же версии, которую вы могли бы использовать Versions Maven Plugin для установки версии 2.0 или 3.0, и в вашей сборке вы можете использовать МВН пакет -DthirdParty.version = 3,0

Убедитесь, что ваш pom.xml выглядит следующим образом

<properties> 
    <thirdParty.version>2.0</thirdParty.version> 
</properties> 

Таким образом, вы можете использовать Jenkins для того, чтобы автоматизировать buils и убедиться, что eveyrhing нормально в вашем непрерывном процессе интеграции.

Смежные вопросы