Discussion :

[romaintaz]

Hello,

Une question m'interroge :

Quand je lance la commande mvn package site, Maven va exécuter 2 fois les tests : une fois lors de la création du package, la seconde fois lorsqu'il créera le site (en supposant bien sûr que le plugin surefire soit demandé).

Y a t'il un moyen simple de faire exécuter les tests une seule fois ?

Je précise que cette solution devrait idéalement n'exécuter les tests qu'une seule fois que je lance la commande mvn package site, mvn package ou mvn site...

[marcxa44]

essaie la commande mvn package site:site
en principe tes tests ne devrait être éxécuter qu'une seule fois lors du mvn package.

[romaintaz]

Hello.

Je reviens sur le sujet, car après différents tests, je m'aperçoit que rien n'est résolu.
Sur mon application, j'ai les rapports Surefire et Cobertura activés (je ne sais pas trop si ça joue, mais bon).
Le problème c'est que si je lance la création du site, ça me lance 2 fois les tests : Lors de la phase de test de Maven, puis lors de l'exécution des tests lors de la phase site. J'ai essayé diverses commandes, mvn site, mvn site:site, mais rien n'y fait, les tests sont réalisés 2 fois.

Une idée ?

[evenisse]

Le fait d'utiliser les rapports surefire et cobertura fait que les tests sont lancés deux fois. C'est normal, explication:

cobertura utilise les classes de test qu'il doit modifier pour pouvoir analyser l'exécution, surefire n'utilise pas ces classes modifiées (car il ne les connait pas, c'est de même pour cobertura et les classes surefire). L'exécution des tests se fait dans des réperoires différents et sont totalement indépendante pour ces deux plugins

[romaintaz]

Effectivement evenisse. Je venais d'arriver à la même explication suite à la lecture de sujets sur le forum Maven à ce propos.

Merci pour l'explication toutefois

[dvicente72]

ça n'est pas possible dans la version actuelle de Maven.

il est impossible pour un plugin de savoir si un autre goal a déjà été lancé et pour certains plugins, il est nécessaire qu'un goal précedent soit lancé.

Pour que Surefire-report puisse générer son rapport , il faut que les tests soient exécutés et le xml généré par le plugin Surefire. Comme il ne peut savoir si ça a déjà été fait, c'est pour ça que le plugin Surefire-report a un lifecycle.xml dans src/main/resources/META-INF/maven/ ce qui permet à Maven de lancer les tests avant de générer le rapport.

donc si tu fais mvn package site

les tests sont lancés 1 fois par le plugin Surefire dans le cycle normal ( qui correspond à package) et les tests sont relancés une 2ème fois via Surefire-report

Pour Cobertura , c'est pareil avec la seul différence qu'il doit lancer en plus les tests sur des classes instrumentés par Cobertura afin de générer le fichier binaire contenant les infos de couverture de code.

Donc tu auras toujours les tests lancés 2 fois une fois via Surefire-report et une autre fois par cobertura

[romaintaz]

dvicente72, si je désactive Cobertura dans mon pom.xml, et que je lance un mvn site, alors les tests ne sont lancés qu'une seule fois, bien que j'ai Surefire et Surefire-Reports dans mon pom.xml...

C'est expliqué ici.

[dvicente72]

oui si tu fais que mvn site

mais si tu fais mvn package site, tu l'auras tj 2 fois, une fois par surefire dans la phase test et une fois par surefire-report quand tu fais le site.

Sauf si ta "plage" de tests durent 3 heures , ce qui va donner 6 au total avec Cobertura en plus, je trouve dommage de désactiver Cobertura.

c'est quand même un indicateur bien pratique.

[romaintaz]

En fait, si je ne touche pas à mon pom.xml, la commande mvn clean install site, alors les tests sont exécutés 3 fois :
- Lors de la compilation.
- par Surefire-report
- par Cobertura

Or mes tests durent en général 20 à 30 minutes. Ce qui porte l'exécution totale à environ 1h - 1h30...

N'y a t'il pas moyen de regrouper les tests faits par la compilation et surefire-report ? Histoire de les exécuter 2 fois au maximum (avec Cobertura) ou 1 seule fois (sans Cobertura) ?

[dvicente72]

dans l'état actuel de mes connaissances, non .

à la limite le seul moyen pour n'exécuter les tests que 2 fois serait de faire :

- enlever surefire-report de ton pom
- créer un site.xml dans ton projet avec un lien vers le rapport surefire
- lancer la commande "mvn clean install site surefire-report:report-only"

je ne vois que ça et là les tests ne serait exécutés que 2 fois , une fois lors de la phase test et un fois par Cobertura.

T'as vraiment besoin de lancer si souvent mvn clean install site et que la durée des tests soit si pénalisante ?

