Débrayer les tests pour release multi-module

**Tommy31** · 06/01/2009, 10h48

Dans le cadre d'une application maven multi-module (v2.0.9), dont certain des sous-modules possèdent des tests unitaires qui bien entendu ne sont plus à jour et ne passent plus, je souhaiterais les décommuter pour réaliser un release.

Sauf que, pas moyen.

J'ai essayé les lignes de commande suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mvn -Dmaven.test.skip=true release:prepare

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mvn -DnoTest=true release:prepare

Echec à chaque fois. En fait, j'ai l'impression que le commutateur n'est pas transmis au goal des sous-modules.

Quelqu'un à une solution ?
Merci !

**romaintaz** · 06/01/2009, 11h29

moi j'utilise la commande mvn -Dtest=notest ..., mais parfois aussi la première que tu proposes, et ça marche (mais je suis en 2.0.8)

**Tommy31** · 06/01/2009, 11h38

En multi-module ? C'est à dire que tu invoque la commande sur le projet parent ?

Ca maaarche pas, snif

**romaintaz** · 06/01/2009, 11h53

Oui, en multi-modules.

Tu n'as rien défini dans ton pom.xml sur les tests unitaires ?

**Tommy31** · 06/01/2009, 12h14

J'ai rien définit de particulier.

La seule configuration c'est la version du jdk :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					<source>1.6</source>
					<target>1.6</target>
				</configuration>
			</plugin>
		</plugins>
	</build>

Sinon, j'ai trouvé une ligne de commande qui fonctionne, mais c'est tordu:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mvn release:prepare "-DpreparationGoals=clean install -Dmaven.test.skip=true"

Bon, je pars la dessus...

**Tomekaa** · 07/01/2009, 10h04

En fait ce n'est pas si tordu que cela

Le release plugin lance ses goals de préparation dans un fork, et ne passe pas les arguments donnés dans sa ligne de commande, mais bien ceux de son paramètre de config preparationGoals.

Donc ta ligne est bien une bonne idée, même si je pense que le préciser comme ci-dessous est un peu plus clair :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mvn release:prepare "-DpreparationGoals=clean install" "-Darguments=-Dmaven.test.skip=true"

Il est aussi possible de passer par une config du plugin de release dans le pom du projet, pour éviter des répétitions inutiles, et là, pourquoi ne pas imagineune config comme celle-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<build>
        <plugins>
                (...)
                <plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-release-plugin</artifactId>
			<version>2.0-beta-7</version>
			<configuration>
				<preparationGoals>clean install</preparationGoals>
				<arguments>-Dmaven.test.skip=${maven.test.skip}</arguments>
			</configuration>
		</plugin> 
                (...)
	</plugins>
</build>

**Tommy31** · 07/01/2009, 11h42

Excellent !

A mettre dans la FAQ !

**aheritier** · 09/01/2009, 13h32

Effectivement la solution est bien d'utiliser -DpreparationGoals et -Darguments
Par exemple si vous voulez faire la release d'un projet parent sans ses modules vous pouvez utiliser :
mvn release:prepare -Darguments="-N" -N
Ainsi le build principal n'est pas récursif et le fork de la release non plus.

**globule71** · 03/12/2009, 19h37

Je confirme !

A mettre dans la FAQ, car j'ai réellement bataillé avant de comprendre pourquoi mes tests unitaires étaient systématiquement exécutées lors d'une release....
Le soucis c'est bien que je sache que ces tests aboutissaient forcément à un échec, tant que je n'avais pas réussi à les "squizzer"... Je ne pouvais faire de release...

**aheritier** · 04/12/2009, 00h16

Un jour faudra tout de même m'expliquer pourquoi vous gardez des tests qui ne passent plus ??
Pour augmenter le nombre de lignes ?

**globule71** · 04/12/2009, 10h32

Car tout simplement lors de la migration d'un projet (déplacement de base de test etc..) Nous pouvons être amené à passer outre les tests pour des raisons de planning sans quoi l'échec d'exécution des tests empêche toute release !

Je me doute bien que l'on sort du cadre d'un process de release mais il y 'a certains moment où on a pas le choix !

**aheritier** · 04/12/2009, 11h07

Je ne critique pas. Je sais qu'il y a toujours une bonne raison et que les gens ne le font pas par plaisir.
C'est juste que faire une release si les tests passent pas ... c'est ennuyeux.
C'est pour cela qu'ils doivent être maintenus au jour le jour.
Je parle bien sur des tests unitaires. Pour les tests d'intégration c'est différent, si ils utilisent des ressources externes non dispo par exemple. Mais dans ce cas ils doivent etre dans un profile non activé par défaut.

**globule71** · 04/12/2009, 12h06

C'est en effet des tests d'intégration dont je parlais... qui nécessitaient l'utilisation d'une base actuellement indisponible.

Je n'ai pas encore utilisé de profil d'activation de ces tests ! Je vais pencher sur la question.

Merci pour ces éclaircissements