Configurer les plugins Maven pour rester ensemble

Question

J'ai un pom parent qui configure certains plugins

<pluginManagement>
   </plugins>
      <plugin>
         <artifactId>gmaven-plugin</artifactId>
         ...
      </plugin>
      <plugin>
         <artifactId>maven-resources-plugin</artifactId>
         ...
      </plugin>
      <plugin>
         <artifactId>cargo-maven2-plugin</artifactId>
         ...
      </plugin>
   </plugins>
</pluginManagement>

Et j'ai un arbre de poms représentant des tests d'intégration

A-\
   a1
   a2
B-\
   b1
   b2
C-\
   D-\
      d1
      d2

Dans chacun des produits a, b, d que je fais

<build>
   <plugins>
      <plugin>
         <artifactId>gmaven-plugin</artifactId>
      </plugin>
      <plugin>
         <artifactId>maven-resources-plugin</artifactId>
      </plugin>
      <plugin>
         <artifactId>cargo-maven2-plugin</artifactId>
      </plugin>
   </plugins>
</build>

Le problème est que je devrais ajouter un quatrième plug-in au processus de test d'intégration, par exemple mon plug-in personnalisé devra être déplacé. à travers tous les modules d'intégration et faire l'ajout manuel.

Vous pouvez me conseiller de supprimer <pluginManagement> pour permettre à tous les enfants de les utiliser implicitement. Oui, mais dans les produits qui ne sont que «pom», je ne veux rien faire des plugins: créez des ressources et mettez des répertoires de configuration jboss.

Je me demande s'il y a une sorte de

<pluginsBundle>
   <groupId>my.group</groupId>
   <artifactId>my-integration-test-bundle</artifactId>
   <plugins>
      <plugin>
         <artifactId>gmaven-plugin</artifactId>
      </plugin>
      <plugin>
         <artifactId>maven-resources-plugin</artifactId>
      </plugin>
      <plugin>
         <artifactId>cargo-maven2-plugin</artifactId>
      </plugin>
   </plugins>
</pluginsBundle>

Pour me permettre de l'utiliser comme

   <plugin>
      <groupId>my.group</groupId>
      <artifactId>my-integration-test-bundle</artifactId>
      <runOnce>true</runOnce>
   </plugin>

Je voudrais ajouter une option comme

<runOnce>true</runOnce>

pour pouvoir démarrer le serveur d'applications et déployer la cible une seule fois par lancement multiple.

Answer 1

Je ne connais pas de mécanisme qui fasse exactement ce dont vous avez besoin. Votre meilleur choix est de définir un pom parent avec les plugins définis dans la section build, plutôt que dans la section pluginManagement. Dans ce cas, la configuration du plugin sera toujours définie. L'ajout de la configuration à un profil dans le parent signifie que vous pouvez exercer un contrôle sur l'activation de ces plugins.

Un raffinement à considérer est que vous pouvez contrôler l'activation d'un profil par la présence ou l'absence d'un fichier. De cette façon, vous pouvez définir le profil dans le parent, mais le désactiver dans ce projet en raison de la présence du fichier de marqueur dans le parent. Les projets enfants n'auraient pas le fichier marqueur dans leur source, le profil serait donc activé pour ces projets. Vous pouvez inverser le comportement en utilisant missing au lieu de exists si cela convient à la majorité des projets.

<profile>
  <id>build</id>
  <activation>
    <file>
      <missing>src/main/resources/build.marker</missing>
      <!-- or if you want to enable the profile when the file does exist:
      <exists>src/main/resources/build.marker</exists-->
    </file>
  </activation>
  <build>
    </plugins>
      <plugin>
        <artifactId>gmaven-plugin</artifactId>
        ...
      </plugin>
      <plugin>
        <artifactId>maven-resources-plugin</artifactId>
        ...
      </plugin>
      <plugin>
        <artifactId>cargo-maven2-plugin</artifactId>
        ...
      </plugin>
    </plugins>
  </build>
</profile>

Vous pouvez également essayer d’écrire un plug-in personnalisé avec un cycle de vie qui exécute tous les mojos requis dans un cycle de vie forké. J'ai récemment répondu à une autre question avec des détails sur la procédure à suivre.

Une autre alternative consiste à écrire un autre plugin utilisant Maven shared-io pour appliquer un descripteur. pour le pom, ce descripteur peut définir une configuration arbitraire fusionnée dans le pom. Une autre réponse décrit comment cela peut être fait.

Answer 2

Si je comprends bien, il n’existe aucun moyen de déclarer un ensemble de plug-ins qui pourraient être utilisés ailleurs… mais il existe un héritage.

Qu'en est-il de la création d'un pom avec la déclaration <plugins> dans la section <build> et de l'héritage de ce pom dans vos projets de tests d'intégration? Cela semble faisable.