Débrayer les tests pour release multi-module

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. :evilred:

J'ai essayé les lignes de commande suivantes :

Code:

---

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

---

Code:

---

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 !

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)

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

Ca maaarche pas, snif :pleure:

Oui, en multi-modules.

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

J'ai rien définit de particulier.

La seule configuration c'est la version du jdk :

Code:

---

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:

---

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

---

Bon, je pars la dessus...

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:

---

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:

---

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>

---

:hola: Excellent !

A mettre dans la FAQ !

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.

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...

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

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 !

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.

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 ;)

Citation:

---

Envoyé par Tommy31

:hola: Excellent !

A mettre dans la FAQ !

---

Je reviens sur ce message, tous les 6 mois je dois réutiliser le plugin release et tous les 6 mois je recherche ce fil :ccool: qui n'est toujours pas dans la FAQ :cry::cry:

Citation:

---

Envoyé par gribo

Je reviens sur ce message, tous les 6 mois je dois réutiliser le plugin release et tous les 6 mois je recherche ce fil :ccool: qui n'est toujours pas dans la FAQ :cry::cry:

---

salut, en fait ya déjà un super site, c'est celui de maven :ccool:http://maven.apache.org/plugins/mave...pare-mojo.html