Ignorer un sous-module lors d'une construction Maven


160

Nous avons besoin de pouvoir sauter un sous-module dans certains environnements.

Le module en question contient des tests d'intégration et prend une demi-heure à s'exécuter. Nous souhaitons donc l'inclure lors de la construction sur le serveur CI, mais lorsque les développeurs créent localement (et que les tests sont exécutés), nous voulons ignorer ce module.

Existe-t-il un moyen de faire cela avec un paramètre de profil? J'ai fait quelques recherches sur Google et regardé les autres questions / réponses ici et je n'ai pas trouvé de bonne solution.

Je suppose qu'une option est de supprimer pom.xmlentièrement ce sous-module du parent et d'ajouter simplement un autre projet sur notre serveur CI pour simplement créer ce module.

Suggestions?


Pourquoi pas Maven Way? C'est une revendication parfaitement valable pour moi.
MaDa

Hmm. Maintenant, je ne peux pas trouver les endroits où les gens semblaient s'opposer à cela ... j'ai donc mis à jour ma question initiale pour supprimer ma déclaration selon laquelle cela ne semble pas être "The Maven Way".
denishaskin

Réponses:


149

Bien sûr, cela peut être fait à l'aide de profils. Vous pouvez faire quelque chose comme ce qui suit dans votre pom.xml parent.

  ...
   <modules>
      <module>module1</module>
      <module>module2</module>  
      ...
  </modules>
  ...
  <profiles>
     <profile>
       <id>ci</id>
          <modules>
            <module>module1</module>
            <module>module2</module>
            ...
            <module>module-integration-test</module>
          </modules> 
      </profile>
  </profiles>
 ...

Dans votre CI, vous exécuteriez maven avec le ciprofil, c'est-à-diremvn -P ci clean install


4
Excellente réponse! Je ne sais pas pourquoi j'ai eu tant de mal à trouver cela dans les documents Maven. La seule suggestion que je ferais est que parce que je préfère que les tests d'intégration soient exécutés par défaut, j'ai ajouté activeByDefaultà ce profil, puis j'ai dû ajouter un autre profil vide (par exemple skip-integration-tests) pour pouvoir les ignorer.
denishaskin

7
y a-t-il un moyen de le faire sans dupliquer tous les éléments partagés?
JonnyRaa

7
Attention, si vous utilisez le plugin maven-release-plugin, il semblerait qu'il ne met pas à jour le numéro de version des sous-modules qui sont cachés derrière un changement de profil. Vous pourriez avoir des sous-modules avec des numéros de version différents pour le reste de votre projet ...
Ardesco

8
Malheureusement, en utilisant le profil, vous ne pouvez pas exclure un module mentionné précédemment dans la partie principale <modules> du pom. Le JIRA issues.apache.org/jira/browse/MNG-5230 (et toute la structure pom) aurait pu être entièrement implémenté tellement mieux avec un peu plus de réflexion.
Ed Randall

2
cette solution fonctionne-t-elle vraiment? Au moins, je ne peux pas le faire fonctionner. On dirait que j'ai le même problème que @EdRandall
Gerros

232

Maven version 3.2.1 a ajouté cette fonctionnalité, vous pouvez utiliser le -plcommutateur ( raccourci pour la --projectsliste) avec !ou -( source ) pour exclure certains sous-modules.

mvn -pl '!submodule-to-exclude' install
mvn -pl -submodule-to-exclude install

