Как создать исполняемый JAR с помощью Maven

0 ∞ 1

  • Введение
  • Конфигурация
    • Ручная настройка
    • Apache Maven Assembly Plugin
    • Apache Maven Shade Plugin
    • One Jar Maven Plugin
    • Плагин Spring Boot Maven
    • Веб-приложение с исполняемым Tomcat
  • Заключение

В этой статье мы рассмотрим упаковку Maven- проекта в файл Jar. Выясним преимущества и недостатки каждого из подходов, применяемых для создания исполняемого файла.

Чтобы создать исполняемый файл jar, не требуются дополнительные зависимости. Нам нужно просто создать Java-проект Maven с одним классом и методом main(…).

В приведенном ниже примере мы создаем Java-класс ExecutableMavenJar. Для этого в файл pom.xml нужно добавить следующие элементы:

<modelVersion>4. 0.0</modelVersion>
<groupId>com.baeldung</groupId>
<artifactId>core-java</artifactId>
<version>0.1.0-SNAPSHOT</version>
<packaging>jar</packaging>

Удостоверьтесь в том, что в конфигурации задан тип jar. Теперь можно приступить к реализации каждого из подходов.

Для этого мы используем плагин maven-dependency-plugin. Сначала скопируем все необходимые зависимости в указанную папку:

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

Сначала мы задаем цель copy-dependencies, что указывает Maven скопировать эти зависимости в заданный outputDirectory.

В данном случае мы создадим папку с именем libs внутри каталога сборки проекта (обычно это папка target).

Затем мы создаем исполняемый файл jar с указанными путями к классам и со ссылкой на зависимости, скопированные на первом шаге:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <archive>
            <manifest>
                <addClasspath>true</addClasspath>
                <classpathPrefix>libs/</classpathPrefix>
                <mainClass>
                    org.baeldung.executable.ExecutableMavenJar
                </mainClass>
            </manifest>
        </archive>
    </configuration>
</plugin>

Наиболее важной частью приведенного выше кода является конфигурация manifest. В ней мы добавляем classpath со всеми зависимостями (папка libs/), а также предоставляем информацию о главном классе.

Преимущества и недостатки этого подхода:

  • Преимущества — прозрачный процесс, в рамках которого можно прописать каждый шаг.
  • Недостатки — зависимости находятся вне финального файла jar. Поэтому он будет работать только, если папка libs будет доступна и видима для jar-файла.

Плагин Apache Maven Assembly позволяет объединять выходные данные проекта вместе с зависимостями, модулями, документацией и другими файлами в единый пакет.

Основной целью в плагине сборки является single. Она используется для создания любых сборок. Остальные цели устарели и будут удалены в следующей версии плагина.

Рассмотрим конфигурацию, заданную в файле pom.xml:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-assembly-plugin</artifactId>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>single</goal>
            </goals>
            <configuration>
                <archive>
                <manifest>
                    <mainClass>
                        org.
 
 baeldung.executable.ExecutableMavenJar
                    </mainClass>
                </manifest>
                </archive>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
            </configuration>
        </execution>
    </executions>
</plugin>

Как и при ручной настройке, сначала нужно предоставить информацию о главном классе. Но плагин автоматически скопирует все необходимые зависимости в файл JAR .

В descriptorRefs мы указали имя, которое будет добавлено к имени проекта. В нашем случае – это core-java-jar-with-dependencies.jar.

  • Преимущества – зависимости хранятся внутри jar-файла.
  • Недостатки — упрощенный контроль упаковки артефакта. Например, нет поддержки перемещения классов.

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

Рассмотрим приведенную ниже конфигурацию:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<shadedArtifactAttached>true</shadedArtifactAttached>
<transformers>
 <transformer implementation=
 "org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
  <mainClass>org.baeldung.executable.ExecutableMavenJar</mainClass>
   </transformer>
            </transformers>
        </configuration>
        </execution>
    </executions>
</plugin>

В этой конфигурации <shadedArtifactAttached> отмечает все зависимости, которые должны быть упакованы в файл jar.

Затем нам нужно указать реализацию трансформатора. В текущем примере мы использовали стандартную версию. В конце задаем основной класс приложения.

Выходной файл получит название core-java-0.1.0-SNAPSHOT-shaded.jar, где core-java — это имя проекта. За ним следуют версия и имя плагина.

  • Преимущества — зависимости внутри jar-файла, расширенный контроль упаковки артефакта.
  • Недостатки — сложная конфигурация (особенно если необходимо использовать расширенные функции).

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

