[Maven / SVN] Erreur "is not a working copy"

**Malatok** · 05/10/2011, 15h07

Bonjour,

Voilà mon problème :

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
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
[INFO] Executing: cmd.exe /X /C "svn --non-interactive commit --file C:\Users\antoine\AppData\Local\Temp\maven-scm-998588205.commit --targets C:\Users\antoine\AppData\Local\Temp\maven-scm-5761453449138466355-targets"
[INFO] Working directory: C:\prog\testreleaseMaven\metaproject-ihm
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: 'C:\prog\testreleaseMaven' is not a working copy
 
[INFO] ------------------------------------------------------------------------
[DEBUG] Trace
org.apache.maven.BuildFailureException: Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: 'C:\prog\testreleaseMaven' is not a working copy
 
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
        at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:592)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoFailureException: Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: 'C:\prog\testreleaseMaven' is not a working copy
 
        at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:287)
        at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
        ... 17 more
Caused by: org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: 'C:\prog\testreleaseMaven' is not a working copy
 
        at org.apache.maven.shared.release.phase.AbstractScmCommitPhase.checkin(AbstractScmCommitPhase.java:168)
        at org.apache.maven.shared.release.phase.AbstractScmCommitPhase.performCheckins(AbstractScmCommitPhase.java:148)
        at org.apache.maven.shared.release.phase.ScmCommitPreparationPhase.runLogic(ScmCommitPreparationPhase.java:75)
        at org.apache.maven.shared.release.phase.AbstractScmCommitPhase.execute(AbstractScmCommitPhase.java:79)
        at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203)
        at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
        at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
        at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:279)
        ... 20 more

Mon problème se situe dans le mvn release:prepare quand il essaie de commiter le changement des POM sur le SVN et pourtant mon SCM a bien les bonnes informations :

Code :

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

1
2
3
4
    <scm>
        <connection>scm:svn:https://monserveur/TestMavenBuild/trunk/metaproject-ihm/</connection>
        <developerConnection>scm:svn:https://monserveur/TestMavenBuild/trunk/metaproejct-ihm/</developerConnection>
    </scm>

Si quelqu'un a déjà eu cette erreur ou qui peut m'en dire plus.
Le plus impressionnant c'est que j'ai déjà fait des releases depuis ce poste.

Merci d'avance pour votre aide.

**nannous** · 06/10/2011, 09h52

Bonjour,
A mon humble avis le problème ne provient pas du maven-release plugin mais plutot de la copie locale de ton code qui n'est pas en phase avec ton repo svn.
Essaie un clean up sinon un checkout from scratch cela peut résoudre ton problème.
J'espère t'avoir aidé

**Malatok** · 06/10/2011, 10h31

Bonjour merci pour la réponse mais j'ai déjà fait un clean des projets dans eclipse. Et j'ai aussi refait un checkout du projet sur le SVN et ca na pas résolue le problème, il me remet ce message lors d'un checkout la je comprend plus.

**Malatok** · 06/10/2011, 12h05

Bon j'ai trouvé la réponse a mon problème, la release marche quand je fais un checkout en ligne de commande grâce a mon client Collabnet, mais pas quand je fais un checkout a partir de eclipse grâce au plugin Subversive SVN 1.6 SVN kit,
Quelqu'un saurait-il pourquoi j'arrive à faire la release dans un sens et pas dans l'autre.

**greaumaxime** · 06/10/2011, 14h37

Bonjour,

Il est très fortement déconseillé de faire une release à partir d'Eclipse notamment parceque tu peux embarquer dans ta release un fichier que tu aurais modifié dans ton environnement de développement et oublié de "commiter" sur le SCM (ici SVN).

Pour en revenir à ton problème, le processus de release est assez strict et s'assure (notamment pour le cas ci-dessus) qu'il n'y a pas de différences entre les fichiers que tu viens de récupérer de SVN (par le checkout) et les fichiers qui vont être présents dans la release.

Or avec Eclipse, lors d'un checkout, des fichiers de conf propres à Eclipse sont générés (.project, .classpath et le dossier .settings) et cachés par défaut. Tu te retrouves donc avec des différences entre le contenu de ton projet en local et le contenu du projet sous SVN.
Ceci peut être une des raisons de ton problème.

Il est important de faire les releases sur des serveurs dédiés et non sur les postes de développement;

Cordialement.

**Malatok** · 06/10/2011, 15h22

