web-dev-qa-db-fra.com

version mvn: préparer à ne pas valider les modifications apportées à pom.xml

J'essaye de libérer un plugin Jenkins ( stashNotifier ) avec Maven et je fais face à un problème avec le plugin de libération.

mvn clean release:prepare

s'exécute sans erreurs mais ne parvient pas à valider le pom.xml modifié dans mon référentiel git local. Même s'il marque le HEAD de la branche sur laquelle j'essaie de publier la version 1.0.2. Voici à quoi ressemble ma branche locale avant de préparer la version

* df60768 (HEAD, Origin/develop, develop) upgraded parent pom to version 1.498
* 792766a added distribution management section to pom.xml and amended readme.md 

et voici à quoi ça ressemble

* df60768 (HEAD, tag: stashNotifier-1.0.2, Origin/develop, develop) upgraded parent pom to version 1.498
* 792766a added distribution management section to pom.xml and amended readme.md 

Malheureusement, le pom.xml contient déjà la prochaine version de développement, ce qui entraîne à son tour une version ultérieure: effectuez pour publier cette version de l'instantané.

De la sortie de la commande de maven, il semble presque qu'il omet la commande git commit:

[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git add -- pom.xml
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git status
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Tagging release with the label stashNotifier-1.0.2...
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git tag -F /var/folders/dr/xxbtyycs1z9dl2_snlj87zrh0000gn/T/maven-scm-678409272.commit stashNotifier-1.0.2
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git Push [email protected]:jenkinsci/stashnotifier-plugin.git stashNotifier-1.0.2
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git ls-files
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Transforming 'Stash Notifier'...
[INFO] Not removing release POMs
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git add -- pom.xml
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Executing: /bin/sh -c cd /Users/gruetter/Dropbox/stashNotifier && git status
[INFO] Working directory: /Users/gruetter/Dropbox/stashNotifier
[INFO] Release preparation complete.

J'utilise maven 3.0.5 (sans --dry-run ou -DpushChanges = false). Voici les parties pertinentes (je pense) de mon pom efficace:

[...]

<scm>
   <connection>scm:git:git://github.com/jenkinsci/stashnotifier-plugin.git</connection>
   <developerConnection>scm:git:[email protected]:jenkinsci/stashnotifier-plugin.git</developerConnection>
   <url>https://github.com/jenkinsci/stashnotifier-plugin</url>
</scm>

[...]

<distributionManagement>
   <repository>
      <id>maven.jenkins-ci.org</id>
      <url>http://maven.jenkins-ci.org:8081/content/repositories/releases/</url>
   </repository>
   <snapshotRepository>
      <id>maven.jenkins-ci.org</id>
      <url>http://maven.jenkins-ci.org:8081/content/repositories/snapshots</url>
   </snapshotRepository>
   <site>
     <id>github-pages</id>
     <url>gitsite:[email protected]/jenkinsci/maven-site.git:plugin-parent/stashNotifier</url>
   </site>
</distributionManagement>

[...]

<properties>
   [...]
   <maven-release-plugin.version>2.2.2</maven-release-plugin.version>
   [...]
</properties>

[...]

<build>
   [...]
   <pluginManagement>
      <plugins>
         [...]
         <plugin>
            <artifactId>maven-release-plugin</artifactId>
            <version>2.2.2</version>
         </plugin>
         [...]
   </pluginManagement>

   [...]

   <plugins>
      [...]
      <plugin>
         <artifactId>maven-release-plugin</artifactId>
         <version>2.2.2</version>
         <configuration>
            <goals>deploy</goals>
         </configuration>
      </plugin>
      [...]
   </plugins>
</build>

Qu'est-ce que je fais mal? Merci d'avance pour vos idées!

76
BumbleGee

J'ai résolu le problème de mon côté (en exécutant maven 3.0.5) en mettant à jour la dépendance du fournisseur git scm, pas la version du plugin de sortie:

<build>
  <plugins>
    <plugin>
      <artifactId>maven-release-plugin</artifactId>
      <version>2.4.2</version>
      <dependencies>
        <dependency>
          <groupId>org.Apache.maven.scm</groupId>
          <artifactId>maven-scm-provider-gitexe</artifactId>
          <version>1.8.1</version>
        </dependency>
       </dependencies>
      </plugin>
    </plugins>
</build>

La version git scm 1.8.1 effectue correctement la validation git (testée avec les objectifs de préparation et de restauration).

EDIT: Différentes versions de maven-release-plugin et maven-scm-provider-gitexe peuvent être requises en fonction de votre environnement. Voir les commentaires pour plus de discussion.

92
richnou

J'ai rencontré le même problème, la solution #richnou fonctionne pour moi (mise à niveau de la dépendance SCM). Il y a le problème créé sur ce problème, voir le lien ci-dessous. Le problème concerne une nouvelle version de Git où "git status" renvoie des messages localisés que le plugin ne peut pas analyser. C'est la cause profonde. Le problème a été corrigé dans git scm (version 1.8.1) en utilisant --porcelain option de git (qui devrait retourner une sortie facilement analysable), mais après ce correctif, un autre problème est survenu - si la racine du référentiel (balise scm) n'est pas le répertoire de travail, release:prepare échoue toujours. Ce problème semble être résolu dans la version instantanée de Git SCM (pas encore publiée). Cela peut être contourné en copiant la balise scm dans le pom enfant.

MRELEASE-812

SCM-709

maven-release-plugin-and-git-fix

16
vasekt

Vous lisez probablement ceci parce que les solutions ci-dessus n'ont pas fonctionné pour vous. J'ai eu le même problème et j'ai essayé tout ce qui est mentionné ici. Mes versions étaient: maven-release-plugin 2.5 et git 1.7.9

La solution qui fonctionnait pour moi était rétrogradation maven-release-plugin vers la version 2.3.2

<build>
    <plugins>
        <plugin>
            <groupId>org.Apache.maven.plugins</groupId>
            <artifactId>maven-release-plugin</artifactId>
            <version>2.3.2</version>
            <configuration>
                <autoVersionSubmodules>true</autoVersionSubmodules>
            </configuration>
        </plugin>
    </plugins>
</build>
9
Iulian Ghionoiu

Tout d'abord, les réponses de richnou et vasekt ont résolu mon problème.J'ai pensé publier cette réponse uniquement à cause des versions plus récentes que celles mentionnées et j'ai pensé qu'il serait bon de donner un exemple supplémentaire en les incluant.

J'exécutais le plug-in de version maven 2.3.2 avec Git 3.3.x sans spécifier la version de dépendance maven scm, ce qui provoquait le problème de l'instantané. Pour moi, je viens de passer à la dernière version à la fois pour le plugin de libération maven et la dépendance scm qui étaient les suivantes:

<plugin>
   <artifactId>maven-release-plugin</artifactId>
   <version>2.5.3</version>
   <dependencies>
      <dependency>
         <groupId>org.Apache.maven.scm</groupId>
         <artifactId>maven-scm-provider-gitexe</artifactId>
         <version>1.9.5</version>
      </dependency>
   </dependencies>
</plugin>

Cela a bien fonctionné pour moi, les versions des versions téléchargées correctement dans le référentiel de versions et l'instantané ont également fonctionné comme prévu.

7
Jeremy

Mise à niveau du maven-release-plugin à la version 2.5.2 a aidé (la mise à niveau vers la version 2.5 n'a pas fonctionné; cela fonctionne pour certaines personnes mais pas pour toutes, peut-être en fonction d'autres logiciels plus récents du système). Je crois que cela attire automatiquement le nouveau fournisseur.

4
mirabilos

Je viens de rencontrer ce même problème, et d'après les autres réponses et commentaires, j'ai pensé qu'il s'agissait probablement d'un bogue dans le plug-in de publication lui-même.

Dans mon cas, j'utilisais la version 2.4 du plugin avec git dans un projet nouveau et principalement vide structuré comme suit:

my-repo.git/
  module-parent/     # running the release from here
  (module-child-1/)  # except I hadn't created it yet
  (module-child-2/)  # except I hadn't created it yet

(Le code source de ce projet peut être vu ici, avant de résoudre le problème: mon projet avec le même problème .)

En regardant le notes de version pour maven-release-plugin: 2.4.1 , il semblait que MRELEASE-830 avait peut-être une chance de le résoudre.

Je ne sais pas si cela était le problème, mais la mise à niveau de mon projet vers 2.4.1 du plugin l'a résolu pour moi . J'espère que cela résoudra le problème pour vous aussi!

1
Karl M. Davis

J'utilise Git 1.8.x localement et j'ai rencontré un problème similaire:

maven-scm-plugin fait

$ git add
$ git status

mais non

$ git commit

Utiliser une autre machine avec Git 1.7.x m'a aidé à contourner ce problème.

Remarque: j'ai essayé d'utiliser maven-scm-plugin 1.8.1 ou 1.9, maven-release-plugin 2.4.1 ou 2.4.2.

1
Lukas Fryc

J'ai rencontré ce même problème lors de l'utilisation de cygwin + maven + git. Il n'a montré aucune erreur mais n'a pas tenté de valider les modifications de pom, juste arrêté après git status:

[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
[INFO] Working directory: C:\Users\ltheisen\git\caasd-portal-automation
[INFO] Executing: cmd.exe /X /C "git status"
[INFO] Working directory: C:\Users\ltheisen\git\caasd-portal-automation
[INFO] Tagging release with the label portal-automation-0.3.9...
[INFO] Executing: cmd.exe /X /C "git tag -F C:\cygwin64\tmp\maven-scm-1212196933.commit portal-automation-0.3.9"
[INFO] Working directory: C:\Users\ltheisen\git\caasd-portal-automation
[INFO] Executing: cmd.exe /X /C "git Push [email protected]:org-mitre-caasd/portal-automation.git portal-automation-0.3.9"
[INFO] Working directory: C:\Users\ltheisen\git\caasd-portal-automation
[INFO] Executing: cmd.exe /X /C "git ls-files"
[INFO] Working directory: C:\Users\ltheisen\git\caasd-portal-automation
[INFO] Transforming 'portal-automation'...
[INFO] Not removing release POMs
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
[INFO] Working directory: C:\Users\ltheisen\git\caasd-portal-automation
[INFO] Executing: cmd.exe /X /C "git status"
[INFO] Working directory: C:\Users\ltheisen\git\caasd-portal-automation
[INFO] Release preparation complete.

Comme vous pouvez le voir, aucune erreur, juste n'a pas validé après avoir vérifié l'état. Cependant, lorsque j'ai exécuté à partir de l'invite de commandes Windows à la place:

...
[INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
[INFO] Working directory: C:\Users\ltheisen\git\caasd-portal-automation
[INFO] Executing: cmd.exe /X /C "git status"
[INFO] Working directory: C:\Users\ltheisen\git\caasd-portal-automation
[INFO] Executing: cmd.exe /X /C "git commit --verbose -F C:\Users\ltheisen\AppData\Local\Temp\maven-scm-2030091036.commit pom.xml"
[INFO] Working directory: C:\Users\ltheisen\git\caasd-portal-automation
[INFO] Executing: cmd.exe /X /C "git symbolic-ref HEAD"
[INFO] Working directory: C:\Users\ltheisen\git\caasd-portal-automation
[INFO] Executing: cmd.exe /X /C "git Push [email protected]:org-mitre-caasd/portal-automation.git master:master"
[INFO] Working directory: C:\Users\ltheisen\git\caasd-portal-automation
[INFO] Release preparation complete.

Vous pouvez voir qu'il a été validé après avoir vérifié l'état. Je ne sais pas si c'est aussi votre problème, mais cela a fonctionné pour moi.

Notez que cela signifierait que vous devez installer msysgit

1
Lucas

Problème similaire, mais j'ai eu ce problème en utilisant Jenkins Release Plugin et Gitlab:

  • La première fois, ça a marché.
  • La deuxième fois, il ne s'engageait pas.

Il s'avère que nous avions une faute de frappe dans la configuration SCM dans notre pom.xml, donc le projet avec faute de frappe a été créé la première fois. À la deuxième fois, Maven accédait au projet obsolète et s'est plaint, sans commettre les modifications.

0
exic