Рассмотрим приведенную ниже конфигурацию:

	<plugin>
    <groupId>com.jolira</groupId>
    <artifactId>onejar-maven-plugin</artifactId>
    <executions>
        <execution>
            <configuration>
                <mainClass>org.baeldung.executable.
                  ExecutableMavenJar</mainClass>
                <attachToBuild>true</attachToBuild>
                <filename>
                  ${project. build.finalName}.${project.packaging}
                </filename>
            </configuration>
            <goals>
                <goal>one-jar</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Сначала необходимо указать основной класс и прикрепить все зависимости сборки, используя для этого attachToBuild = true .

Также необходимо задать имя файла для вывода. Цель Maven — это one-jar.

В One Jar зависимости jar не будут расширены в файловую систему во время выполнения.

  • Преимущества — позволяет классам располагаться на верхнем уровне One Jar. Плагин поддерживает внешние jar и собственные библиотеки.
  • Недостатки – не обновляется с 2012 года.

Плагин позволяет упаковывать исполняемые архивы jar или war и запустить приложение «на месте». Он поддерживает Maven версии 3.2 или выше. Более подробное описание плагина доступно здесь.

Рассмотрим приведенную ниже конфигурацию:

	<plugin>
    <groupId>org. springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>repackage</goal>
            </goals>
            <configuration>
                <classifier>spring-boot</classifier>
                <mainClass>
                  org.baeldung.executable.ExecutableMavenJar
                </mainClass>
            </configuration>
        </execution>
    </executions>
</plugin>

Между Spring и другими плагинами есть два существенных отличия: цель выполнения называется repackage, а классификатор — spring-boot . Обратите внимание, что плагин можно использовать без Spring Boot.

  • Достоинства – зависимости располагаются внутри jar- файла, его можно запускать в любом доступном месте, улучшенный контроль упаковки артефакта, исключение зависимостей из jar-файла и упаковка war файлов.
  • Недостатки — добавляет ненужные классы, связанные с Spring и Spring Boot.

В последней части статьи мы рассмотрим упаковку автономного веб-приложения в jar-файл. Но для этого понадобится другой плагин.

<plugin>
    <groupId>org.apache.tomcat.maven</groupId>
    <artifactId>tomcat7-maven-plugin</artifactId>
    <version>2.0</version>
    <executions>
        <execution>
            <id>tomcat-run</id>
            <goals>
                <goal>exec-war-only</goal>
            </goals>
            <phase>package</phase>
            <configuration>
                <path>/</path>
                <enableNaming>false</enableNaming>
                <finalName>webapp.jar</finalName>
                <charset>utf-8</charset>
            </configuration>
        </execution>
    </executions>
</plugin>

Чтобы создать jar-файл, запустите man package, который создаст webapp. jar в каталоге target.

Чтобы запустить приложение, просто введите в консоли: java -jar target / webapp.jar и проверьте результат по адресу: localhost:8080/.

  • Преимущества — наличие одного файла, простота развертывания и запуска.
  • Недостатки — размер файла намного больше.

Обратите внимание на то, что это последняя версия данного плагина, поддерживающая сервер Tomcat7. Чтобы избежать ошибок, обязательно убедитесь в том, что для зависимости Servlets scope задано значение provided. Иначе во время выполнения jar-файла возникнет конфликт:

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <scope>provided</scope>
</dependency>

В этой статье мы рассмотрели несколько способов создания исполняемого jar-файла с помощью различных плагинов Maven. Полную реализацию этого руководства вы сможете найти в проектах, опубликованных на Github:

Исполняемый jar

Исполняемый war

Как проверить? Чтобы скомпилировать проект в исполняемый файл jar, запустите Maven с помощью команды mvn clean package.

Надеемся, что данная статья помогла разобраться в этой теме.

Вадим Дворниковавтор-переводчик статьи «How to Create an Executable JAR with Maven»

Пожалуйста, оставьте ваши мнения по текущей теме материала. Мы очень благодарим вас за ваши комментарии, дизлайки, отклики, лайки, подписки!

Курс JSP & Servlets — Лекция: Продвинутая сборка Maven-проекта

1.1 Список плагинов для сборки в Maven

Сборка в Maven может быть настроена очень гибко. Разработчики Maven специально создали десятки плагинов, используя которые можно очень гибко настраивать различные сборки. Самые популярные из них приведены в таблице ниже:

