Розщеплення великого проекту для створення багатомодульного проекту Maven

Я працюю над додатком Spring-MVC, в якому ми використовуємо Maven для управління залежностями. Оскільки проект великий, ми думаємо розділити проект на кілька частин. У мене були деякі сумніви, на які, сподіваюся, тут я отримаю відповіді.

Наразі ми розгортаємо один файл WAR, як ROOT.warна Tompata Apache на нашому сервері. Оскільки проект великий, у веб-сайтах є такі частини, як сповіщення та електронна пошта, послуги сторонніх служб, PUSH (Cometd), REST API та ін. В даний час всі вони розташовані в клубі і залежать один від одного. Наприклад, Notificationоб'єкт також залежить від Personоб'єкта, оскільки сповіщення призначені для користувачів.

Основний намір розділити великий проект - це можливість працювати над окремими модулями, над виправленнями помилок, додаванням функцій, тестуванням і т. Д. І коли це задоволено, то на сервері замість усієї програми можна замінити лише цей модуль. Чи можливо це?

Як я вже згадував раніше, між об'єктами існують залежності та відображення. Як ними керуватимуть різні підмодулі, чи просто змінити заяви про імпорт включатимуть інші проекти?

Як я вже говорив, намір полягає в тому, щоб працювати над окремими модулями та мати можливість їх розгортання (бажано гарячого). Наразі у нас є лише один файл WAR як ROOT.war. Чи буде розщеплення створювати кілька файлів війни, які потім називаються URL-адресою як domain-name.com/module_name/some_mapping?

Наразі я перевіряю документацію, але це головна мета, яку ми хочемо досягти за допомогою багатомодульного модуля, наданого Maven, і зацікавлене знати, чи це можливо. Якщо потрібна додаткова інформація, будь ласка, повідомте мене про це.

В даний час я використовую батьківський POM з весни наступним чином:

<parent>
    <groupId>io.spring.platform</groupId>
    <artifactId>platform-bom</artifactId>
    <version>1.1.3.RELEASE</version>
    <relativePath />
</parent>

Це можливо ?

Так, звичайно. Я мав у минулому структуру декількох подібних проектів, ось деякі шматочки, сподіваюсь, ви змусите вас розпочати.

Є дві основні особливості Maven, які ви будете використовувати, щоб плести речі разом:

• Нормальні залежності
• Модулі

Розділяй і володарюй

Вам потрібно буде розділити свої проекти на кілька незалежних проектів. Під незалежним я маю на увазі, що всі посилання на код поза проектом робляться через залежності в Maven, а не безпосередньо зливаються з вихідним деревом.

Залежно від стану вашого вихідного дерева це може означати багато роботи. Це говорить про те, що ви робите це не для того, щоб взуватися на Maven, а як засіб для структуризації та санітарії кодової бази. Подумайте про це як про свій інструментарій, набагато простіше знайти тут речі:

ніж тут:

Мейвен в значній мірі покладається на конвенцію, тому чим краще організовані ваші речі, тим більше Maven може допомогти вам. Однак, це може зажадати від вас переорганізуватися, щоб краще підходити до власної конвенції, і якщо мені доведеться дати поради, то це набагато простіше змінити свої речі, щоб вони відповідали умовам Мейвена, ніж намагатися налаштувати Maven на зрозуміти свою умовність.

Якби ці проекти могли бути корисними поза основним додатком, вони могли б жити як справді незалежні бібліотеки і включатись, хоча і залежними від них. Вони повинні жити у власному сховищі (не у дереві джерела додатків) і не повинні залежати від будь-якої частини основного додатку.

Після розподілу в проектах основні частини вашої програми можуть бути складені як модулі. Як правило, вони розміщуватимуться як підпапка основної папки джерела програми.

Також ваша батьківська POM для вашої програми міститиме декларацію модуля. Ви також розмістите там всі загальні залежності для вашого додатка, а також оголосите більшість плагінів збірки та їх конфігурацію. Тут також я настійно рекомендую вам розмістити групу властивостей для речей, таких як версія програми, яку ви можете повторно використовувати в модулях. Набагато простіше керувати, коли всі мають однакову версію, а наявність версії в одному місці змушує це просто працювати.

Інструментальне обладнання

Якщо ви команда більше 1, я також настійно рекомендую вам встановити сховище для ваших залежностей від Maven. Подивіться на Artifactory , Nexus або Archiva . Ви можете налаштувати файл POM для встановлення на них безпосередньо, так що після запуску він не повинен мати великі накладні витрати, але заощадить вашій команді багато часу на вирішення залежностей правильною банку в потрібному місці.

