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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.