Discussion :

[animageo]

== EDIT : désolé je pensais l'avoir mis dans le sous-forum maven, si un administrateur peut le déplacer, je ne pense pas avoir les droits pour le faire ==

J'ai deux problèmes assez spécifiques que j'ai pu contourner jusqu'à présent mais je veux bien l'avis d'un œil aguerri.

J'ai un projet maven qui génère un tar.gz contenant de la configuration (fichiers de configurations, librairies spécifiques à un OS) destinés à des environnements et des OS différents donc j'utilise les classifier pour générer un tar.gz ENV1 et un tar.gz ENV2. Chacun de ces build repose sur la notion de profils qui permettent également d'utiliser des variables propres à ces environnements via le filtrage de ressources. Donc si je lance la commande maven avec -PENV1, le profil activé ne build que l'assembly de ce profil avec les propriétés définies pour ce profil.

Comme la plupart des projets j'imagine, j'utilise un repository Nexus pour stocker mes SNAPSHOTS et mes RELEASE.

Et donc avec de mode de fonctionnement, j'ai deux problèmes :
- Lorsque je veux déployer sous Nexus en SNAPSHOT mes tar.gz, je suis obligé de faire un mvn deploy par environnement puisque je dois activer un profil précis. Si j'active plusieurs profils en même temps, tous les tar.gz seront générés mais ils utiliseront les propriétés du dernier profil activé donc ça ne me convient pas.
- Lorsque je veux déployer sous Nexus en RELEASE, je fais un maven:prepare et maven:perform, je ne peux pas activer les deux profils à la fois non plus pour les mêmes raisons. Je me retrouve donc dans le nexus à avoir un seul tar.gz. Je contourne ça en lançant moi même un mvn deploy supplémentaire sur le profil passé à la trappe. Sauf que j'ai un autre problème : le premier deploy a généré le tar.gz de l'ENV1 et le pom associé donc quand je lance le deploy pour le .tar.gz de l'ENV2, il plante car le pom existe déjà. Donc je peux faire un allow redeploy sur le repository release (je n'aime pas trop) ou sinon à la barbare, je supprime le pom et les md5 et sha1 associés via une requête HTTP DELETE gérée par l'API REST (c'est ce que je fais).

Ce qui me gène dans le premier problème c'est que ça fait déconner l'API REST nexus. Puisque je fais deux mvn deploy différent, j'ai disons dans mon repository SNAPSHOT un artifact PROJET-1.0.x-timestamp-4-ENV1.tar.gz et PROJET-1.0.x-timestamp-5-ENV2.tar.gz. le 4 et 5 correspondant au numéro de mvn deploy executé. Et donc si je demande à l'API REST de me récupérer le dernier (avec &v=LATEST), et que le -5 est le dernier, ça marchera pour le classifier ENV2 mais pas pour le ENV1 car il cherchera un artifact PROJET-1.0.x-timestamp-5-ENV1.tar.gz mais ça n'existe pas. Avez-vous une idée pour que tout soit généré via une seule commande mvn deploy ?

Pour le second problème, c'est de devoir faire un mvn deploy supplémentaire et donc de ne pas gérer complètement le package release avec la commande mvn adéquate, avez-vous une idée pour que tout fonctionne avec le maven:perform ?

[animageo]

Bon suite à quelques recherches et notamment à cet article (http://www.blackbuild.com/how-to-rea...ng-your-karma/), j'ai fini par me convaincre qu'utiliser les profils pour différencier les versions n'étaient pas une bonne solution.

Vu que ce qui me posait problème était surtout de la configuration que j'avais pour ENV1 et ENV2, j'ai désormais trois projets sans profils au lieu d'un seul avec deux profils. Le projet parent contient la configuration commune puis les deux projets enfants (en tant que modules) génèrent chacun un artefact respectivement pour ENV1 et ENV2 avec des coordonnées maven différentes donc plus de problèmes dans Nexus.