ПлагинОписание
1maven-compiler-pluginУправляет Java-компиляцией
2maven-resources-pluginУправляет включением ресурсов в сборку
3maven-source-pluginУправляет включением исходного кода в сборку
4maven-dependency-pluginУправляет процессом копирования библиотек зависимостей
5maven-jar-pluginПлагин для создания итогового jar-файла
6maven-war-pluginПлагин для создания итогового war-файла
7maven-surefire-pluginУправляет запуском тестов
8buildnumber-maven-pluginГенерирует номер сборки

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

1.2 Плагин компиляции maven-compiler-plugin

Самый популярный плагин, позволяющий управлять версией компилятора и используемый практически во всех проектах, – это компилятор maven-compiler-plugin. У него имеются настройки по умолчанию, однако практически в каждом проекте их нужно задать заново.

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

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.2</version>
    <configuration>
        <source>1.11</source>
        <target>1.13</target>
        <encoding>UTF-8</encoding>
    </configuration>
</plugin>

В примере выше мы задаем три параметра Java-компилятора: source, target и encoding.

Параметр source позволяет нам задать версию Java для наших исходников. Параметр target – версию Java-машины, под которую нужно скомпилировать классы. Если версия кода или Java-машины не задана, то по умолчанию используется параметр 1.3

Наконец параметр encoding позволяет указать кодировку Java-файлов. Мы указали UTF-8. Сейчас практически все исходники хранятся в кодировке UTF-8. Но если этот параметр не указан, то выберется текущая кодировка операционной системы. Для Windows – это кодировка Windows-1251.

Также бывают случаи, когда компьютер, на котором производится сборка имеет несколько установленных версий Java: для сборки разных модулей и/или разных проектов. В этом случае в переменной JAVA_HOME может быть указан только путь к одной из них.

Кроме того, бывают разные реализации Java-машины: OpenJDK, OracleJDK, Amazon JDK. И чем больше проект, тем сложнее его структура. Но вы можете явно задать плагину путь к компилятору javac с помощью тега . Его добавили специально на этот случай.

Плагин maven-compiler-plugin имеет две цели (goals):

  • compiler:compile – компиляция исходников, по умолчанию связана с фазой compile
  • compiler:testCompile – компиляция тестов, по умолчанию связана с фазой test-compile.

Также можно указать список аргументов, которые будут переданы javac-компилятору в командной строке:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.2</version>
    <configuration>
        <compilerArgs>
            <arg>-verbose</arg>
            <arg>-Xlint:all,-options,-path<arg>
        </compilerArgs>
    </configuration>
</plugin>

1.3 Плагин создания jar-файла maven-jar-plugin

