Utilisation de la balise input avec le plugin maven antrun

Version imprimable

Bonjour,

Je viens partager une anomalie rencontrée lors de la création d'un projet maven.
Durant le build de mon projet, je souhaite poser une question avec la balise < input > de antrun
Théoriquement, le build continue ou s'arrête en erreur en fonction de ma réponse.

Concrètement :
- Lorsque je fais un mvn package, ma réponse est prise en compte et le build s'arrête bien en erreur (ou continue)
- Lorsque je fais un mvn release:prepare, ma réponse n'est prise en compte le build reste bloqué sur la question et je suis obligé de faire un "ctrl + c"

Est-ce que quelqu'n a déjà rencontré ce genre de problème ??

Voilà comment j'utilise le plugin antrun dans mon pom.xml

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<plugin>
  <artifactId>maven-antrun-plugin</artifactId>
  <version>1.8</version>
  <executions>
    <execution>
      <id>initialisation</id>
      <phase>initialize</phase>
      <configuration>
        <tasks>
          <exec dir="${project.basedir}"
            executable="${project.basedir}/livraison/outils/0_init_livraison.ksh"
            failonerror="false"
            resultproperty="sortieInitScript">
            <arg line="${project.name} ${project.version} ${ancienneVersion}" />
            <redirector errorproperty="redirector.err" />
          </exec>
          <echo message="Resultat ${sortieInitScript}, Message ${redirector.err}"/>
          <input message="  Souhaitez-vous Continuer ? "
            validargs="o,n"
            addproperty="procedureChoix" />
          <fail message="ARRET VOLONTAIRE DE LA PROCEDURE !!">
            <condition>
              <equals arg1="${procedureChoix}" arg2="n" />
            </condition>
          </fail>
        </tasks>
      </configuration>
      <goals>
        <goal>run</goal>
      </goals>
    </execution>
  </executions>
</plugin>

07/09/2015, 15h06
eulbobo

Je vais poser une question qui ne répondra pas à ta question :

Que fait précisément ton script 0_init_livraison.ksh ?
Et pourquoi as tu "besoin" de saisir une commande clavier?
08/09/2015, 09h25
romaintaz

Bonjour,

Attendre une saisie de l'utilisateur lors d'un build est une très mauvaise pratique. Il faut l'éviter à tout prix. Une alternative est de considérer que la valeur que doit saisir l'utilisateur soit passée au build Maven par une propriété globale, en faisant par exemple mvn clean pacakge -DmaPropriete=MaValeur.
08/09/2015, 12h44
tchize_

Le plugin release lance différentes instances autonomes de maven pour ses différentes opérations. Il va tagger le SCM, faire un checkout du Tag dans un sous dossier, lancer un build de ce checkout (via package) et si c'est un succes générer la release.

Dans ton cas, tu as donc un deuxième process maven en background, lancé par le plugin release, qui demande de l'input. Mais ça ne marchera pas car le plugin en background n'a pas accès à la console. Il n'y a a priori rien pour empêcher ces forks dans le plugin release.

Avoir un build qui dépend de la console est extrèmement problématique, la majorité des outils autour de maven ne fonctionneront pas avec ça car ils supposent des runs autonomes. Ton projet maven est impossible à mettre dans un jenkins, impossible à invoker depuis netbeans comme build process, impossible de faire des releases et les releases ne seront pas reproductibles car dépendantes de l'input de l'utilisateur (qui change suivant l'utilisateur).

Comme dit, si t'as besoin d'une valeur dans ton build, passe un paramètre à la ligne de commande. En plus, l'utilisation des ant task est fortement déconseillé. Il existe d'autres manière de faire en maven si tu veux lancer un script.

Bonjour,

Pour répondre à eulbobo, mon script 0_init_livraison.ksh vérifie différentes informations du pom.xml.
Par exemple, lors de mon build, mon projet est packagé sous forme de rpm. Le script vérifie alors si les dépendances sur les anciens rpm sont cohérentes. (Est que toto-1.0.rpm dépend bien de jiji-1.0.rpm ? si non, est-ce volontaire, ou un oubli ? D'où la demande de confirmation de l'utilisateur)

Au final, j'ai appliqué la solution de romaintaz.
Je ne demande plus à la personne qui créé le package de confirmer (ça ne fonctionnerai d'ailleurs pas avec un outil comme Jenkins).
S'il y a un doute, le build se stoppe en erreur, et dans le message d'erreur je dis comment forcer le build malgré l'erreur détectée par le script.

Ça fonctionne très bien, et comme l'explique tchize_, c'est un bonne pratique.

Mon problème technique n'avait finalement pas vraiment lieu d'être. Il suffisait de voir les choses différemment.

Merci pour vos réponses :D !

Pour information si quelqu'un a besoin d'un code similaire:

- Voici les commandes que je passe : mvn clean packge -Dforcer=oui ou mvn release:prepare -Darguments=-Dforcer=oui

- Voici comment je renseigne mon pom.xml (ça peut surement être amélioré)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 <plugin> <artifactId>maven-antrun-plugin</artifactId> <version>1.8</version> <executions> <execution> <id>initialisation</id> <phase>initialize</phase> <configuration> <tasks> <exec executable="${outilsLivraison}/0_init_livraison.ksh" failonerror="false" resultproperty="codeRetour"> <redirector errorproperty="message.redirector.err" /> </exec> <fail message=" ARRET DE LA PROCEDURE ! VOUS POUVEZ FORCER LA PROCEDURE AVEC '-Dforcer=oui' (ou '-Darguments=-Dforcer=oui' pour une release)."> <condition> <and> <equals arg1="${message.redirector.err}" arg2="warning" /> <not><equals arg1="${forcer}" arg2="oui" /></not> </and> </condition> </fail> <fail message=" Erreur"> <condition> <equals arg1="${codeRetour}" arg2="1" /> </condition> </fail> </tasks> </configuration> <goals> <goal>run</goal> </goals> </execution> </executions> </plugin>
- Voici comment je renseigne mon script .ksh
Code:

1 2 3 fonc_warning(){ echo "warning" 1>&2 }