2013-04-05 2 views
4

У меня есть один проект Maven, в котором есть «ядро» и «веб». Я пытаюсь преобразовать его в несколько модулей.Автообновленные зависимости в многомодульном проекте Maven

Я взял «веб-пакеты» и поместил их в новый проект. Я добавил основной проект как зависимость, и я могу ссылаться на его классы в Eclipse. «Ядро» проекта правильно отображается в WEB-INF\lib в «веб-проекте», когда я его создаю.

Проблема возникает, когда классы из «основного» проекта составляют @Autowired в проекте «Интернет».

В данном конкретном случае я запускаю класс обслуживания из «ядра» в один из классов веб-сервисов в «веб-проекте». Если я добавлю пакет, к которому относится базовая услуга, к моему context:component-scan в моей конфигурации «веб-приложений», он находит эту службу, но затем служба ссылается на репозиторий, который ссылается на сущность, которая ищет фабрику управления сущностями, которую я «Я настроен в своем приложении-контексте в моем« основном »проекте.

Похоже, что возможно, что context:component-scan в «основном» проекте не происходит? Или, возможно, выбранные классы не становятся доступными для «веб-проекта»?

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

Я использую m2e в Eclipse с плагином Run Jetty Run, если это имеет значение; однако, похоже, у меня такие же проблемы, когда я делаю mvn jetty:run из командной строки.

ответ

5

Вам нужно будет загрузить приложение-приложение основного модуля из контекста приложения веб-модуля. В противном случае он не будет знать о компонентах, определенных в контексте основного приложения. Посмотрите ответы на вопросы Application context from other maven module cannot be loaded и Spring import application context from another project для правильных решений.
Вы также можете взглянуть на это post, в котором описывается, как создать многомодульный проект Spring с использованием Maven.

+0

Спасибо за ответ. Кажется, это работает. Еще один быстрый вопрос, если вы не возражаете ... Является ли это общепринятым решением для такого типа модуляции? Единственная причина, по которой я спрашиваю, состоит в том, что если я буду распространять свой «основной» проект, кто-то должен будет узнать хотя бы имя моего контекста приложения, чтобы он работал правильно. Это не проблема в моем случае, потому что это все внутреннее, но я бы хотел сделать это наименее хрупким способом. Существует ли конкретное соглашение об именах для контекстов приложений, которые должны быть загружены в другие модули? – Luke

+0

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

+0

Отлично! Еще раз спасибо. – Luke

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