Если вы захотите собрать с помощью Maven свою собственную jar-библиотеку, то вам понадобится плагин maven-jar-plugin. Этот плагин умеет много полезных вещей.

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

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <version>2.4</version>
    <configuration>
        <includes>
            <include>**/properties/*</include>
        </includes>
        <archive>
           <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
        </archive>
    </configuration>
</plugin>

Во-первых, с его помощью можно указать, какие файлы попадут в библиотеку, а какие – нет. С помощью тегов <include> в секции <includes> можно задать список директорий, чей контент нужно добавить в библиотеку.

Во-вторых, каждая jar-библиотека должна иметь манифест (файл MANIFEST.MF). Плагин сам положит его в нужное место библиотеки, вам всего лишь нужно указать, по какому пути его взять. Для этого используется тег <manifestFile>.

И наконец, плагин может самостоятельно сгенерировать манифест. Для этого вместо тега <manifestFile> вам нужно добавить тег <manifest> и в нем указать данные для будущего манифеста. Пример:

<configuration>
    <archive>
        <manifest>
            <addClasspath>true</addClasspath>
            <classpathPrefix>lib/</classpathPrefix>
            <mainClass>ru.javarush.MainApplication</mainClass>
        </manifest>
    </archive>
</configuration>

Тег <addClasspath> определяет необходимость добавления в манифест CLASSPATH.

Тег <classpathPrefix> позволяет дописывать префикс (в примере lib) перед каждым ресурсом. Определение префикса в <classpathPrefix> позволяет размещать зависимости в отдельной папке.

Да, вы можете размещать библиотеки внутри другой библиотеки. И вас ждет много сюрпризов, когда вам нужно будет куда-то передать путь к properties-файлу, который находится в jar-библиотеке, которая находится в jar-библиотеке.

И наконец, тег <mainClass> указывает на главный исполняемый класс. “Что за главный исполняемый класс?”, – спросите вы. А все дело в том, что Java-машина может запустить программу, которая задана не только Java-классом, но и jar-файлом. И именно для такого случая нужен главный стартовый класс.

1.4 Плагин генерации номера сборки buildnumber-maven-plugin

Очень часто jar-библиотеки и war-файлы включают в себя информацию с названием проекта и его версией, а также версией сборки. Мало того, что это полезно для управления зависимостями, так еще и упрощает тестирование: понятно, в какой версии библиотеки ошибка исправлена, а в какой – добавлена.

Чаще всего эту задачу решают так – создают специальный файл application.properties, который содержит всю нужную информацию и включают его в сборку. Так же можно настроить сценарий сборки так, чтобы данные из этого файла перекочевывали в MANIFEST.MF и тому подобное.

Но что самое интересное, так это то, что у Maven есть специальный плагин, который может генерировать такой application.properties файл. Для этого нужно создать такой файл и заполнить его специальными шаблонами данных. Пример:

# application.properties
app.name=${pom.name}
app.version=${pom.version}
app.build=${buildNumber}

Значения всех трех параметров будут подставляться на этапе сборки.

Параметры pom.name и pom.version будут браться прямо из pom.xml. А для генерации уникального номера сборки в Maven есть специальный плагин – buildnumber-maven-plugin. Смотрите пример ниже:

<packaging>war</packaging>
<version>1.0</version>
<plugins>
    <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>buildnumber-maven-plugin</artifactId>
        <version>1. 2</version>
        <executions>
            <execution>
                <phase>validate</phase>
                <goals>
                    <goal>create</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <revisionOnScmFailure>true</revisionOnScmFailure>
            <format>{0}-{1,date,yyyyMMdd}</format>
            <items>
                 <item>${project.version}</item>
                 <item>timestamp</item>
            </items>
        </configuration>
    </plugin>
</plugins>

В примере выше происходят три важные вещи. Во-первых, указан сам плагин для задания версии сборки. Во-вторых, указано, что он будет запускаться во время фазы validate (самая первая фаза) и генерировать номер сборки – ${buildNumber}.

И в-третьих, указан формат этого номера сборки, который склеивается из нескольких частей. Это версия проекта project.version и текущее время заданное шаблоном. Формат шаблона задается Java-классом MessageFormat.

Подключаемый модуль Apache Maven JAR – jar:jar

Полное имя :

org.apache.maven.plugins:maven-jar-plugin:3.3.0:jar

Описание :

Создать JAR из текущего проекта.

Атрибуты :

  • Для выполнения требуется проект Maven.
  • Требуется разрешение зависимостей артефактов в области: среда выполнения .
  • Цель является потокобезопасной и поддерживает параллельные сборки.
  • По умолчанию привязывается к фазе жизненного цикла: package .

Обязательные параметры

Имя Тип С Описание
<каталог классов> Файл - Каталог, содержащий классы и файлы ресурсов, которые должны быть упакован в JAR.
Значение по умолчанию: : ${project.build.outputDirectory} .
Файл - Каталог, содержащий сгенерированный JAR.
Значение по умолчанию : ${проект.сборка.каталог} .

Дополнительные параметры

Имя Тип С Описание
<архив> MavenArchiveConfiguration - Используемая конфигурация архива. См. Мейвен Справочник архиватора.
<классификатор> Строка - Классификатор для добавления к сгенерированному артефакту. Если дан, артефакт будет прикреплен как дополнительный артефакт. Если не дано это будет создать основной артефакт, который является поведением по умолчанию. Если вы попытаетесь чтобы сделать это во второй раз без использования классификатора, сборка будет неудача.
<исключает> Строка[] - Список файлов для исключения. Задается как шаблоны наборов файлов, которые относительно входного каталога, содержимое которого упаковывается в JAR.
логический - Требовать от подключаемого модуля jar создать новый JAR, даже если ни один из содержание, кажется, изменилось. По умолчанию этот плагин смотрит на посмотрите, существует ли выходная банка и не изменились ли входные данные. Если эти условия верны, плагин пропускает создание jar. Этот не работает, когда другие плагины, такие как maven-shade-plugin, настроен на постобработку jar. Этот плагин не может обнаружить постобработку, и таким образом оставляет баночку с постобработкой на месте. Это может привести к сбоям, когда эти плагины не ожидают найти собственный вывод в качестве входа. Установите этот параметр на правда чтобы избежать этих проблем, заставив этот плагин воссоздать банку каждый раз.
Начиная с 3.0.0 свойство было переименовано из jar.forceCreation для maven.jar.forceCreation .
Значение по умолчанию : ложь .
Свойство пользователя : maven.jar.forceCreation .
<включает> Строка[] - Список файлов для включения. Задается как шаблоны наборов файлов, которые относительно входного каталога, содержимое которого упаковывается в JAR.
Строка 3.2.0 Временная метка для воспроизводимых записей выходного архива, форматированных как ISO 8601 расширенное смещение даты и времени (например, в формате UTC, таком как ‘2011-12-03T10:15:30Z’ или со смещением ‘2019-10-05T20:37:42+06:00’) или как целое число, представляющее секунды с эпохи (например, SOURCE_DATE_EPOCH).
Значение по умолчанию: : ${project.build.outputTimestamp} .
логический - Пропустить создание пустых архивов.
Значение по умолчанию : ложь .
логический - Устарело. Для версии 3.0.0 этот параметр определен здесь только для того, чтобы построить, если вы используете его!
Значение по умолчанию : ложь .
Свойство пользователя: : jar.useDefaultManifestFile .

Сведения о параметрах

<архив>

Используемая конфигурация архива. См. Мейвен Справочник архиватора.

  • Тип : org.apache.maven.archiver.MavenArchiveConfiguration
  • Требуется : Нет
<каталог классов>

Каталог, содержащий классы и файлы ресурсов, которые должны быть упакован в JAR.

  • Тип : java.io.Файл
  • Требуется : Да
  • По умолчанию : ${project.build.outputDirectory}
<классификатор>

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

  • Тип : java.lang.String
  • Требуется : Нет
<исключает>

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

  • Тип : java.lang.String[]
  • Требуется : №
Требовать от подключаемого модуля jar создания нового JAR, даже если ни один из содержание, кажется, изменилось. По умолчанию этот плагин смотрит на посмотрите, существует ли выходная банка и не изменились ли входные данные. Если эти условия верны, плагин пропускает создание jar. Этот не работает, когда другие плагины, такие как maven-shade-plugin, настроен на постобработку jar. Этот плагин не может обнаружить постобработку, и таким образом оставляет баночку с постобработкой на месте. Это может привести к сбоям, когда эти плагины не ожидают найти собственный вывод в качестве входа. Установите этот параметр на правда чтобы избежать этих проблем, заставив этот плагин воссоздать банку каждый раз.
Начиная с 3.0.0 свойство было переименовано из jar.forceCreation для maven.jar.forceCreation .

  • Тип : логический
  • Требуется : Нет
  • Свойство пользователя : maven.jar.forceCreation
  • По умолчанию : ложь
<включает>

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

  • Тип : java.lang.String[]
  • Требуется : Нет

Каталог, содержащий сгенерированный JAR.

  • Тип : java.io.File
  • Требуется : Да
  • По умолчанию : ${project.build.directory}

Временная метка для воспроизводимых записей выходного архива, форматированных как ISO 8601 расширенное смещение даты и времени (например, в формате UTC, таком как ‘2011-12-03T10:15:30Z’ или со смещением ‘2019-10-05T20:37:42+06:00’) или как целое число, представляющее секунды с эпохи (например, SOURCE_DATE_EPOCH).

  • Тип : java. lang.String
  • Начиная с : 3.2.0
  • Требуется : Нет
  • По умолчанию : ${project.build.outputTimestamp}

Пропустить создание пустых архивов.

  • Тип : логический
  • Требуется : Нет
  • По умолчанию : ложь

Устарело. Для версии 3.0.0 этот параметр определен здесь только для того, чтобы построить, если вы используете его!

Использование этого свойства приведет к сбою сборки, поскольку оно было удалено. из конфигурации плагина. Увидеть майора Версия Обновление до версии 3.0.0 для плагина.

  • Тип : логический
  • Требуется : Нет
  • Свойство пользователя : jar. useDefaultManifestFile
  • По умолчанию : ложь

Создайте Fat Jar с подключаемым модулем Maven и включите все зависимости

Maven — один из наиболее часто используемых инструментов для разработки приложений Java.

Упаковка Maven создаст файл Jar без зависимостей.

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

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

Maven предоставляет различные способы создания Fat jar:

Плагин сборки Maven:

Добавьте приведенный ниже плагин Maven в файл pom. xml:

org.apache.maven.pluginsmaven-assembly-plugin2.4.1jar-with-dependenciesorg.sample.Applicationmake-assemblypackagesingle

Примечание: если в проекте нет основного класса, то раздел архива можно опустить.

descriptorRef — это имя, которое будет добавлено к имени пакета.

Фаза используется для указания, когда должна выполняться эта цель maven, предлагается указать пакет, потому что, когда мы вызываем пакет mvn, эти jar-файлы со всеми зависимостями также будут созданы.

Maven оказался полезным инструментом, необходимым для разработки приложений JAVA.

Посетите нас и получите обширные знания о разработке исполняемых файлов Jar.

Свяжитесь с нами

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

Функция перемещения классов не поддерживается в вышеуказанном подключаемом модуле.

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

Maven-Shade-Plugin:

org.apache.maven.pluginsmaven-shade-plugin3.2.2packageShadeorg.sample.plexus.utilorg.shaded.sample.plexus.utilorg.sample.plexus. пот.

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

Допустим, если файл jar содержит 10 пакетов, но мы используем только один пакет, то вместо исключения 9 пакетов включить 1 пакет.

Мы можем использовать тег включения, аналогичный исключению.

Просмотрите толстую банку:

Выполните следующую команду, чтобы просмотреть структуру папок толстой банки:

jar tf target\magellan-connector-msexchange-online-graph-cmis-1.0.0-SNAPSHOT-jar-with-dependencies. jar

Также доступны сторонние библиотеки для подготовки толстой банки, такие как плагин maven с одной банкой и т. Д.

МЕТА-ИНФ/ META-INF/MANIFEST.MF орг/ орг/апач/ орг/апач/химия/ org/apache/химия/opencmis/ org/apache/химия/opencmis/сервер/ org/apache/химия/opencmis/сервер/поддержка/ org/apache/химия/opencmis/сервер/поддержка/фильтр/ org/apache/химия/opencmis/сервер/поддержка/запрос/ META-INF/ЗАВИСИМОСТИ МЕТА-ИНФ/ЛИЦЕНЗИЯ META-INF/УВЕДОМЛЕНИЕ org/apache/химия/opencmis/сервер/поддержка/CmisServiceWrapper.класс org/apache/химия/opencmis/сервер/поддержка/фильтр/JsonPrettyPrinter.class org/apache/chemistry/opencmis/server/support/filter/LoggingFilter$LoggingInputStream.class org/apache/chemistry/opencmis/server/support/filter/LoggingFilter$LoggingOutputStream.class org/apache/chemistry/opencmis/server/support/filter/LoggingFilter$LoggingRequestWrapper.class org/apache/chemistry/opencmis/server/support/filter/LoggingFilter$LoggingResponseWrapper.class org/apache/chemistry/opencmis/server/support/filter/LoggingFilter. class org/apache/химия/opencmis/сервер/поддержка/запрос/AbstractPredicateWalker.class org/apache/химия/opencmis/сервер/поддержка/запрос/CalendarHelper.class ….. ком/открытый текст/ com/opentext/коннекторы/ com/opentext/connectors/msexchangeonlinegraph/ com/opentext/connectors/msexchangeonlinegraph/аннотации/ com/opentext/connectors/msexchangeonlinegraph/cmis/ com/opentext/connectors/msexchangeonlinegraph/cmis/apiutils/ com/opentext/connectors/msexchangeonlinegraph/cmis/домен/ com/opentext/connectors/msexchangeonlinegraph/cmis/impl/ com/opentext/connectors/msexchangeonlinegraph/cmis/objects/ com/opentext/connectors/msexchangeonlinegraph/cmis/typedef/ com/opentext/connectors/msexchangeonlinegraph/cmis/utils/ com/opentext/connectors/msexchangeonlinegraph/annotations/ConnectorCmisService.class com/opentext/connectors/msexchangeonlinegraph/cmis/apiutils/CommonApi.class com/opentext/connectors/msexchangeonlinegraph/cmis/apiutils/ConversationContainer.class com/opentext/connectors/msexchangeonlinegraph/cmis/apiutils/FolderContainer.

No related posts.