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

Question

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

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

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

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

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

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

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

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

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

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

1. мне нужно переместить классы контроллера как com.mycompany.usermgmtsys.controller.UserMgmtController и т.д .. в SRC/основной/Java Или мавена должны найти контроллеры от модульные банки, включенные как зависимость в WEB-INF/lib.

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

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