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

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

В настоящее время мы развертываем один файл WAR, как ROOT.warна Apache tomcat, на нашем сервере. Поскольку проект большой, в веб-приложении есть такие части, как «Уведомления и электронная почта», «Сторонние сервисы», «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 может вам помочь. Тем не менее, может потребоваться, чтобы вы реорганизовались, чтобы лучше соответствовать его собственному соглашению, и если я должен дать один совет, то здесь НАМНОГО проще изменить ваши вещи в соответствии с соглашениями Maven, чем пытаться настроить Maven для понять ваше соглашение.

Если бы эти проекты можно было использовать вне основного приложения, они могли бы жить как действительно независимые библиотеки и включать в себя, хотя бы, зависимости maven. Они должны жить в своем собственном хранилище (не в дереве исходного кода приложения) и не должны зависеть от какой-либо части основного приложения.

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

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

механическая обработка

Если вы являетесь командой больше 1, я также настоятельно рекомендую установить репозиторий для ваших зависимостей Maven. Посмотрите на Artifactory , Nexus или Archiva . Вы можете настроить файл POM для установки на них напрямую, поэтому после запуска он не должен быть слишком трудоемким, но сэкономит вашей команде много времени на устранение зависимостей с правильным jar-файлом в правильном месте.

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

Поскольку вы упаковываете свое приложение как военный мастер, он может справиться с созданием войны и разместить все зависимости на своих местах без необходимости объединения файлов JAR или другой подобной работы, поэтому не стоит беспокоиться.

пример

Я мог бы продолжать здесь гораздо дольше, но ничто не сравнится с хорошим примером. Посмотрите на 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команду, чтобы увидеть, что на самом деле понял Maven.

плагины

Из вашего комментария я понимаю, что вы хотите достичь. В этом случае я бы пошел на подход плагинов. Создайте проект, который предоставляет API точек расширения, где вы хотите изолировать работу. Затем вы можете использовать это как зависимость в новом проекте, который будет его реализовывать. В вашем основном приложении просто добавьте правильные зависимости для этих реализаций (не используя модули maven на этот раз), и вы должны быть готовы. В конце концов, основной проект приложения почти не будет содержать исходный код, все делается во внешних проектах и ​​загружается через зависимости.

Однако при таком подходе вам необходимо будет повторно развернуть все приложение, независимо от того, изменилось ли ядро ​​или нет, поскольку война статически построена из зависимостей, изменение одной из них подразумевает перестройку всего объекта. Звучит хуже, чем есть на самом деле. По сути, только новые изменения будут фактически собраны, остальные будут в основном копией предыдущих jar-ов. Но так как все находится в файле войны, его нужно будет пересобрать, а сервер нужно будет остановить и перезапустить.

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

Основное различие между модулями и зависимостями заключается в следующем:

• Модули будут жить в том же дереве исходного кода, что и основное приложение, в идеале как подпапки.
• Зависимости могут быть где угодно.

Вы можете найти Библию здесь .

Надеюсь это поможет. Удачи.