JavaRush /Курсы /JSP & Servlets /Управление файлами во время сборки Maven-проекта

Управление файлами во время сборки Maven-проекта

JSP & Servlets
2 уровень , 1 лекция
Открыта

2.1 Плагин копирования ресурсов maven-resources-plugin

Если ты собираешь web-приложение, то у тебя будет просто куча различных ресурсов в нем. Это jar-библиотеки, jsp-сервлеты, файлы настроек. Ну и конечно же это куча статических файлов типа html, css, js, а также различных картинок.

По умолчанию Maven при сборке проекта просто скопирует все ваши файлы из папки src/main/resources в директорию target. Если же ты хочешь внести изменения в это поведение, то тебе поможет плагин maven-resources-plugin.

Пример кода такого плагина:

<plugin>
    <artifactId>maven-resources-plugin</artifactId>
    <version>2.6</version>
    <executions>
        <execution>
            <id>copy-resources</id> <phase>validate</phase> <goals> <goal>copy-resources</goal> </goals>
            <configuration> <outputDirectory> ${basedir}/target/resources </outputDirectory> <resources>
                    <resource> инструкции по копированию ресурса 1 </resource> <resource> инструкции по копированию ресурса 2 </resource> <resource> инструкции по копированию ресурса N </resource>
                </resources> </configuration>
        </execution>
    </executions>
</plugin>

Данный плагин вызовется во время фазы validate. С помощью тега <outputDirectory> можно задать директорию, в которую плагин должен будет скопировать ресурсы, заданные в секции <resources>. И вот тут-то плагин может развернуться во всю свою мощь.

2.2 Фильтрация ресурсов с помощью maven-resources-plugin

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

Пример:


            <resource>
                <directory>src/main/resources/images</directory>
                <includes>
                     <include>**/*.png</include>
                </includes>
            </resource>

Две звездочки в качестве маски обозначают любое количество директорий. В примере выше в качестве данных ресурса будут взяты все png-файлы, которые содержаться в директории src/main/resources/images (и ее поддиректориях).

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

<resource>
    <directory>src/main/resources/images</directory>
    <includes> <include>**/*.png</include> </includes>
    <excludes> <exclude>old/*.png</exclude> </excludes>
</resource>

Теги применяются последовательно: сначала к ресурсу будут добавлены указанные в include-файлы, а затем из этого списка исключат exclude-файлы.

Но и это еще не все. Плагин умеет заглядывать внутрь файлов (если они текстовые, конечно). И, например, добавить в файл application.properties нужную версию сборки. Чтобы плагин обрабатывал содержимое файла, нужно указать ему параметр <filtering>true</filtering>.

Пример:

<resource>
    <directory>src/main/resources/properties</directory>
    <filtering>true</filtering>
    <includes> <include>**/*. properties </include> </includes>
</resource>

Более подробно с данным плагином можно ознакомиться по ссылке: https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html

2.3 Плагин включения исходных кодов maven-source-plugin

Еще один полезный плагин – maven-source-plugin позволяет включать в сборку исходный код ваших java-файлов. Зачем?

Все дело в том, что кроме web-приложений, с помощью Maven собирается очень большое количество библиотек. Очень много Java-проектов следуют концепции open-source и распространяются среди Java-сообщества со своими исходниками.

Зачем нужен отдельный плагин? Почему нельзя просто скопировать исходники и все?

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

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

Ну и в-третьих, ты можешь решить не включать какие-нибудь особо секретные файлы в вашу сборку.

Пример использования плагина maven-source-plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-source-plugin</artifactId>
    <version>2.2.1</version>
    <executions>
        <execution>
            <id>attach-sources</id>
            <phase>verify</phase>
            <goals>
                <goal>jar</goal>
            </goals>
        </execution>
    </executions>
</plugin>

2.4 Плагин копирования зависимостей maven-dependency-plugin

Также тебе может понадобиться умное копирование зависимостей (библиотек) при сборке проекта. Для этого используется плагин maven-dependency-plugin.

Пример:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>2.5.1</version>
    <configuration>
        <outputDirectory> ${project.build.directory}/lib/ </outputDirectory>
    </configuration>
    <executions>
        <execution> <id>copy-dependencies</id> <phase>package</phase> <goals> <goal>copy-dependencies</goal> </goals> </execution>
    </executions>
