76 votes

Exécuter l'objectif du plug-in Maven sur les modules enfants, mais pas sur le parent

Dans un environnement multi-projet de module, comment pouvez-vous spécifier que vous souhaitez exécuter un plugin but dans toute l'enfant-modules, mais pas sur le projet parent? Il est <pluginManagement>, mais qui ne définit la configuration de l'exécution, l'enfant modules auraient encore besoin d'référence plugin pour obtenir l'objectif exécutée:

[...] Cependant, cette configure uniquement les plugins qui sont référencées dans les plugins élément dans les enfants. (POM de Référence)

Toute autre façon d'atteindre cet objectif?

Mise à JOUR: j'ai essayé ce, selon les conseils de Pascal:

<!-- ... -->
<packaging>pom</packaging>
<modules>
  <module>child</module>
</modules>

<build>
  <plugins>
    <plugin>
      <artifactId>maven-jar-plugin</artifactId>
      <executions>
        <execution>
        <phase>integration-test</phase>
        <goals>
          <goal>jar</goal>
        </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>
<!-- ... -->

Cela va générer un .jar pour le projet parent, même si l' jar objectif est lié à l' integration-test de phase.

40voto

Pascal Thivent Points 295221

Selon le Défaut du Cycle de vie des Liaisons, les liaisons pour un emballage pom sont:

Défaut Du Cycle De Vie Des Liaisons - Emballage pom

package site:fixez-le descripteur de 
installer:installer 
déployer déployer déployer

Donc, si votre parent POM a un <packaging>pom<packaging> (ce devrait être le cas comme l'a fait remarquer dans un commentaire), et si vous liez vos plugins à d'autres phases que celles ci-dessus (voir le Cycle de vie de Référence pour une liste complète), ils ne seront pas exécutées lors de la compilation du POM parent.

(EDIT: Ma première réponse est tout simplement faux. Si vous liez un plugin objectif à une phase particulière, il sera déclenchée au cours de cette phase, indépendamment de l'emballage du projet. La valeur par Défaut du Cycle de vie des Liaisons qui n'ont rien à voir avec ça, ils sont juste valeur par défaut du cycle de vie des liaisons. Tout ce qui importe est de savoir si la phase à laquelle le plugin est liée est une partie de la construire lifecyle.)

Comme vous l'avez souligné, vous pouvez utiliser l' pluginManagement dans le pom parent pour la configuration du plugin, mais si vous voulez vraiment pour exécuter un plugin but chez les enfants de modules et pas dans le parent (vous pourriez avoir de bonnes raisons de le faire, mais la plupart du temps, les plugins ne pas avoir beaucoup d'effet sur un module avec un pom des emballages qui n'ont pas de contenu), vous aurez de référence des plugins dans l' plugins élément dans les enfants.

Appliqué à votre exemple, le parent pom.xml pourrait définir les spécifications suivantes:

<project>
  <packaging>pom</packaging>
  ...
  <modules>
    <module>child</module>
  </modules>
  ...
  <build>
    <pluginManagement>
      <plugins>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-jar-plugin</artifactId>
          <version>2.2</version>
          <executions>
            <execution>
              <id>my-execution-id</id>
              <phase>integration-test</phase>
              <goals>
                <goal>jar</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
        ...
      </plugins>
    </pluginManagement>
  </build>
  ...
</project>

Et dans chaque enfant, pom.xml, seuls les éléments suivants sont requis:

<project>
  ...
  <build>
    ...
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
      </plugin>
    </plugins>
    ...
  </build>
</project>

28voto

Mikhail Points 51

L'décrit solution de gestion des plugins est certainement corriger, mais dans certains cas, elle ne rentre pas. Supposons que vous souhaitez exécuter plusieurs jar:jar buts de l'enfant module configurés chacun avec ses propres paramètres (configuration) à chaque exécution. Ou, en général, lorsque vous ne voulez pas forcer l'enfant poms explicitement déclencher le plugin(s).

Dans ce cas, la solution qui a fonctionné pour moi a été de définir les exécutions dans le pom parent en vertu d'un profil spécifique, et l'ai activé seulement des enfants poms par exemple en vérifiant l'existence d'un fichier ou d'un bien:

<profile>
    <id>generate-dc</id>
    <activation>
        <file>
            <exists>src/main/assembly/some.xml</exists>
        </file>
    </activation>

Ensuite, les plugins ne sera pas exécutée dans le parent, mais sera exécuté dans tous les enfants si ceux qui contiennent le fichier, ou de définir une propriété.

11voto

Rafeeq Points 71

J'ai eu une exigence similaire d'exécuter des plugins dans l'enfant mais pas le POM parent. J'ai atteint cet objectif en indiquant <skip>true</skip> dans le POM parent.

l'entrée pom parent est en dessous

 <plugin>
    <groupId>eviware</groupId>
    <artifactId>maven-soapui-plugin</artifactId>
    <version>4.0.0</version>
    <inherited>false</inherited>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.8.2</version>
        </dependency>
    </dependencies> 
    <configuration>
        <skip>true</skip>
    </configuration>
</plugin> 
 

L'entrée pom du projet enfant est ci-dessous

 <plugins>
    <plugin>
        <groupId>eviware</groupId>
        <artifactId>maven-soapui-plugin</artifactId>
        <version>4.0.0</version>
        <configuration>
            <settingsFile>site-service-web/src/test/soapui/soapui-settings.xml</settingsFile>
            <projectFile>site-service-web/src/test/soapui/PodifiSite-soapui-project.xml</projectFile>
            <outputFolder>site-service-web/target/surefire-reports</outputFolder>
            <junitReport>true</junitReport>
            <exportwAll>true</exportwAll>
            <printReport>true</printReport>
        </configuration>
    </plugin>
</plugins>
 

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X