web-dev-qa-db-fra.com

Ignorer un sous-module pendant une construction Maven

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

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

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

Je suppose qu’une option consiste à supprimer ce sous-module du parent pom.xml entièrement et ajoutez simplement un autre projet sur notre serveur CI pour construire ce module.

Suggestions?

mavencontinuous-integrationjenkins
130
denishaskin

Bien sûr, cela peut être fait en utilisant des profils. Vous pouvez faire quelque chose comme ce qui suit dans votre parent pom.xml.

  ...
   <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 profil ci, c.-à-d. mvn -P ci clean install

139
Raghuram

Maven version 3.2.1 a ajouté cette fonctionnalité, vous pouvez utiliser le -pl interrupteur ( raccourci pour --projects liste) 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 le citer (comme je l’ai fait) ou l’échapper avec le caractère barre oblique inversée.

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

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

[~ # ~] éditer [~ # ~] Windows ne semble pas aimer les guillemets simples, mais il est nécessaire dans bash; sous Windows, utilisez les guillemets doubles (merci @awilkinson)

mvn -pl "!submodule1,!submodule2" install
180
Alexandre DuBreuil

Il est possible de choisir les projets de réacteurs à construire en spécifiant le -pl argument 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, compte tenu de 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 plaisent.

EDIT: comme blackbuild signalé, à partir de Maven 3.2.1, vous avez n nouveau -el _ drapea qui exclut les projets du réacteur, comme ce que -pl Est-ce que:

37
skuro

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, lesquels dépendent à leur tour des EJB ou des routines d'accès aux données. Vous pourriez grouper vos tests d'intégration continue (CI) de cette manière. Je rationaliserais cela en disant que les tests de CI doivent être en phase avec les changements de logique d'application.

Supposons que votre projet est structuré comme suit:

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

Le project-root/pom.xml définit les modules

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

Le ci/pom.xml dé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 des tests Maven ignorés dans ce module, sauf lorsque le profil nommé CI est actif. Votre serveur de CI doit avoir pour instruction d’exécuter mvn clean package -P CI. Le site Web Maven a un explication détaillée du mécanisme de profilage .

4
Sri Sankaran

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

Pour que vous puissiez 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 la fosse va sauter

[INFO] --- pitest-maven: 1.1.3: mutationCoverage (default-cli) @ module-Sélénium --- [INFO] Projet en cours

2
twillouer