</plugin>

В этом примере прописано дефолтное поведение плагина – копирование библиотек в директорию ${project.build.directory}/lib.

В секции execution прописано, что плагин будет вызван во время фазы сборки – package, goal – copy-dependences.

В целом, у этого плагина довольно большой набор целей, вот самые популярные из них:

1 dependency:analyze анализ зависимостей (используемые, неиспользуемые, указанные, неуказанные)
2 dependency:analyze-duplicate определение дублирующихся зависимостей
3 dependency:resolve разрешение (определение) всех зависимостей
4 dependency:resolve-plugin разрешение (определение) всех плагинов
5 dependency:tree вывод на экран дерева зависимостей

Также в разделе configuration можно задать дополнительные параметры:

1 outputDirectory Директория, в которую будут копироваться зависимости
2 overWriteReleases Флаг необходимости перезаписывания зависимостей при создании релиза
3 overWriteSnapshots Флаг необходимости перезаписывания неокончательных зависимостей, в которых присутствует SNAPSHOT
4 overWriteIfNewer Флаг необходимости перезаписывания библиотек с наличием более новых версий

Пример:


<configuration>
    <outputDirectory>
         ${project.build.directory}/lib/
    </outputDirectory>
    <overWriteReleases>false</overWriteReleases> <overWriteSnapshots>false</overWriteSnapshots> <overWriteIfNewer>true</overWriteIfNewer>
 </configuration>

По умолчанию <overWriteReleases> и <overWriteSnapshots> – false, для <overWriteIfNewer> – true.

