J'ai un peu galéré dernièrement pour configurer correctement Perforce avec Maven et notamment le plugin Maven release. Je vous propose donc un petit billet sur le sujet.
Bref, ça va parler de release avec maven, de déploiement sur Nexus et de label perforce.
Tout un programme.
Tout d'abord petit rappel, si vous avez la chance de ne pas connaitre Perforce (sic...), il s'agit d'un gestionnaire de source tout comme peut l'être Subversion, Git ou Mercurial. Enfin "tout comme peut l'être", faut le dire vite... Je passerais rapidement sur l’outil en lui-même car je l’utilise contraint et forcé.
Or comme ce magnifique outil est relativement indigeste et loin d’être simple à utiliser je vous propose de voir rapidement la configuration nécessaire pour l’intégration avec Maven.
A noter que si vraiment Perforce vous insupporte, et je peux comprendre, vous pouvez utiliser un proxy git-perforce. Je vous invite dans ce cas à lire le billet Jean Chistophe Gay sur le sujet. (Au passage c’est un super collègue, prenez le sur vos missions ;))
Mais revenons à nos moutons, même en utilisant git-p4 ca ne vous épargnera pas la douleur de devoir releaser sur Perforce de temps en temps.
Tout d’abord petit rappel,
le versionning avec Maven
Maven repose sur un notion forte de version d’artefact. Chaque dépendance que vous déclarez dans votre pom.xml a un numéro de version qui doit être explicitement déclaré. Par exemple :
com.localizeyourapp
nemrodclient
1.1
Si vous utilisez plusieurs modules, chaque module doit avoir sa version. (Ce qui compliquera heureusement la tâche de ceux qui pensait qu’il suffirait de changer le numéro de version a un seul endroit pour en faire une release....)
pom.xml
|
\`---module1
| |
| \`---pom.xml
\`---module2
| |
| \`---pom.xml
\`---module3
|
\`---pom.xml
Le plugin maven release permet justement de suivre quelques bonnes pratiques lors de la release de votre projet :
- Vérification que vous n’avez aucune modifiation non commité en local
- Vérification que vous ne dépendez d’aucune dépendance instable (SNAPSHOT)
- Lancement des tests
- Changement automatique de toutes les versions de POM de votre projet (sous modules inclus)
- Création d’un tag sous votre gestionnaire de source
- Déploiement de l’artefact dans un repo Maven (nexus par exemple)
Ouf, on a de la chance, le plugin maven-release supporte Perforce
- http://www.perforce.com/perforce/r11.1/manuals/p4maven/index.html
- http://kb.perforce.com/article/1023/maven-integration
- http://maven.apache.org/scm/scms-overview.html
Configuration
Perforce
Prérequis :
p4 doit être disponible en ligne de commande
vous devez avoir certaines variables disponibles en variable d’environnement
Les variables nécessaires pour Perforce peuvent être sous forme de variable d’environnement, ou bien écrites dans un fichier p4.ini à la racine de votre dépot. Le fichier doit contenir les informations suivantes :
P4PORT=perforce:1992
P4CHARSET=utf16le-bom
P4COMMANDCHARSET=winansi
P4CLIENT=hlassiege_1992
P4USER=v-hlassiege
P4PASSWORD=****
Posez pas de question sur l’encodage, ca fait partie des merveilles de Perforce...
Maven
Côté Maven, il vous faut quelque configuration dans votre pom.xml.
La balise scm :
scm:perforce:myHost:1992://depot/poms-parent/main
scm:perforce:myHost:1992://depot/poms-parent/main
La partie distribution management pour que Maven sache sur quel repository déployer ces artefacts :
inhouse
dav:http://repositoryHost:8081/nexus/content/repositories/company/
inhouse_snapshot
dav:http://repositoryHost:8081/nexus/content/repositories/company-snapshot/
Ensuite il est important que la personne (ou l’outil si vous l’automatisez via votre intégration continue) qui va déclencher la release utilise un fichier settings.xml qui déclare les identifiants de connexion à Nexus :
inhouse
myLogin
myPwd
Ensuite, une fois arrivé là, le reste est trivial
cd C:\DEV\perforce1992\depot\poms-parent\main
mvn release:prepare
mvn release:perform
Voilà, désormais que Perforce soit avec vous. Ou pas...