Организация структуры проекта: как сделать его лучше? - PullRequest
1 голос
/ 02 сентября 2011

Все -

У нас есть несколько веб-приложений, все из которых основаны на какой-то версии Spring, разработанной в течение долгого времени различными командами в организациях.Каждый из них создает свою собственную WAR, имеет свой собственный контекст для работы и часто развертывается на одной машине, поскольку их функциональные возможности тесно связаны друг с другом.Таким образом, мы получаем:

tomcat/webapps/{A, B, C ... }

при развертывании, каждый из которых использует очень похожий набор инструментальных цепочек, реплицирует все Spring jar и зависимости вокруг.

IМне интересно, есть ли способ улучшить структуру проекта, развернуть ее как SINGLE war, позволяя каждому веб-приложению жить в своем собственном репо-источнике и иметь свой собственный темп развития ??

Любой указатель или ссылки приветствуются.

Оливер

Ответы [ 4 ]

3 голосов
/ 02 сентября 2011

Развертывание в одной WAR объединит все проекты вместе.Изменение одного из них будет означать повторное развертывание всех с прилагаемыми усилиями по обеспечению качества для проверки и регрессии.Я бы не рекомендовал это.

Можно обратиться к нескольким копиям Spring JAR, поместив их в Tomcat / lib;они загружаются загрузчиком классов Tomcat вместо загрузчика классов WAR.Это будет означать, что каждое приложение должно быть в одной и той же версии Spring;Обновление одного означает обновление всего.Тебе придется пройти все регрессионное тестирование одновременно.

Какой вред наносят тебе отдельные файлы WAR?Какое вам дело, если в каталоге Tomcat / webapps много развертываний?Одним из преимуществ является то, что они МОГУТ быть в отдельных графиках выпускаЭто большой, чтобы отдать.Прежде чем делать это, убедитесь, что у вас есть веская причина.

1 голос
/ 03 сентября 2011

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

Вы можете выиграть от объединения каждого проекта в одну WAR, но я думаю, что это действительно один изтрава всегда зеленее.Одна ключевая вещь, которую я хотел бы иметь в виду, это выяснить, сколько еще (или короче!) Займет перераспределение, если проекты будут объединены.

1 голос
/ 03 сентября 2011

вам, вероятно, придется перейти на сервер приложений, такой как jboss, но не могли бы вы использовать файл ear и попросить maven собрать модули для вас? Таким образом, вы можете поместить их в отдельные репозитории, если вы хотите, чтобы у каждого был свой pom, а затем создать другой проект с pom для файла ear:

вот плагин maven ear:

http://maven.apache.org/plugins/maven-ear-plugin/

вот старая запись в блоге о файле с несколькими весенними приложениями (одно applicationContext для всех войн, которыми можно поделиться, если вам нужно):

http://blog.springsource.com/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/

0 голосов
/ 03 сентября 2011

Подумайте об OSGi. Вы можете развернуть все зависимости только один раз, собрать свои отдельные, но взаимосвязанные модули как пакеты OSGi, а также развернуть и обновить их все независимо. Вы также можете выбрать, развертывать ли их все как WAR-файлы (веб-пакеты), или развертывать их как JAR-файлы с одной или несколькими WAR-файлами, импортирующими их, чтобы связать все. Веб-сервер Virgo , ранее Spring DM Server, действительно хорош и готов делать такие вещи прямо из коробки.

...