Комментарии (37)
ЧТОБЫ ПОСМОТРЕТЬ ВСЕ КОММЕНТАРИИ ИЛИ ОСТАВИТЬ КОММЕНТАРИЙ,
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
21 ноября 2025
Я полагаю запоминать это на данном этапе не нужно. Цель данной лекции очевидно общее знакомство с maven.
Alexander Уровень 72
25 ноября 2025
Хочется в это верить)
Vlad128 Уровень 22
16 января 2025
Неужели новичку, сразу доверят собрку проекта, в компании?
Роман Уровень 88
23 сентября 2024
Эти две лекции предназначены для тех, кто уже работал с мэйвеном? Потому что для новичка они абсолютно бесполезны.
Ираклий Уровень 112
12 мая 2025
Мало того что бесполезны так это еще и запомнить в принципе фантастика
Drongo Уровень 2
16 апреля 2024
упрожнятся лучше в консоли или может посоветуете что?
Anonymous #3268884 Уровень 24
25 марта 2024
Для чего нужны все эти фазы, цели, плагины? Что это за сатанизм? ) Если в этом вопросе до сих пор что-то остается непонятным, то сейчас по-быстрому объясним. Итак, приступаем. Плагины и цели ---------------------------------- Плагины и цели (goals) - это по сути самое первое и самое основное, что нужно для того, чтобы пользоваться мэйвеном. Поскольку у мэйвена нет графического интерфейса, то для того, чтобы мэйвен совершил любое, хоть какое-то действие, нужно отдать мэйвену соответствующую команду через командную строку. Чтобы отдавать команды, нужно открыть командную строку и перейти в корневую директорию того проекта, с которым мы работаем. Общий вид этих команд выглядит так: mvn название-плагина:название-цели Тут вся суть заключается в том, что те действия, которые совершает мэйвен, он совершает с помощью тех или иных плагинов. Какие-то плагины нужно добавлять самому, если они вдруг понадобятся, но также есть целая куча плагинов, которые уже встроены в мэйвен по умолчанию. Каждый плагин может выполнять свои строго определенные действия. Соответственно, у каждого плагина есть свой список действий, которые он может выполнять. Эти действия называются целями, они же goals. У некоторых плагинов бывает только одна цель, а у каких-то плагинов их несколько. Поэтому любая команда состоит из названия плагина и названия одной из целей, которые есть у этого плагина. Попросту говоря, название конкретного плагина плюс название одной из его целей - это указание на то конкретное действие, которое совершит мавен, когда получит данную команду.
Anonymous #3268884 Уровень 24
25 марта 2024
Вот несколько примеров того, как выглядят команды: mvn install:install-file mvn dependency:analyze-duplicate mvn maven-checkstyle-plugin:check mvn dependency:list Что именно делают те или иные команды - это на джавараш рассказано подробно и понятно. Некоторые команды требуют еще указания всяких дополнительных параметров, примерно вот таким образом: mvn название-плагина:название-цели -Dпараметр=значение -Dпараметр2=значение2 -Dпараметр3=значение3 Причем все это нужно писать в одну строку, иначе команда не сработает. Не все плагины одинаково нужны и важны. Некоторые имеют какие-то совсем уж специфические цели, которые не факт, что когда-то понадобятся, а какие-то другие - наоборот строго необходимы для любой сборки любого самого примитивного проекта. Самые необходимые плагины, без которых не обойтись, уже имеются в мэйвене по умолчанию, а какие-то нужно добавлять самостоятельно, если они вдруг понадобились. Если какие-то плагины понадобились, то их нужно вписать в файл pom.xml, и тогда мэйвен их скачает, загрузит и начнет употреблять) То есть если для сборки проекта нужны особые действия, то нужно просто подобрать такой плагин, у которого в списке целей имеется нужная цель, совершающая именно те действия, которые внезапно понадобились. Чтобы добавить понадобившийся плагин, его нужно вписать в файл pom.xml после тега <build> Еще там же можно прописать всякие настройки для этого плагина.
Anonymous #3268884 Уровень 24
25 марта 2024
Циклы и фазы ---------------------------------- Все действия по сборке проекта выполняются в определенной последовательности. Эти последовательные действия объединяются в группы, а группы делятся на подгруппы. Группы называются жизненными циклами, а подгруппы в этих группах - фазами. Циклов всего три штуки: clean, default и site. В цикле клин удаляется всякая фигня из папки таргет, в цикле сайт создается документация, а вся сборка как таковая делается в цикле дефолт. Каждый из трех циклов делится на свои фазы. В цикле клин - три фазы, в цикле сайт - четыре. В цикле дефолт больше всего фаз - целых 23 штуки. Основные из них следующие: validate compile test package verify install deploy Между ними есть еще другие фазы, но эти - самые важные. Фазы - это группы действий. Не путай фазы с целями. Не путай, я сказал) Цель - это одно из действий одного из плагинов. А фаза - целая совокупность действий. Каждое действие можно запускать по отдельности, а можно запускать сразу всю фазу целиком. Мы помним, что для запуска одного действия служит вот такая команда: mvn название-плагина:название-цели А всю фазу целиком можно запустить вот так: mvn название-фазы Заметил, да? В середине двоеточия нет. При запуске такой команды будут выполнены все действия, привязанные к данной фазе, а перед этим будут еще выполнены все предыдущие фазы цикла. То есть, если запустил фазу compile, то перед ней будут сделаны все предыдущие, начиная с validate. В ходе каждой фазы будут по порядку сделаны все действия, которые привязаны к данной фазе. А какие действия привязаны к фазам? А какие привяжешь, такие и будут привязаны)
Anonymous #3268884 Уровень 24
25 марта 2024
То есть порядок фаз четко установлен, а какие действия будут совершаться в каждой фазе - это можно прописать самостоятельно. К некоторым фазам уже по умолчанию привязаны кое-какие действия, а к каким-то ничего не привязано, что пропишешь сам, то и будет выполняться. Например к фазе compile по умолчанию привязано выполнение цели compile плагина compiler. А к большинству фаз не привязано ничего до тех пор, пока сам не привяжешь. Что тебе нужно, то и прописывай. Хоть сразу штук двадцать разных действий в каждую фазу можешь вписать. В итоге, когда ты запускаешь фазу, то одной командой запускается целая куча действий, которые будут происходить в том порядке, в каком ты их прописал, и каждое из них будет происходить с теми настройками, которые ты прописал. А каким же образом можно привязать действия к фазам? Куда их прописывать? Привязка целей к фазам -------------------------------------------------------- А прописывать их нужно в файл pom.xml в тег <build>. Внутри этого тега пишется тег <plugins>, а внутри него тег <plugin>. Внутри тега <plugin> вписывается тот плагин, который тебе нужен, затем пишешь тег <executions>, а в нем - тег <execution>. Потом пишешь тег <phase>, в котором указываешь ту фазу, в которой хочешь запустить плагин, а затем в теге <goals> пишешь тег <goal>, и там указываешь, какую из целей данного плагина ты хочешь запустить. Потом в теге <configuration> пишешь дополнительные настройки этого плагина, если они нужны. Закрываешь тег </plugin>, закрыв перед этим предыдущие теги.
Anonymous #3268884 Уровень 24
25 марта 2024
Выглядит все это дело примерно вот так: <plugins> <plugin> <groupId> БЛА-БЛА-БЛА </groupId> <artifactId> НАЗВАНИЕ ПЛАГИНА </artifactId> <version> ЕГО ВЕРСИЯ </version> <executions> <execution> <phase> ФАЗА, В КОТОРОЙ НУЖНО ВЫПОЛНИТЬ ДЕЙСТВИЕ </phase> <goals> <goal> ЗАПУСКАЕМАЯ ЦЕЛЬ ПЛАГИНА </goal> </goals> </execution> </executions> <configuration> А ЗДЕСЬ ВСЯКИЕ НАСТРОЙКИ </configuration> </plugin> </plugins> Готово! Указанная цель указанного плагина встроена в указанную фазу. Теперь это действие будет автоматически запускаться при запуске данной фазы. Можешь встроить туда еще сотню других действий, каждое в отдельном теге <plugin>, и они все будут автоматически запускаться в том порядке, в котором вписаны. А в следующую фазу впиши еще сотню действий, каких хочешь. И можно будет запускать их все нажатием одной кнопки. Это как программирование, только мы пишем не программу для JVM на языке джава, а программу для мэйвена на языке xml.
Anonymous #3268884 Уровень 24
25 марта 2024
Теперь кратко резюмируем все вышесказанное. 1. Все действия, которые совершает мэйвен, он совершает при помощи плагинов. 2. Для запуска любого действия нужно указать название плагина и название одной из целей, которые есть у этого плагина. Любое действие - это плагин плюс одна из его целей. 3. Существует четко установленный порядок фаз. А какие действия будут происходить в этих фазах - это можно прописать самостоятельно. 4. Прописывать это нужно в файле pom.xml после тега <build>. Там можно указать: какие действия нужно совершить, в какой фазе их совершить, в каком порядке их выполнять, и с какими настройками они будут происходить. 5. Никогда не путаем цели и фазы. Кто-то путает, а ты не путай) Цель - это одно из тех действий, которые может совершить тот или иной плагин. А фаза - это совокупность тех целей, которые к ней привязаны.
Андрей Уровень 109
4 апреля 2024
отличный комментарий
Антон Уровень 115
23 октября 2024
Бутылку шампанского этому господину 🍾👍
Никита Уровень 109
17 декабря 2024
КТО ТЫ ВОИН?)😎
Anonymous #3268884 Уровень 24
29 декабря 2024
тот кто нифига не может понять, как пользоваться Редисом и Кафкой))
Даниил Уровень 35
12 февраля 2025
Спасибо тебе большое, добрый человек!!!
Владислав Уровень 87
16 апреля 2025
Снимаю шляпу.
Dima Makarov Уровень 42
10 августа 2023
А зачем вообще нужны эти goals нам? Они представляют какую-то ценность кроме как теоретических знаний?
2GAREN Уровень 46
26 октября 2023
Да, "цели" (goals) в Maven играют крайне важную роль и имеют практическое применение, а не только теоретическую ценность. В Maven, каждый плагин предоставляет набор задач, которые можно выполнить. Эти задачи и называются "целями". Когда вы запускаете Maven с определенной командой, например mvn compile, вы фактически запускаете "цель" compile плагина maven-compiler-plugin. Почему это важно: Контроль над процессом сборки: С помощью различных целей вы можете тонко настраивать процесс сборки вашего проекта. Например, вы можете запустить только компиляцию, тестирование или сборку пакета. Автоматизация: Цели позволяют автоматизировать различные этапы разработки, тестирования и развертывания вашего приложения. Гибкость: Вы можете создавать собственные плагины и цели для выполнения специфических для вашего проекта задач. Интеграция с CI/CD: Цели Maven часто используются в инструментах непрерывной интеграции и доставки (CI/CD) для автоматизации процессов сборки, тестирования и развертывания. Несколько примеров целей и их применения: mvn clean - удаляет папку target и все файлы сборки. mvn compile - компилирует исходные коды проекта. mvn test - запускает юнит-тесты. mvn package - упаковывает ваш проект в определенный формат (например, JAR или WAR). mvn install - устанавливает ваш пакет в локальный репозиторий Maven. Таким образом, цели в Maven представляют собой ключевой инструмент для управления жизненным циклом проекта и позволяют разработчикам эффективно и гибко управлять различными этапами разработки.
Anonymous #3268884 Уровень 24
25 марта 2024
Сорян, дружище, внесу небольшую поправку. То, что вы перечислили: mvn clean, mvn compile, mvn test и прочее - это все НЕ ЦЕЛИ. Это фазы. А в каждую фазу можно встроить сразу несколько целей, прописав их в пом-файл. Между фазой и целью есть небольшое отличие. Цель - это одно из тех действий, которые может совершить тот или иной плагин. А фаза - это совокупность тех целей, которые к ней привязаны. К каждой фазе может быть привязано несколько целей различных плагинов. А может быть не привязано ни одной. А может быть привязано много) Например: mvn dependency:analyze-duplicate или mvn maven-checkstyle-plugin:check или вот так mvn compiler:compile Это все команды запуска целей. По одной штуке в одной команде. А такая команда, как mvn package может запустить сразу десяток целей, которые будут встроены в фазу package Команды, которые запускают цели, и те команды, которые запускают целые фазы можно отличить чисто визуально. У команд, запускающих цели, в середине команды стоит двоеточие.
pk221 Уровень 12
14 июля 2023
самое крутое, читать уже работая))) когда сразу правишь текущий проект и дополняешь знания на практике, исправляя свои же костыли)😅
Виктор Уровень 40
7 сентября 2023
расскажи давно ли работаешь, как устроился, что еще использовал для изучения. А так рад за тебя).
pk221 Уровень 12
8 сентября 2023
Спасибо, устроился через стажировку от Школы21 изучать сам начал, а тут добиваю пробелы в знаниях и укладываю по полочкам))
Dimitrius Уровень 40
26 сентября 2023
Неужели тебе хватило знаний без данных разделов( Мавен, Хайбернет, Спринг, ШТТП. АПИ) чтобы тебя взяли на работу? Я уже больше года схожу с ума от количества информации т еще столько предстоит изучить, кошмар просто)))Такое чувство что никогда не устроюсь на работу!
pk221 Уровень 12
18 октября 2023
я начал путь со "Школы 21" - это проект по французской системе Ecole 42, и там учился 2 года, потом сам начал изучать Java и вышел на стажу в Сбер, после нее попал в штат. по знаниям был такой багаж: - Си (сборка в Make) - С++ (база + ООП) - Git - основы DevOps - основы тестирования вроде ничего не упустил. но я реккомендую по возможности устраиваться сразу, как получится, так как на парактике это совершенно другой уровень и скорость обучения уже будет и все эти пет проекты и листание книг покажутся детским садом.
Ольга Уровень 72 Expert
31 января 2024
Здорово! Удачи тебе в изучении нового)
Daniel Уровень 51
9 июня 2023
Понятно, что ничего не понятно.
Denis Rogov Уровень 1 Expert
27 марта 2023
М, пон
Николай Уровень 70 Expert
3 мая 2023
мега пон
Xelin Уровень 45
8 июня 2023
супер мега пон
Roockie Уровень 111 Expert
25 июня 2023
супер мега ультра пон
Андрей Уровень 51
10 сентября 2023
супер мега ультра гига пон
2GAREN Уровень 46
26 октября 2023
супер мега ультра гига пупер пон
24 ноября 2023
pom.xml
Anonymous #3268884 Уровень 24
25 марта 2024
Убить всех человеков! Слава роботам!
1 мая 2025
супер мега ультра гига пупер атомный... не пон