Re: Version Pom dans code
Cédric Beust ♔ <[email protected]>
| Newsgroups | gmane.comp.java.french.general |
|---|---|
| Message-ID | <[email protected]> |
2010/9/2 Baptiste MATHUS <[email protected]> > > Le 2 septembre 2010 09:48, Nicolas Delsaux <[email protected]> a > écrit : > > 2010/9/2 Cédric Beust ♔ <[email protected]>: >> > >> > >> > Par exemple, voici celui de TestNG (note le numéro de version, que je >> > réutilise ensuite dans plusieurs autres fichiers pendant le build). >> >> Mais rien n'empêche ce fichier properties d'être créé ou rempli par >> l'outil de build, non ? >> > > Regarde le fichier en lien chez Cédric. Il est d'accord avec toi, puisque > son .properties est "variabilisé", et je suppose vu les noms de variables > qu'il es même modifié par maven au packaging > En fait, non: ce build.properties est l'"autorité" et tout est dérivé à partir de ces valeurs: le build ant, le build maven et aussi quelques autres opérations telle que la génération d'un fichier vide "TESTNG-${version}" que je mets dans le jar file pour aider l'identification. Je pense qu'une bonne question à se poser est: si un jour, tu veux changer la structure de tes répertoires (src/, test/, ressources, etc...), tu ne devrais avoir que quelques lignes à modifier. D'où l'importance de mettre toutes ces informations physiques dans un fichier centralisé. Le seul problème que j'ai rencontré est que le déploiement de mon artifact dans Nexus essaie d'incrémenter le numéro de version directement dans mon pom.xml, ce qui m'énerve au plus haut point (j'ai essayé de convaincre les gars de Sonatype de rendre cette phase optionnelle mais sans succès jusqu'à présent). -- Cédric