Il est très fortement déconseillé de faire une release à partir d'Eclipse notamment parceque tu peux embarquer dans ta release un fichier que tu aurais modifié dans ton environnement de développement et oublié de "commiter" sur le SCM (ici SVN).

=> Faux le plugin release interdit de faire la release si il y a le moindre changement en local qui n'est pas commiter sur le svn.

Or avec Eclipse, lors d'un checkout, des fichiers de conf propres à Eclipse sont générés (.project, .classpath et le dossier .settings) et cachés par défaut. Tu te retrouves donc avec des différences entre le contenu de ton projet en local et le contenu du projet sous SVN.
Ceci peut être une des raisons de ton problème.

=> je ne savais pas ... En même temp si ils sont cachés :'(

Il est important de faire les releases sur des serveurs dédiés et non sur les postes de développement;

=> Pas forcément mais juste un checkout avec un autre client svn que le plugin eclipse.

Encore merci pour l'explication
Cordialement.

**romaintaz** · 06/10/2011, 17h26

Globalement, il est recommandé de générer les packages d'une release dans un environnement sain, donc un serveur dédié (l'intégration continue par exemple).

Qui te dit par exemple que la machine du développeur qui va construire l'application n'a pas une spécificité dans sa configuration, qui rendra le build final "spécifique" et pas forcément reproductible ?

**thebloodyman** · 06/10/2011, 19h54

Globalement, il est recommandé de générer les packages d'une release dans un environnement sain, donc un serveur dédié (l'intégration continue par exemple).

Qui te dit par exemple que la machine du développeur qui va construire l'application n'a pas une spécificité dans sa configuration, qui rendra le build final "spécifique" et pas forcément reproductible ?

Salut,

J'ai réfléchi à ta phrase et j'ai l'impression qu'en arriver la est souvent synonyme d'avoir en amont des mauvaises pratiques de configuration Maven sur les postes développeur.
Pourquoi le développeur aurait une conf spécifique Maven qui ne serait pas celle souhaitée alors qu’au quotidien il travaille bien avec sur son projet avec cette conf.

**greaumaxime** · 07/10/2011, 09h26

Citation:
Il est très fortement déconseillé de faire une release à partir d'Eclipse notamment parceque tu peux embarquer dans ta release un fichier que tu aurais modifié dans ton environnement de développement et oublié de "commiter" sur le SCM (ici SVN).

=> Faux le plugin release interdit de faire la release si il y a le moindre changement en local qui n'est pas commiter sur le svn.

Je parlais en général, indépendamment de l'utilisation de Maven, Ant...

Citation:
Il est important de faire les releases sur des serveurs dédiés et non sur les postes de développement;

=> Pas forcément mais juste un checkout avec un autre client svn que le plugin eclipse.

Si si :-), l'objectif de réaliser une release "reproductible" n'est pas uniquement lié à la configuration de Maven mais également à l'environnement de création du build (OS, JDK, encodage des fichiers...).

Même si Maven te permet de vérifier certains paramètres, dans une équipe de 10, 20, 30... développeurs où la release est effectuée sur les postes de développement, tu ne peux pas t'assurer à 100% que le développeur qui fait la release à un instant T, n'utilise pas quelque chose de spécifique à son poste (une bibliothèque uniquement dans son repo local...).

Après c'est comme toutes les bonnes pratiques, ça ne veut pas dire que ça ne marchera pas dans ton cas sans un serveur dédié mais cette bonne pratique limite le risque de problèmes potentiels.

Cordialement.

**romaintaz** · 07/10/2011, 22h16

Envoyé par thebloodyman

Salut,

J'ai réfléchi à ta phrase et j'ai l'impression qu'en arriver la est souvent synonyme d'avoir en amont des mauvaises pratiques de configuration Maven sur les postes développeur.
Pourquoi le développeur aurait une conf spécifique Maven qui ne serait pas celle souhaitée alors qu’au quotidien il travaille bien avec sur son projet avec cette conf.

