Что такое наложение WAR?
Наложения используются для совместного использования общих ресурсов несколькими веб-приложениями. Зависимости проекта WAR собраны в WEB-INF / lib, за исключением артефактов WAR, которые накладываются на сам проект WAR. http://maven.apache.org/plugins/maven-war-plugin/overlays.html
Почему и где бы вы использовали наложение WAR?
Наложения WAR составляют еще один инструмент в вашем арсенале для борьбы с повторяющимся кодом и / или ресурсами. Наложения позволяют объединять много похожих ресурсов, например, изображения, файлы CSS и JavaScript, в один проект. Во время сборки наложение будет предсказуемо объединено в основной проект WAR. Отличным примером оверлея WAR является фирменный веб-сайт в сочетании с декораторами Sitemesh. Представьте, что у вас есть фирменный веб-сайт, который состоит из нескольких веб-приложений. Подход отраслевого стандарта будет состоять в том, чтобы использовать декораторы Sitemesh, чтобы украсить приложение фирменными стилями и позволить каждому из ваших приложений сосредоточиться на конкретной цели этого приложения. В настоящее время этот пост в блоге не будет углубляться в декораторы Sitemesh, однако более подробная информация доступна по адресу http://www.sitemesh.org/,
Как следует из нашего примера, каждому из декораторов потребуется набор CSS, изображений и, возможно, файлов JavaScript для определения фирменного стиля приложения. Если ваши приложения должны быть развернуты на рабочем месте, чтобы выглядеть и действовать как единый фирменный сайт, вам необходимо убедиться, что изображения, CSS, JavaScript, файлы декоратора и файлы JSP одинаковы в каждом из ваших приложений, чтобы сохраняйте постоянный бренд в своих приложениях. Что ж, это дублированный код (в настоящее время он входит в пятерку моих самых больших «кодов, которых можно избежать при любой стоимости»).
Как вы решаете дублирование кода, используя WAR Overlays?
Один из подходов к уменьшению количества дублирующегося кода заключается в создании отдельного проекта maven с целевым типом упаковки WAR. Затем в каждом файле pom.xml вашего приложения включите оверлейный проект в качестве зависимости и создайте его в качестве оверлея с помощью maven-war-plugin. Это известно как FAT WAR Overlay . ( ПРИМЕЧАНИЕ. В следующем посте я расскажу о других типах наложений WAR, чтобы уменьшить проблемы переходных зависимостей )
Больше подробностей, пожалуйста!
Во-первых, давайте создадим новый проект maven WAR и назовем его «branded-templates» . ( ПРИМЕЧАНИЕ. Этот пост не предназначен для того, чтобы быть исчерпывающим руководством по созданию проекта maven, а только для добавления к уже работающему проекту maven. Если вам нужна дополнительная помощь, обратитесь к некоторым другим моим постам или веб-сайту maven для получения дополнительных указаний. )
В нашем новом приложении с фирменными шаблонами нам нужно будет заполнить это нашими ресурсами. Вот мои рекомендуемые места для размещения веб-ресурсов в вашем проекте:
- / src / main / webapp / styles — используется для хранения ваших CSS-файлов (например: brand.css, reset.css и т. д.)
- / src / main / webapp / scripts / — используется для хранения файлов JavaScript бренда (например: jquery.1.xx-min.js, jquery-my-company-validation.js и т. д.
- / src / main / webapp / images / — используется для хранения изображений бренда (например: company-logo.png, facebook-icon.png, company-background.jpg и т. д.)
Наименование на данный момент не будет иметь большого значения, но вам придется принимать решения здесь, потому что у вас есть два варианта именования, которые будут иметь последствия для развития. Вы можете называть ваши ресурсы и / или папки одинаково в обоих ваших приложениях, или вы можете называть их по-разному, чтобы получить разные желаемые результаты. Как это повлияет на мой дизайн и почему вы должны подумать об этом? (Ответ придет после того, как мы добавим в содержащий проект веб-приложения, продолжайте!)
Давай продолжим. Теперь мы можем установить ваш WAR-оверлей фирменных шаблонов в ваш локальный репозиторий maven:
mvn clean install
Если все хорошо, вы должны увидеть «Успешную сборку» вместе с 1.0-SNAPSHOT для вашей версии WAR.
Теперь давайте создадим новое основное приложение под названием «main-webapp» . Если у вас есть существующее веб-приложение, не стесняйтесь использовать его и работать вместе с этим примером. Внутри файла pom.xml основного веб-приложения нам нужно добавить плагин для объединения двух WAR в одну WAR и добавить оверлей в качестве зависимости от проекта.
Добавьте в ваш раздел зависимостей:
<dependency>
<groupId>com.yourcompany</groupId>
<artifactId>branded-templates</artifactId>
<type>war</type>
</dependency>
Обратите внимание, что мы добавляем это как тип WAR , не оставляйте тип пустым.
Добавьте в раздел плагинов:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<overlays>
<overlay>
<groupId>com.yourcompany</groupId>
<artifactId>branded-templates</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
Далее мы добавили плагин war, который примет наше приложение и создаст WAR. Если вы знакомы с типами артефактов maven, вы уже знаете, что ваш проект уже создает WAR, так почему плагин? Плагин — это место, где происходит «волшебство» наложения. Здесь наложение помещается в файл WAR основного веб-приложения.
Сколько у меня будет WAR-файлов?
При использовании оверлея WAR вы начнете с двух или более файлов WAR (предположительно, с одним или несколькими оверлеями и основным веб-приложением), но в конечном итоге получите один артефакт WAR (ваше основное веб-приложение), который будет развернут в вашей среде. , Несмотря на то, что полностью возможно запустить оверлей как отдельное приложение, я рекомендовал вам прочитать мой следующий пост (скоро) об управлении зависимостями в проектах оверлеев, чтобы избежать проблем с зависимостями в вашем проекте main-app.
Так что же происходит, когда существует конфликтующий ресурс?
Как вы можете себе представить, могут быть конфликты между именами ресурсов оверлея и ресурсами основного проекта. Это то, о чем я просил вас подумать из поставленного выше вопроса. Если у вас есть то же местоположение и имя файла в приложении наложения, что и в вашем основном приложении, версия наложения будет проигнорирована для версии основного приложения . Это может работать для вас или против вас, так что подумайте, как вы можете использовать оба. Как бы вы хотели использовать возможности настройки в основном веб-приложении.
Обратите внимание: если вы планируете использовать декораторы Sitemesh, неплохо было бы поместить ваши файлы decorators.xml и sitemesh.xml в вашу папку WEB-INF и соответствующие JSP в папке WEB-INF (предложите поместить их в / WEB- Папка INF / decorators). Не забудьте добавить информацию sitemesh web.xml в файл web-приложения основного веб-приложения.
Еще один недостаток, который может возникнуть из-за этого, будет иметь дело с web.xml. В файле web.xml Наложить НЕ копируется и не является слился в любом случае , так что если наложение имеет конкретную информацию web.xml файл можно либо вручную добавить его в web.xml или использовать <инклюдник = «/ WEB -INF / web-overlay.xml «> тег, в котором вы добавили содержимое в файл с именем web-overlay.xml в военный проект оверлеев.
Советы по быстрому развитию
На этом этапе у вас должно быть наложение и работающее главное веб-приложение, использующее это наложение WAR. Поскольку у вас есть ресурсы в оверлее, и вы, вероятно, работаете в основном веб-приложении, и развертывание новой версии вашего проекта оверлея становится все труднее, вы можете просто сослаться на версию вашего оверлея SNAPSHOT внутри вашего файл main-webapp pom.xml и выполните локальную установку вашего оверлея.
С http://www.ensor.cc/2011/06/mavens-war-overlay-what-are-war.html