Статьи

Оверлеи Maven для WAR: Как управлять зависимостями

Февраль 7, 2019

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

Быстрый обзор

Почему быстрое резюме? Мы собираемся углубиться в то, как зависимости и библиотеки применяются к главному проекту. Чтобы иметь наложение WAR, вы должны включить WAR в качестве зависимости от главного проекта и наложить его на этапе пакета war-plugin.

Куда идут библиотеки зависимостей?

Как упоминалось в
первой части этого блога, файлы размещаются в местах их родителей, если они существуют. Это означает, что если в вашей WAR-оверлее у вас есть файл .jsp в /WEB-INF/welcome.jsp, то в главной WAR-файле в / WEB-INF будет файл с именем «welcome.jsp». Кроме того, если файл с именем «welcome.jsp» уже существует, этот файл не будет перезаписан. Если мы экстраполируем это немного больше, библиотеки в папке / WEB-INF / lib из оверлея будут помещены в папку / WEB-INF / lib главного проекта. Это замечательно, и все, кроме случаев, когда существуют разные версии библиотек, вызывающие сбои во время выполнения. Хорошая новость: существуют способы управления зависимостями как в оверлейном WAR, так и в главном проекте.

Как посмотреть библиотеки вашего основного артефакта?

Чтобы определить, какие библиотеки и в каком артефакте, есть два простых способа. Сначала определите, какие библиотеки находятся в вашем основном WAR.

mvn clean package 

ls -al target/YOUR_ARTIFACT_WAR/WEB-INF/lib

ПРИМЕЧАНИЕ: добавление «-DskipTests» при добавлении в вышеупомянутую команду maven пропустит тесты и сделает этот шаг немного быстрее, хотя это строго необязательно.

Во-вторых, добавьте параметр «workDirectory» в часть конфигурации вашего war-плагина, когда применяя оверлей Пример: <workDirectory> target / extract_here </ workDirectory>

В файле POM главного проекта:

<plugins>
...
...
<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>2.1.1</version>
        <configuration>
                <workDirectory>target/overlay-war-folder</workDirectory>
                <overlays>
                        <overlay>
                                <groupId>com.yourcompany</groupId>
                                <artifactId>branded-templates</artifactId>
                        </overlay>
                </overlays>
        </configuration>
</plugin>
...
...
</plugins>

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

Как исключить зависимости / библиотеки во время сборки?

Может быть трудно управлять зависимостями между каждым из наложений, особенно если наложение не находится под вашим контролем разработки. Одним из методов может быть управление зависимостями в двух файлах POM с использованием «предоставленных» и «дополнительных» зависимостей, которые предоставляет maven. Однако если оверлейный проект также может выступать в качестве отдельного проекта, этот метод не будет работать, поскольку библиотеки не считаются предоставленными или необязательными при независимом запуске. Это часто случается при попытке проверить каждый из оверлеев независимо. Дополнительная опция для управления библиотеками — исключение их из главной WAR на этапе пакета. Это достигается с помощью параметра «исключает» в каждой из секций наложения. Например, чтобы удалить все библиотеки Spring, вы можете исключитьвесна * .jar»

<plugins>
...
...
<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>2.1.1</version>
        <configuration>
                <workDirectory>target/overlay-war-folder</workDirectory>
                <overlays>
                        <overlay>
                                <groupId>com.yourcompany</groupId>
                                <artifactId>branded-templates</artifactId>
                                <excludes>
                                        <exclude>WEB-INF/lib/spring*.jar</exclude>
                                </excludes>
                                <excludes>
                                        <exclude>WEB-INF/lib/log4j*.jar</exclude>
                                </excludes>
                        </overlay>
                </overlays>
        </configuration>
</plugin>
...
...
</plugins>

Вы можете начать спрашивать себя, это очень быстро усложнится, и вы правы, есть и другие варианты.

Skinny vs Fat WAR Наложения

До сих пор все наши наложения считались «жирными», потому что они содержат все его зависимости, которые накладываются на главный WAR-файл. Существует альтернатива, которая более известна как «тощая война». Тощий ВОЙНА — это комбинация большинства тактик этого поста. ПРИМЕЧАНИЕ
. Метод, который я вам показываю, известен как «WAR скинниера», потому что библиотеки зависимостей существуют в файле WAR оверлея, однако классы будут выведены за пределы, и библиотеки могут быть удалены во время окончательной упаковки главного проекта.

Достижение «тощей войны»

Во-первых, в оверлейном проекте, во время
фазы пакета , скажите maven создать классы проекта как дополнительный артефакт в дополнение к файлу WAR. Этот набор классов станет jar-файлом, который будет использоваться в качестве второй зависимости в POM главного проекта.

В POM-файле оверлея (добавьте в существующий военный плагин):

<plugins>
...
...
<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>2.1.1</version>
        <configuration>
                <attachClasses>true</attachClasses>
        </configuration>
</plugin>
...
...
</plugins>

После успешной установки / развертывания оверлейного проекта мы добавим файл classes / jar и зависимость WAR в POM-файл главного проекта.

В файле POM мастер-проекта:

<dependency>  
   <groupId>com.yourcompany</groupId>  
   <artifactId>branded-templates</artifactId>  
   <type>war</type>  
</dependency>  


<dependencies>
...
...
<dependency>
        <groupId>com.yourcompany</groupId>
        <artifactId>branded-templates</artifactId>
        <version>1.1</version>
        <type>war</type>
</dependency>
<dependency>
        <groupId>com.yourcompany</groupId>
        <artifactId>branded-templates</artifactId>
        <version>1.1</version>
        <type>jar</type>
        <classifier>classes</classifier>
</dependency>
...
...
</dependencies>

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

<plugins>
...
...
<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>2.1.1</version>
        <configuration>
                <workDirectory>target/overlay-war-folder</workDirectory>
                <overlays>
                        <overlay>
                                <groupId>com.yourcompany</groupId>
                                <artifactId>branded-templates</artifactId>
                                <excludes>
                                        <exclude>WEB-INF/lib/*.jar</exclude>
                                </excludes>
                        </overlay>
                </overlays>
        </configuration>
</plugin>
...
...
</plugins>

ПРИМЕЧАНИЕ. Зависимости, существующие в оверлее, необходимо будет добавить в качестве зависимостей в главный проект, поскольку они были удалены из папки оверлея / WEB-INF / lib. Это основной известный риск использования узких военных наложений

Поздравляем!

Теперь у вас есть проект с ограниченными конфликтами библиотек, и вы можете лучше управлять основным проектом и его стабильностью.

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

С http://www.ensor.cc/2011/07/mavens-war-overlays-how-to-manage.html

47
Share: