Maven-assembly-plugin: comment utiliser appendAssemblyId

j'ai un projet Maven multi-modules et dans un module Je veux créer deux artefacts pendant la construction:

  • l'Artéfact principal qui est une bibliothèque jar dont certains des autres modules dépendront.
  • un fichier JAR exécutable qui exécute certaines fonctions d'aide. Aucun autre module ne dépend de cela et son seul but pour l'utilisateur de l'exécuter manuellement dans certaines situations.

voici le code que j'utilise pour configurer le plugin 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>

je mets appendAssemblyId à false parce que sinon -jar-with-dependencies sera ajouté au nom final et je ne vois pas la nécessité. Omettre cela donne un nom de fichier plus propre et plus facile à utiliser.

quand j'exécute mvn integration-test alors je reçois les avertissements suivants:

[WARNING] Options de Configuration: 'appendAssemblyId' est réglé à faux, et "classificateur" est manquant. Au lieu de joindre le fichier d'assemblage: [...]/cible/aide-5.0.0-INSTANTANÉ.jar, ça deviendra le fichier de l'artefact du projet principal.

NOTE: Si plusieurs descripteurs ou descripteurs-formats sont fournis pour ce projet, la valeur de ce fichier sera non déterministe!

[AVERTISSEMENT] Remplacement de pré-existants principal du projet-artefact fichier: [...]/cible/ma.module-5.0.0-SNAPSHOT.pot avec le fichier d'assemblage: [...]/cible/aide-5.0.0-INSTANTANÉ.jar

il y a deux choses qui m'irritent:

  1. Malgré le fait que l'avertissement prétend qu'il va remplacer mon.module-5.0.0-SNAPSHOT.pot avec de l'aide-5.0.0-INSTANTANÉ.jar il ne le fait pas réellement et lorsque la construction a terminé les deux fichiers ont encore des tailles différentes.

  2. pourquoi l'avertissement au sujet du remplacement de l'artefact apparaître à tous?

  3. Il semble que classifier est obsolète, pourquoi ne l'avertissement me demander de l'utiliser?

15
demandé sur Tunaki 2016-07-20 16:34:51

1 réponses

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

récapitulons. Un projet Maven qui n'est pas de type pom produira toujours, par défaut, ce qu'on appelle un Artéfact principal. Pour un bocal, cet artéfact est le résultat de l'empaquetage des sources compilées dans un bocal; pour une guerre, il est le résultat de la construction de l'application web.

ce qui est important de se rappeler 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 libéré (avec maven-release-plugin ). Attaché signifie que cet artefact sera installé / déployées / libéré lorsque le projet est. Tous les fichiers générés lors d'une construction Maven (essentiellement, tout ce qui se trouve dans le dossier target ) ne le sont pas; seuls les fichiers qui y étaient attachés. En tant que tel, vous pouvez très bien créer beaucoup de fichiers sous target mais avoir un seul artefact installé.

à côté de cet artefact principal, vous pouvez vouloir que votre construction produise d'autres artefacts à installer ou à déployer. C'est le concept d'artefacts additionnels ou secondaires attachés. Les principaux exemples sont le Javadoc ou les sources: généralement quand un projet est publié, son Javadoc et ses sources sont aussi. Et c'est là que la notion classifier prend son envol .

dans un Repository Maven, chaque fichier doit suivre la même convention de nommage: artifactId-version(-classifier).type . Chaque artefact secondaire aura le même GAV (Groupe id, artefact id, version) que l'artefact principal donc si vous voulez mettre à l'intérieur D'un Maven repo 1 Artéfact principal et 1 artéfact attaché (comme ce serait le cas pour un pot principal avec ses sources de Javadoc et de pot), vous avez besoin d'un certain moyen de les distinguer. Ce qui est ce que le classifier est pour: distinguer les Artéfacts secondaires de la main artefact.

revenons à votre exemple maintenant. Votre projet Maven, qui est d'emballage jar , produira par défaut un artéfact de pot principal appelé my.module-5.0.0-SNAPSHOT.jar ; toujours par défaut, ce pot principal est attaché au projet (et prêt à être installé / déployé). Maintenant, vous configurez 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 D'assemblage, par défaut, attache au projet l'artefact qu'il produit . Donc vous finissez avec 2 artefacts attachés

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

et aucun classificateur pour les distinguer. C'est ce qui soulève l'avertissement: vous finissez par attacher au projet un artefact secondaire qui remplace effectivement 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 parce que
  2. partagent les mêmes coordonnées donc seulement 1 survivra.

c'est celui produit par le Plugin D'assemblage qui va gagner le conflit, et remplacer l'artefact principal attaché.

si vous voulez vous convaincre de tout cela, lancez mvn clean install sur le projet et vérifiez votre rapport local. Vous remarquerez que seul l'artefact jar-with-dependencies sera installé. L'autre (l'objet) est allé hop.

vous pouvez également configurer un <distributionManagement> : 

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

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

note Finale: Oui, le classifier paramètre de l'Assemblée Plugin est obsolète, parce que vous devriez utiliser l'assemblée id en tant que classificateur.

26
répondu Tunaki 2017-05-23 12:18:24