Soyez prudent en bash le personnage! est un caractère spécial, vous devez donc soit le guetter (comme je l'ai fait), soit l'échapper avec le caractère anti-slash.

La syntaxe pour exclure plusieurs modules est la même que celle de l'inclusion

mvn -pl '!submodule1,!submodule2' install
mvn -pl -submodule1,-submodule2 install

EDIT Windows ne semble pas aimer les guillemets simples, mais c'est nécessaire dans bash; sous Windows, utilisez des guillemets doubles (merci @awilkinson)

mvn -pl "!submodule1,!submodule2" install

27
Important: si vous souhaitez exclure un sous-module imbriqué, vous devez utiliser la version qualifiéemvn -pl !com.acme:nestedmodule1
Leonard Brünings

3
L'option -pl nécessite '[groupId]:' avant artifactId, nous devrions donc utiliser mvn -pl '!: Submodule-to-exclude' install
Honsen

4
Vous pouvez également utiliser mvn -pl '!path/to/submodule/directory', sans utiliser groupId et artifactId. Ma réponse fonctionne si submodule1et submodule2se trouvent dans le répertoire courant.
Alexandre DuBreuil

Il est aussi ne vaut rien que si vous utilisez -pldans mvn install, vous aurez probablement besoin de l' utiliser pour mvn deployainsi
majikman

39

Il est possible de décider des projets de réacteur à construire en spécifiant l' -plargument de ligne de commande:

$ mvn --help
[...]
 -pl,--projects <arg>                   Build specified reactor projects
                                        instead of all projects
[...]

Il accepte une liste de paramètres séparés par des virgules sous l'une des formes suivantes:

  • chemin relatif du dossier contenant le POM
  • [groupId]:artifactId

Ainsi, étant donné la structure suivante:

project-root [com.mycorp:parent]
  |
  + --- server [com.mycorp:server]
  |       |
  |       + --- orm [com.mycorp.server:orm]
  |
  + --- client [com.mycorp:client]

Vous pouvez spécifier la ligne de commande suivante:

mvn -pl .,server,:client,com.mycorp.server:orm clean install

pour tout construire. Supprimez les éléments de la liste pour ne construire que les modules qui vous conviennent.


EDIT: comme l' a souligné blackbuild , à partir de Maven 3.2.1, vous avez un nouveau -eldrapeau qui exclut les projets du réacteur, de la même manière que -pl:


2
Merci. Cela a bien fonctionné pour moi. Notez également que vous pouvez ajouter le "-am" (AKA "--also-make") pour également créer des projets qui sont requis par les modules que vous avez spécifiés.
GaZ

1
Génial! J'ai utilisé mvn install -pl .pour installer le pom parent uniquement dans le dépôt local sans construire de modules.
Marcin

Jetez également un œil à jira.codehaus.org/browse/MNG-5230 . Vous pouvez désormais exclure des projets du réacteur.
blackbuild

1
Lien MNG-5230 depuis la fermeture de codehaus.org: issues.apache.org/jira/browse/MNG-5230
Ed Randall

Malheureusement, cela ne fonctionne pas de manière transitoire, c'est-à-dire que si j'ai top / mod1 / mod2, et que je construis à partir de haut, -pl '! Mod2' génère une erreur.
zakmck

4

La notion de projets multi-modules est là pour répondre aux besoins des segments codépendants d'un projet. Un tel client dépend des services qui à leur tour dépendent, par exemple, d'EJB ou de routines d'accès aux données. Vous pouvez regrouper vos tests d'intégration continue (CI) de cette manière. Je rationaliserais cela en disant que les tests CI doivent être synchronisés avec les changements de logique d'application.

Supposons que votre projet soit structuré comme suit:

project-root
  |
  + --- ci
  |
  + --- client
  |
  + --- server

Le project-root/pom.xmldéfinit les modules

<modules>
  <module>ci</module>
  <module>client</module>
  <module>server</module>
</modules>

Le ci/pom.xmldéfinit des profils tels que:

... 
<profiles>
  <profile>
    <id>default</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <plugin>
       <artifactId>maven-surefire-plugin</artifactId>
       <configuration>
         <skip>true</skip>
       </configuration>
     </plugin>
  </profile>
  <profile>
    <id>CI</id>
    <plugin>
       <artifactId>maven-surefire-plugin</artifactId>
       <configuration>
         <skip>false</skip>
       </configuration>
     </plugin>
  </profile>
</profiles>

Cela entraînera le fait que Maven saute des tests dans ce module sauf lorsque le profil nommé CIest actif. Votre serveur CI doit recevoir l'instruction de s'exécuter mvn clean package -P CI. Le site Web de Maven a une explication approfondie du mécanisme de profilage .


2

il y a maintenant (à partir de la version 1.1.1) un drapeau 'skip' dans le pit.

Vous pouvez donc faire des choses comme:

    <profile>
        <id>pit</id>
        <build>
            <plugins>
                <plugin>
                    <groupId>org.pitest</groupId>
                    <artifactId>pitest-maven</artifactId>
                    <configuration>
                        <skip>true</skip>
                    </configuration>
                </plugin>
            </plugins>
        </build>
    </profile>

dans votre module, et pit sautera

[INFO] --- pitest-maven: 1.1.3: mutationCoverage (default-cli) @ module-selenium --- [INFO] Projet ignoré

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.