Наступним логічним кроком щодо інструментального інструменту є система безперервної інтеграції ( Дженкінс , їх ще багато). Він буде керувати побудовою джерела, запускаючи тести і підштовхуючи до артефактури, при цьому все це потрібно зробити - це працювати над кодом, а решта просто працює.

Оскільки ви упаковуєте свій додаток як воєнний генерал, можна впоратися зі створенням війни та розмістити всі залежні місця у відповідних місцях без необхідності зливати файли з баночками чи іншою подібною роботою.

Приклад

Я міг би продовжуватись тут набагато довше, але нічого не є хорошим прикладом. Подивіться на github для проектів подібної величини і подивіться, як вони створювали свої пом-файли та ієрархії папок. Подивіться на більш ніж один, деякі будуть відповідати вашій установці краще , ніж інші, ніхто на насправді не втілитися на істині , але ви повинні знайти достатньо , щоб живити ваші думки про те , як зробити це.

Візьмемо для прикладу Дженкінс :

Ви можете бачити, що їх батьківський POM досить великий.

Вони використовують модулі, як ви бачите в цьому розділі:

<modules>
    <module>core</module>
    <module>war</module>
    <module>test</module>
    <module>cli</module>
</modules>

І кожному модулю відповідає підпапка з тим самим іменем, яка також містить POM. Ви можете вкладати стільки, скільки хочете, як це, хоч і тримайте це в межах розумності;).

Почніть з малого

Якщо ви ніколи не використовували Maven, я б запропонував, однак ви не починайте відразу з модулів. Поводьте це повільно, почніть з, скажімо, однієї з найпростіших бібліотек, яку ви можете мати, і зробіть це проект Maven. Потім зробіть свою основну заявку простим проектом Maven. Після цього почніть додавати прості залежності, а потім розділіть свій перший модуль тощо.

Maven - чудовий інструмент, але він також може бути супер болем у шиї, особливо коли справи йдуть не по-своєму. Починаючи з усієї розпуки на першому шляху - це рецепт катастрофи (був для мене!).

Якщо справи трохи дивні, ви завжди можете скористатися mvn help:effective-pomкомандою, щоб побачити, що Мевен насправді зрозумів.

плагіни

З вашого коментаря я краще розумію, що ви хочете отримати. У цьому випадку я б підходив до плагінів. Створіть проект, який розкриває API точок розширення, де ви хочете ізолювати роботу. Тоді ви можете використовувати це як залежність у новому проекті, який буде його реалізовувати. У своєму головному додатку просто додайте належні залежності для цих реалізацій (цього разу не використовуючи модулів Maven), і вам слід добре піти. Врешті-решт, основний проектний приклад не матиме майже жодного вихідного коду, що робиться у зовнішніх проектах та завантажується через залежності.

Однак вам потрібно буде перевстановити всю програму, але при такому підході, незалежно від того, змінилося ядро ​​чи ні, оскільки війна статично будується із залежностей, зміна однієї з них передбачає перебудову всієї справи. Це звучить гірше, ніж є насправді. Насправді лише нові зміни будуть фактично вбудовані, решта - це копія попереднього банку. Але оскільки все є у файлі війни, його потрібно буде відновити, і сервер потрібно буде зупинити і перезапустити.

Якщо вам потрібно йти далі, справи стають трохи складнішими, хоча і не неможливими. Я рекомендую вам заглянути в OSGI, Apache Felix міг би розпочати роботу, хоча є й інші реалізації. Це дозволить вам взяти зовнішню банку і перетворити їх у належні плагіни. Ви отримаєте набагато більше контролю над життєвим циклом виконання компонентів, що відкривають двері для динамічного перезавантаження та оновлення. Однак це вимагатиме значних змін у вашій ядрі, тому знову, ймовірно, не є гарною відправною точкою. Однак після того, як у вас є проект, який добре відокремлений, і всі частини виділені так, як ви хочете, це може бути природним наступним кроком, якщо запуск та зупинка програми на оновлення є головною проблемою.

Основна різниця між Модулями та залежностями полягає в наступному:

• Модулі житимуть у тому ж вихідному дереві, що і основний додаток, як ідеально підпапки.
• Залежності можуть бути де завгодно.

Ви можете знайти Біблію тут .

Сподіваюся, це допомагає, удачі.