Проблемы с структурированием проектов Maven Multi Module

Хорошо, вот интересный опыт, который я имел с прошлой пары недель, структурируя мой проект с несколькими модулями maven.

Когда я решил использовать maven для управления жизненным циклом сборки, у меня было несколько причин, по которым я хотел выбрать maven.

а. В основном команды разработчиков разделены так, что каждая команда может работать над отдельным модулем в рамках проекта, например Team-A, для работы в системе управления пользователями, Team-B для работы в системе авторизации, Team-C для работы в системе управления документами... и скоро. В каждой команде есть разработчики Java, тестеры, эксперты пользовательского интерфейса и т.д.

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

И поэтому я пришел к выводу, что каждый модуль разработки многомодового проекта maven должен представлять функциональный модуль

PROJECT STRUCTURE 1

После некоторых обсуждений на форумах я обнаружил, что люди, предлагающие мне следовать многоуровневому подходу, были дочерними модулями, которые должны быть такими слоями, как слой уровня управления, уровень сервиса, дао-слой и т.д. Я не обращал внимания на этот совет, потому что это не решение моего цель команд, работающих над отдельным модулем. Таким образом, для большого проекта увеличивается время сборки и развертывания для каждой команды во время разработки, что влияет на временные линии проекта. иногда время сборки и развертывания составляет до 30 минут, если в проекте есть 10-11 модулей.

Но я обратил внимание на предположение о том, что сохранение уровня DAO для каждого модуля не является хорошей идеей, поскольку DAO очень гранулирован и повторно используется другими модулями. и, следовательно, зависимость одного модуля от другого будет каким-либо образом увеличиваться.

Я нашел решение этой проблемы, создав общий модуль и переместив DAO и DOMAIN в общий модуль, который будет унаследован как зависимость от каждого модуля. И это, кажется, более жизнеспособный вариант. Теперь структура проекта выглядит следующим образом.

PROJECT STRUCTURE 2

Теперь, когда я строю проект и запускаю webapp на сервере, он жалуется на 404, Resource Not Found. Я обнаружил, что это происходит потому, что папка WEB-INF/classes отсутствует, src/main/java отсутствует в модуле веб-приложения. Я искал и нашел пару ссылок, которые предположили, что это проблема сборки развертывания в Eclipse. Поэтому мне нужно вручную создать эти папки и добавить в сборку развертывания, потому что maven не делает этого.

Но большие вопросы:

  • Мне нужно переместить классы Controller, такие как com.mycompany.usermgmtsys.controller.UserMgmtController и т.д. в src/main/java. Или maven должен найти контроллеры из модулей, включенных как зависимость в WEB-INF/lib.

Я не хочу этого делать, например, вставляя java файл в веб-приложение. Я хочу, чтобы все контроллеры были доступны для веб-приложения в качестве зависимости, например, WEB-INF/lib/usermgmtsystem.jar. Но тогда Tomcat не будет искать контроллеры в папке классов.

Я не знаю, что мне делать? Любые предложения будут оценены.

Ответ 1

Я понял вопрос. Контроллеры являются компонентами уровня представления. Диспетчер ожидает, что компоненты уровня представления в папке WEB-INF/classes в целевом объекте, а не ищет его в lib. Я не уверен, что это справедливо только для структурирования на основе maven в eclipse. Итак, наконец, это изменения, которые я сделал

а. Создал исходную папку src/main/java в веб-приложении. Он не генерируется по умолчанию в модуле веб-приложения. б. Добавьте пакеты и соответствующие контроллеры в папку src/main/java.

Итак, окончательная структура, которая у меня есть (я не вставляю точный снимок eclipse, это обобщенный вид)

Final Structure

Ответ 2

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

Лично я стараюсь избегать многомодульных проектов, поскольку, если вы используете плагин Maven Release Plugin, вы блокируетесь для выпуска всех ваших модулей вместе.

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

Вы также получаете удар, если вы используете CI с многомодульными проектами - вы, как правило, запускаете все модули из корневого помпы, но если вы работаете в определенном модуле, вы в конечном итоге получаете удар создания тех, которые не изменились, по сути теряя некоторые преимущества, которые должна была обеспечить модуляция.

Итак, идите с независимыми модулями, но, и это важный бит, создайте общую "зависимость", используемую каждым.

A 'dependency' pom - это pom, который стандартизирует все зависимости в ваших проектах и ​​отличается тем, что эти зависимости указаны в разделе dependencyManagement, а не в разделе зависимостей (он также устанавливает стандартную конфигурацию плагина и т.д.). Это позволяет вашим проектным псам указывать зависимость pom как своего родителя, а затем объявлять зависимости, которые им нужны, за вычетом версий, которые выбираются из "зависимостей" и таким образом стандартизированы в ваших проектах.

Если вы все еще обеспокоены возможностью создания всего, это может быть достигнуто с помощью простого пакетного файла.

Ответ 3

Это хороший вопрос. Существует много аспектов, которые необходимо учитывать для полезного макета проекта. Я хотел бы попытаться ответить на тот, который вы не упомянули. Расширяется ли ваше приложение пользователями? Если это так, подумайте о создании отдельного модуля для вашего общедоступного уровня API (служебные интерфейсы, DTO, используемые этими службами, и Исключения, создаваемые службами).

В нашем приложении у нас есть несколько модулей maven на функциональную область. Идея состоит в том, что группа работала над функцией только в одной функциональной области, и эта изоляция не позволяла им взаимодействовать с источниками, которые были изменены другой группой. Каждая функциональная область далее разбивается на подмодули maven, которые мы называем "api", "domain" и "service" - мы не объединяем службы/контроллеры, домен и исключения в один модуль. Модуль api содержит те классы, которые мы хотим предоставить клиентам для их настройки. Наш уровень обслуживания - это реализация этих интерфейсов. Кроме того, мы не разрешаем одной службе модуля вызывать другую службу модуля, так как это обходит наш уровень взаимодействия с сервисом, где клиент может подключать расширения к нашим услугам. Использование отдельных модулей maven для каждой функциональной области помогает обеспечить это.

У нас есть другие модули (internal-api, web, adapter), но они действительно не добавляют к этой теме.