Pourquoi Hudson ignore-t-il mon fichier profiles.xml?

Question

J'ai un projet Maven2, avec un fichier pom.xml et un fichier profiles.xml au même niveau. La configuration du projet est assurée par des propriétés de profil Maven:

dbhost=${dbhost} 
dbport=${dbport} 
// etc. 

Localement, chaque Developper personnaliser sa construction dans la "profiles.xml". Ça marche bien.

Pour une intégration continue, un fichier "profiles.xml" ci a été placé sur notre serveur SCM (au même niveau que le fichier pom.xml).

Le problème est que Hudson ignore simplement ce fichier pendant la construction de Maven, alors que le "-P hudsonprofile" est correctement défini.

Si le même profil est déplacé directement dans le "pom.xml", ou dans le "settings.xml" global, la construction fonctionne. Nous avons donc déjà une solution.

Je sais aussi que le fichier « profiles.xml » est dépréciée, mais je voudrais comprendre pourquoi le comportement est différent entre Hudson et construire ma construction locale ...

Note: Hudson et ma construction locale utilisez la même version de Maven (2.2.1).

Answer 1

Cela me semble être un problème de classpath. Pourquoi Hudson ne remarquerait-il pas le fichier profiles.xml? La seule raison que je peux penser est que Hudson utilise un chemin de classe différent de ce que vous attendez.

Une meilleure pratique (au moins dans mon expérience), est d'essayer de construire le projet à partir de la ligne de commande sur votre serveur CI (où Hudson s'exécute). Si cela fonctionne, Hudson devrait aussi travailler. Sauf si vous avez étrangement configuré Maven dans Hudson.

De plus, ajuster les paramètres.xml de Maven n'est pas si mauvais. Au moins, si vous ne vous attendez pas à ce qu'il change trop. Même ainsi, il est réparé rapidement.

Answer 2

Je pense que la meilleure solution consiste à définir les profils directement dans votre fichier pom.xml pour CI tout autant que pour les générations locales. Ensuite, les développeurs peuvent remplacer tous les paramètres de profil dans leur propre fichier settings.xml personnel pour les versions locales. Cela a l'avantage supplémentaire de ne pas avoir à enregistrer un fichier profiles.xml qui ne fonctionnera pas pour les développeurs, les obligeant à modifier ce fichier versionné et à ne pas enregistrer leurs modifications. Cela a également l'avantage de rendre votre construction non dépendante d'une fonctionnalité obsolète de Maven. Après tout, je ne compterais pas sur le comportement d'une fonctionnalité obsolète en premier lieu. J'espère que c'est une solution élégante qui utilise des idées de ce que vous savez déjà fonctionne.