Il est vrai que Maven a permis de réduire pas mal de soucis de ce côté là. Par exemple fini les répertoires lib/ contenant des librairies pas toujours très précises (quelle version, d'où vient ce JAR, etc.). Mais pour autant, ça n'empêche pas d'avoir des comportements différents sur des machines de développeurs.

Dans la configuration du settings.xml (fichier qui est disponible sur chaque poste de dév, donc potentiellement tu ne sais pas s'ils sont tous corrects), tu peux définir pas mal de choses. Des repositories distants différents par exemple.
Autre idée : dans des configurations complexes de pom.xml, on définit souvent différents profils. Il suffit que le développeur lance la mauvaise commande, ou que sa configuration soit un peu particulière, et le mauvais profil est activé, ce qui peut avoir un impact sur le livrable final.

Et puis de toutes façons, tant qu'à faire, autant créer un job sur Jenkins (ou n'importe quel serveur d'IC) afin de gérer ce processus de release. Car moins il y a d'intervention humaine, mieux c'est...

**thebloodyman** · 07/10/2011, 23h10

Toujours pas convaincu

Envoyé par romaintaz

Dans la configuration du settings.xml (fichier qui est disponible sur chaque poste de dév, donc potentiellement tu ne sais pas s'ils sont tous corrects), tu peux définir pas mal de choses. Des repositories distants différents par exemple.

C'est justement une mauvaise pratique de développement.
Les développeurs travaillant sur un même projet ne sont pas censés définir dans leur settings.xml leur propre repo.
C'est à l'inverse des bonnes pratiques comme utiliser un gestionnaire de repo, donc un seul repo pour tous les développeurs d'un projet voire d'un groupe de projets.
Par exemple, si on permet aux développeurs de mettre ce que bon leur semble dans leur settings.xml, le résultat de leur build pendant les développements risque donc d'être différents entre eux, donc risque de bugs.

Autre idée : dans des configurations complexes de pom.xml, on définit souvent différents profils. Il suffit que le développeur lance la mauvaise commande, ou que sa configuration soit un peu particulière, et le mauvais profil est activé, ce qui peut avoir un impact sur le livrable final.

Si la phase release demande l'utilisation d'un profil particulier (dans le prepare puis le perfom), je suis d'accord, il y a effectivement un risque d'erreur humaine.
Maintenant utiliser un script qui enchaine les commandes résout très bien le problème.

Et puis de toutes façons, tant qu'à faire, autant créer un job sur Jenkins (ou n'importe quel serveur d'IC) afin de gérer ce processus de release. Car moins il y a d'intervention humaine, mieux c'est...

A priori, le processus de release se fait à la demande.
Donc que le développeur lance un .bat/.sh ou lance le job de livraison sur l'IC comporte les mêmes risques : opération en un coup dans les deux cas.
Si le développeur chargé d'effectuer les release n'est pas capable de lancer le .bat/.sh, pourquoi serait il plus capable de lancer le bon job sur l'IC ?

**tchize_** · 08/10/2011, 00h01

Je vais prendre un exemple tout simple:

Tu fais un projet java 5, tu configure maven en java 5, le compilateur java 5. Tout ca est dans le pom et tous les devs le partagent, donc aucun soucis.

Puis un dev fait un commit utilisant une classe java 6. Il a un jdk 1.6. Maven va compiler avec le jdk 1.6 en mode "compatibilité 1.5" (paramètre -target et -source de javac). La compilation va réussir malgrés tout sans alerte, car le compilateur ne vérifie pas la version des classes et méthodes individuelles de la jdk.

Résultat: tu a un jar, dont on a fait une release, qui est déclaré binairement comme java 1.5 mais qui va te lancer un NoClassDefFoundError si tu le lance pas sur une java 6.

Il y a beaucoup de choses ainsi qui peuvent jouer.

Dans une environnement controlé, pas de ce genre de blague.

**romaintaz** · 08/10/2011, 14h51

Envoyé par thebloodyman

C'est justement une mauvaise pratique de développement.
Les développeurs travaillant sur un même projet ne sont pas censés définir dans leur settings.xml leur propre repo.
C'est à l'inverse des bonnes pratiques comme utiliser un gestionnaire de repo, donc un seul repo pour tous les développeurs d'un projet voire d'un groupe de projets.

On est tout à fait d'accord là-dessus. Sauf qu'entre la théorie et la pratique, il y a parfois des différences. Laisser l'IC gérer le tout est une façon de s'assurer de ce qui sera construit...

**tchize_** · 08/10/2011, 16h42

Envoyé par romaintaz

On est tout à fait d'accord là-dessus. Sauf qu'entre la théorie et la pratique, il y a parfois des différences. Laisser l'IC gérer le tout est une façon de s'assurer de ce qui sera construit...

Au delà de ça, humainement dans une équipe, ca permet d'éviter les conflits de méthodologie et les argumentations sans fin quand il faut faire une release: si ça passe pas sur l'intégration continue, ça passe pas et c'est induscutable

**thebloodyman** · 09/10/2011, 03h21

Tu fais un projet java 5, tu configure maven en java 5, le compilateur java 5. Tout ca est dans le pom et tous les devs le partagent, donc aucun soucis.

Puis un dev fait un commit utilisant une classe java 6. Il a un jdk 1.6. Maven va compiler avec le jdk 1.6 en mode "compatibilité 1.5" (paramètre -target et -source de javac). La compilation va réussir malgrés tout sans alerte, car le compilateur ne vérifie pas la version des classes et méthodes individuelles de la jdk.

Résultat: tu a un jar, dont on a fait une release, qui est déclaré binairement comme java 1.5 mais qui va te lancer un NoClassDefFoundError si tu le lance pas sur une java 6.

Si le développeur utilise une classe Java 1.6 et commite ses sources sur le SCM, la machine ou est l'IC qui utilise du Java 1.5 devrait faire un build en erreur du projet, non ?
Ainsi, le développeur saurait qu'il y a un problème dans ce cas avant même de faire sa release.

Plus généralement, si on part du principe que les développeurs configurent leur poste de dév n'importe comment alors oui je suis d'accord l'IC peut être utile.
Maintenant, faut aussi prendre en compte que l'IC (jdk, settings.xml, etc...) est aussi gérée pas les développeurs, donc le risque qu'ils fassent une erreur de conf sur l'IC (suite à telle ou telle évolution de configuration) n'est pas non plus impossible.
Le problème reste le même : la rigueur.
Je vois beaucoup plus d’intérêt à utiliser l'IC pour ce qu'elle sait faire de mieux : faire gagner du temps au dév/intégrateurs en automatisant en tâches de fond, les opérations de builds et de tests des développements effectués.

Ce n'est pas que je ne vois aucun intérêt à releaser sur l'IC, mais je trouve sa valeur ajoutée plutôt limitée dans ce cas.
Et je trouve également que laisser ce job à l'IC masque un prob plus important : le non alignement entre les conf java/maven des développeurs.
Prob qui se pose autant en dév qu'en release.

**tchize_** · 09/10/2011, 12h55

Envoyé par thebloodyman

Si le développeur utilise une classe Java 1.6 et commite ses sources sur le SCM, la machine ou est l'IC qui utilise du Java 1.5 devrait faire un build en erreur du projet, non ?

Oui, c'est bien le sens de mon message

**tchize_** · 09/10/2011, 12h57

Envoyé par thebloodyman

Maintenant, faut aussi prendre en compte que l'IC (jdk, settings.xml, etc...) est aussi gérée pas les développeurs, donc le risque qu'ils fassent une erreur de conf sur l'IC (suite à telle ou telle évolution de configuration) n'est pas non plus impossible.

oui, mais on change bien moins souvent l'IC que les postes développeurs. Le développeur va souvent faire des bidouille genre: "et je ja passe en java 6, est-ce que ce bug est résolu? Non? Ha bas tant pis". Alors que sur l'IC ce sera "on passe en java 6" et non pas "si"

**thebloodyman** · 09/10/2011, 13h24

Oui, c'est bien le sens de mon message

Dans ce cas, la release depuis la machine où se trouve l'IC n'apporte pas de valeur puisque le développeur saura qu'il y a un problème dans ce cas avant même de faire sa release : au moment du commit.

Envoyé par tchize_

oui, mais on change bien moins souvent l'IC que les
postes développeurs. Le développeur va souvent faire des bidouille genre: "et je ja passe en java 6, est-ce que ce bug est résolu? Non? Ha bas tant pis". Alors que sur l'IC ce sera "on passe en java 6" et non pas "si"

Oui et non. Si la release ne passe pas sur la machine de l'IC pour x ou y raisons, le développeur sera tenté de bidouiller aussi la conf dessus pour que ça passe. C'est du vécu.
Je dirais même d'autant plus dans la mesure où un client attend la release de son projet.

Désolé, mais vraiment pas convaincu

**tchize_** · 09/10/2011, 17h38

Si ton intégration continue fonctionne faire une release consiste simplement à promouvoir un build déjà fait

[Maven / SVN] Erreur "is not a working copy"

Maven Java

Discussions similaires

Partager

Partager