Discussion :

[JavaWorker]

Bonjour à tous,

Dans le cadre du développement dans une entreprise ayant son propre workflow
de développement, j'aurais besoin de variabiliser le fichier POM de mes projets
qui peuvent eux-mêmes contenir différents modules.
Cette variabilisation porte sur le numéro de version de l'artifact de telle sorte :
-- le fichier POM est écrit une fois pour toute en début d'une release et n'est plus
modifié jusqu'à la fin de la release;
-- le numéro de version est figé et n'est plus changé, ex: 01.02.00;
-- une variable est introduite après ce numéro de version pour déterminer lors d'un build
ce qui va être généré (release, snapshot, release candidate, alpha, ...) ceci grâce à
différents profils;

Lorsque j'effectue des tests en local, tout se passe bien. Cependant lorsque je déploie dans
des repositories internes à l'entreprise pour mettre à disposition des artifacts, les POMs
déployés embarquent la variable (et non pas la valeur que je lui affecte par profil) et cela engendre
des problèmes de gestion des dépendances lors du build d'autres projets dépendant de mes artifacts déployés.

Auriez-vous une solution qui me permette de garder ce mécanisme de variabilisation dans mon fihcier POM tout
en déployant ce POM valorisé ?


PS:
J'ai regardé un peu le code du plugin deploy, et il semble qu'il déploie le pom tel qu'il est stocké
sur le disque dur. D'un autre côté, le plugin help avec son goal effective-pom permet de récupérer le POM
valorisé avec les valeurs des variables définies dans les profils.
Pensez-vous qu'il soit judicieux de rajouter un paramètre (flag booléen) au plugin deploy pour qu'il sache
aussi déployer des POM valorisés ? Serait-ce contraire à la philosophie de Maven ?

Merci par avance pour votre aide.

[denisC]

-- le fichier POM est écrit une fois pour toute en début d'une release et n'est plus
modifié jusqu'à la fin de la release;
-- le numéro de version est figé et n'est plus changé, ex: 01.02.00;
-- une variable est introduite après ce numéro de version pour déterminer lors d'un build
ce qui va être généré (release, snapshot, release candidate, alpha, ...) ceci grâce à
différents profils;

Je conprends pas trop. Tu veux dire que ta version (dans le POM) est de type 1.2.3-alpha? Ca ne pose pas de problème à Maven ça... Ou que c'est une variable du type ${version} qui n'est pas valorisée initialement? Pourquoi ne pas la valoriser en début de release? Je ne comprends pas vraiment ton workflow, ce qui ne me permets pas de comprendre ce que tu cherches à faire....

Pensez-vous qu'il soit judicieux de rajouter un paramètre (flag booléen) au plugin deploy pour qu'il sache
aussi déployer des POM valorisés ? Serait-ce contraire à la philosophie de Maven ?

Pas une bonne idée. Un profil permet de modifier l'execution d'une release pas de définir une release....

[JavaWorker]

Je conprends pas trop. Tu veux dire que ta version (dans le POM) est de type 1.2.3-alpha? Ca ne pose pas de problème à Maven ça... Ou que c'est une variable du type ${version} qui n'est pas valorisée initialement? Pourquoi ne pas la valoriser en début de release? Je ne comprends pas vraiment ton workflow, ce qui ne me permets pas de comprendre ce que tu cherches à faire....

En fait mon tag version serait plutôt comme ceci :

Code :

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

<version>01.00.00${VarSRC}</version>

Cette variable peut prendre la valeur "-SNAPSHOT", "-RC1", "-RC2", ... ou être vide. Ce qui me permet de générer des artifacts différents au moment du build sans changer les fichiers POMs.

Pas une bonne idée. Un profil permet de modifier l'execution d'une release pas de définir une release....

Je comprends bien. Mais alors si j'ai un POM avec des variables, il faut impérativement que je remplace à la main ces variables par leurs valeurs avant
de déployer sous peine d'avoir un POM déployé contenant des variables qui ne seraient pas déclarées dans un autre environnement ?

Merci de ta réponse