à mon sens , dans ton cas, je me contenterai d'un mvn clean install

et le mvn clean install site, je ne le ferai qu'une fois par jour via Continuum

non ?

[romaintaz]

Bon, je reviens sur ce problème, pour dire que j'ai trouvé une solution pour n'exécuter qu'une seule fois les tests lors de la commande mvn clean install package.
Dans le pom.xml, je demande au plugin Surefire Report de ne pas relancer les tests, mais juste de créer les rapports :

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
16
17
 
...
    <reporting>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-report-plugin</artifactId>
                <version>2.3</version>
                <reportSets>
                    <reportSet>
                        <reports>
                            <report>report-only</report>
                        </reports>
                    </reportSet>
                </reportSets>
            </plugin>
...

Les tests ne sont alors exécutés que lors de la phase de compilation, et non plus dans la phase de création de site.

Ca va m'aider, dans la mesure où mon dernier nightly build (qui faisait un mvn clean install site site:deploy) avait mis pas moins de 7 heures !

Voilà un sujet vraiment résolu cette fois

[rseM2]

Ca va m'aider, dans la mesure où mon dernier nightly build (qui faisait un mvn clean install site site:deploy) avait mis pas moins de 7 heures !

Il vaut mieux être en nightly build dans ce cas, sinon la pause café est assez longue

Sinon je vois souvent mvn ... site site:deploy.
Y a-t-il une raison pour ne pas utiliser mvn ... site-deploy ? (A part le fait de ne pas le connaître).
Il me semble que cela revient au même.


Rémy

[romaintaz]

La simple raison est que site:deploy ne crée pas le site. Donc si tu fais pas un site site:deploy, tu vas te retrouver avec une erreur :

[INFO] [site:deploy]
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The site does not exist, please run site:site first

[rseM2]

La simple raison est que site:deploy ne crée pas le site. Donc si tu fais pas un site site:deploy, tu vas te retrouver avec une erreur :

Oui je suis au courant de cela.
Ce que je propose n'est pas site:deploy mais site-deploy. C'est une nuance subtile mais qui fait la différence.

Rémy

[romaintaz]

Bon, effectivement, j'avais bien lu site-deploy, mais je croyais à une erreur
Je ne connaissais pas (ou alors j'ai oublié) ce raccourci. Bon, d'un autre côté, c'est juste histoire de gagner quelques caractères à l'écriture lors de la commande, non ? Ou y a t'il une vraie différence entre site-deploy et site site:deploy ?

[vain_mich]

Aucune différence à ma connaissance le résultat est identique !

[denisC]

Ou y a t'il une vraie différence entre site-deploy et site site:deploy ?

La différence, c'est que site-deploy est une phase du cycle de vie, qui appelle tous les plugins de cette phase (plus les phases précédentes), alors qu'avec site site:deploy, tu appelles la phase site puis le plugin site avec le mojo deploy.

Dans une configuration par défaut, c'est pareil (le seul plugin lié à la phase site-deploy c'est site:deploy et l'ancetre est bien site), mais si tu rajoutes quelque chose à site-deploy (ou qu'un plugin se lie tout seul), ça ne sera plus pareil..... Si le mojo pour deployer le site ou le plugin change, la phase sera mis à jour dans maven, mais pas dans tes sccripts.


Donc +1 pour site-deploy.

[rseM2]

Je ne connaissais pas (ou alors j'ai oublié) ce raccourci. Bon, d'un autre côté, c'est juste histoire de gagner quelques caractères à l'écriture lors de la commande, non ? Ou y a t'il une vraie différence entre site-deploy et site site:deploy ?

A mon avis, il n'y a pas de différence.

Mais même si c'est quelques caractères de gagner c'est toujours cela surtout quand on finit par avoir une ligne de commande assez longue (plusieurs phases, profiles...). A la fin ca peut devenir difficile à lire et à maintenir.

En tout cas c'était plus pour informer que ca existe.

Rémy

[rseM2]

La différence, c'est que site-deploy est une phase du cycle de vie, qui appelle tous les plugins de cette phase (plus les phases précédentes), alors qu'avec site site:deploy, tu appelles la phase site puis le plugin site avec le mojo deploy.

Dans une configuration par défaut, c'est pareil (le seul plugin lié à la phase site-deploy c'est site:deploy et l'ancetre est bien site), mais si tu rajoutes quelque chose à site-deploy (ou qu'un plugin se lie tout seul), ça ne sera plus pareil..... Si le mojo pour deployer le site ou le plugin change, la phase sera mis à jour dans maven, mais pas dans tes sccripts.


Donc +1 pour site-deploy.

J'ai vu ton post après ma dernière réponse.
Ton explication est très bonne et je suis d'accord avec toi : +1 pour site-deploy

Rémy