web-dev-qa-db-fra.com

maven-Assembly-plugin: Comment utiliser appendAssemblyId

J'ai un projet Maven multi-module et dans un module, je veux créer deux artefacts pendant la construction:

  • L'artefact principal qui est une bibliothèque JAR dont dépendront certains des autres modules.
  • Un fichier jar exécutable qui exécute certaines fonctions d'assistance. Aucun autre module n'en dépend et il est uniquement destiné à être exécuté manuellement par l'utilisateur dans certaines situations.

Voici le code que j'utilise pour configurer le maven-Assembly-plugin brancher:

<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>

Je configure appendAssemblyId sur false car sinon -jar-with-dependencies sera ajouté au nom définitif et je n'en vois pas la nécessité. L'omission donne un nom de fichier plus propre et plus facile à utiliser.

Quand je lance mvn integration-test puis je reçois les avertissements suivants:

[AVERTISSEMENT] Options de configuration: 'appendAssemblyId' est défini sur false et 'classifier' est manquant. Au lieu de joindre le fichier d'assemblage: [...]/target/helper-5.0.0-SNAPSHOT.jar, il deviendra le fichier de l'artefact principal du projet.

REMARQUE: si plusieurs descripteurs ou formats de descripteurs sont fournis pour ce projet, la valeur de ce fichier ne sera pas déterministe!

[AVERTISSEMENT] Remplacement du fichier d'artefact principal du projet préexistant: [...]/target/my.module-5.0.0-SNAPSHOT.jar par le fichier d'assemblage: [...]/target/helper-5.0.0- SNAPSHOT.jar

Il y a deux choses qui m'irritent:

  1. Malgré le fait que l'avertissement prétend qu'il remplacera my.module-5.0.0-SNAPSHOT.jar par helper-5.0.0-SNAPSHOT.jar, il ne le fait pas réellement et lorsque la génération est terminée, les deux fichiers ont toujours des tailles différentes.

  2. Pourquoi l'avertissement concernant le remplacement de l'artefact apparaît-il du tout?

  3. Il semble que classifier soit obsolète pourquoi l'avertissement me demande-t-il de l'utiliser?

javamavenmaven-assembly-plugin
21
lanoxx

C'est parce que vous interprétez mal les avertissements.

Résumons. Un projet Maven qui n'est pas de type pom produira toujours, par défaut, ce qu'on appelle un artefact principal. Pour un JAR, cet artefact est le résultat de l'empaquetage des sources compilées dans un JAR; pour une GUERRE, c'est le résultat de la construction de l'application web.

Ce qui est important à retenir est que cet artefact est attaché au projet: cette terminologie est utile lorsque le projet est installé (avec mvn install ), déployé (avec mvn deploy) ou publié (avec maven-release-plugin). Attaché signifie que cet artefact sera installé/déployé/publié lorsque le projet est. Tous les fichiers générés lors d'une génération Maven (en gros, tout ce qui se trouve sous le dossier target) ne le sont pas; seuls les fichiers joints. En tant que tel, vous pouvez très bien créer de nombreux fichiers sous target mais avoir un seul artefact installé.

Parallèlement à cet artefact principal, vous souhaiterez peut-être que votre génération produise d'autres artefacts à installer ou à déployer. C'est le concept d'artefacts attachés supplémentaires ou secondaires. Les principaux exemples sont le Javadoc ou les sources: généralement lorsqu'un projet est publié, son Javadoc et ses sources le sont également. Et c'est là que la notion classifier entre en je .

Dans un référentiel Maven, chaque fichier doit suivre la même convention de dénomination: artifactId-version(-classifier).type. Chaque artefact secondaire aura le même GAV (identifiant de groupe, id d'artefact, version) que l'artefact principal, donc si vous voulez mettre à l'intérieur d'un dépôt Maven 1 artefact principal et 1 artefact attaché (comme ce serait le cas pour un JAR principal le long avec ses sources JAR Javadoc et JAR), vous avez besoin d'un moyen de les distinguer. C'est à cela que sert le classifier: distinguer les artefacts secondaires de l'artefact principal.

Revenons maintenant à votre exemple. Votre projet Maven, qui est d'un emballage jar, produira par défaut un artefact JAR principal appelé my.module-5.0.0-SNAPSHOT.jar; toujours par défaut, ce JAR principal est attaché au projet (et prêt à être installé/déployé). Vous configurez maintenant le maven-Assembly-plugin Pour créer un nouvel artefact JAR (appelé helper-5.0.0-SNAPSHOT.jar Mais cela n'a vraiment pas d'importance). Le plugin Assembly, par défaut, attache au projet l'artefact qu'il produit . Vous vous retrouvez donc avec 2 artefacts attachés

  1. ayant le même identifiant d'artefact de my.module; le fait que le fichier sur le disque à l'intérieur du dossier target soit nommé helper pour l'un n'est pas pertinent, seules les coordonnées GAV comptent
  2. ayant la même version de 5.0.0-SNAPSHOT
  3. ayant le même emballage de JAR

et aucun classificateur pour les distinguer. C'est ce qui déclenche l'avertissement: vous finissez par attacher au projet un artefact secondaire qui remplace efficacement le principal, simplement parce qu'il a les mêmes coordonnées. Le résultat est donc:

  1. Les deux fichiers ayant des noms différents sur le disque à l'intérieur de target, mais cela n'est pas pertinent car
  2. Les deux partagent les mêmes coordonnées, donc seulement 1 survivra.

C'est celui produit par le plugin Assembly qui va gagner le conflit et remplacer l'artefact principal attaché.

Si vous voulez vous convaincre de tout cela, exécutez mvn clean install Sur le projet et vérifiez votre dépôt local. Vous remarquerez que seul l'artefact jar-with-dependencies Sera installé. L'autre (l'artefact principal) est allé pouf.

Vous pouvez également configurer un <distributionManagement>:

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

et appelez mvn clean deploy. Vous pouvez ensuite vérifier que le seul artefact déployé sera le jar-with-dependencies.

Remarque finale: Oui, le paramètre classifier du plugin d'assemblage est déconseillé, car vous devez simplement utiliser l'ID d'assembly comme classificateur.

34
Tunaki