Maven-assembly-plugin: как использовать appendAssemblyId

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

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

вот код, который я использую для настройки maven-assembly-plugin плагин:

<plugin>
    <artifactId>
        maven-assembly-plugin
    </artifactId>
    <version>2.4</version>
    <executions>
      <execution>
        <id>dist-assembly</id>
        <phase>package</phase>
        <goals>
          <goal>single</goal>
        </goals>

        <configuration>
          <finalName>bso</finalName>
          <descriptorRefs>
            <descriptorRef>jar-with-dependencies</descriptorRef>
          </descriptorRefs>
          <finalName>helper-${project.version}</finalName>
          <appendAssemblyId>false</appendAssemblyId>
          <archive>
            <manifest>
              <mainClass>HelperMain<mainClass>
            </manifest>
          </archive>
        </configuration>

      </execution>
    </executions>
  </plugin>

Я appendAssemblyId to false иначе -jar-with-dependencies будет добавлено к окончательному имени, и я не вижу в этом необходимости. Опущение этого дает более чистое и простое в использовании имя файла.

когда я запускаю mvn integration-test затем я получаю следующие предупреждения:

[предупреждение] параметры конфигурации:' appendAssemblyId 'имеет значение false, а' классификатор ' отсутствует. Вместо прикрепления файла сборки: [...] / цель / помощник-5.0.0-снимок.jar, он станет файлом для основного артефакта проекта.

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

[предупреждение] замена существующего файла главного артефакта проекта: [...] / target / my.модуль-5.0.0-снимок.сосуд с файлом сборки: [...] / цель / помощник-5.0.0-снимок.Джар

есть две вещи, которые раздражают я:

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

  2. почему вообще появляется предупреждение о замене артефакта?

  3. кажется,classifier устарело почему предупреждение просит меня использовать его?

15
java maven maven-assembly-plugin

1 ответов

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

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

важно помнить, что этот артефакт прикрепленный к проекту: эта терминология полезно, когда проект установлен (с mvn install), развернутые (с mvn deploy) или отпущена (с maven-release-plugin). прикрепленный означает, что этот артефакт будет установлен при проект. Не все файлы, созданные во время сборки Maven (в основном, все под target папка); только файлы, которые были прикреплены. Таким образом, вы можете очень хорошо создать много файлов под target но есть один установлен артефакт.

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

в репозитории Maven каждый файл должен следовать одному и тому же соглашению об именах: artifactId-version(-classifier).type. Каждый вторичный артефакт будет иметь тот же GAV (group id, artifact id, version), что и основной артефакт, поэтому, если вы хотите поместить внутри Maven repo 1 основной артефакт и 1 прикрепленный артефакт (как это было бы для основной банки вместе с ее jar Javadoc и источниками JAR), вам нужно каким-то образом их различать. Что classifier предназначен для: отличать вторичные артефакты от основного артефакта.

давайте вернемся к вашему примеру. Ваш проект Maven, который jar упаковки, будет производить по умолчанию основной артефакт JAR называется my.module-5.0.0-SNAPSHOT.jar; по-прежнему по умолчанию этот основной JAR прикреплен к проекту (и готов к установке / развертыванию). Теперь вы настраиваете maven-assembly-plugin чтобы создать новый артефакт JAR (называемый helper-5.0.0-SNAPSHOT.jar но это действительно не имеет значения). Модуль сборки, по умолчанию,присоединяет к проекту артефакт, который он производит. Таким образом, вы получаете 2 прикрепленных артефакта

  1. имея тот же идентификатор артефакта my.module; тот факт, что файл на диск внутри target папка с именем helper для одного не имеет значения, только координаты GAV имеют значение
  2. имея ту же версию 5.0.0-SNAPSHOT
  3. имея ту же упаковку банки

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

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

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

если вы хотите убедить себя во всем этом, бегите mvn clean install на проекте и Проверьте свое местное РЕПО. Вы заметите, что только jar-with-dependencies артефакт будет установлен. Другой (главный артефакт)испарился.

вы также можете настроить <distributionManagement>:

<distributionManagement>
    <repository>
        <id>local-repo-test</id>
        <url>file://...</url>
    </repository>
</distributionManagement>

и вызвать mvn clean deploy. Затем вы можете проверить, что единственным развернутым артефактом будет jar-with-dependencies.

последнее примечание: да,classifier параметр плагина сборки устарел, потому что вы должны просто использовать идентификатор сборки в качестве классификатора.

26