Différents fichiers à empaqueter dans un projet de guerre Maven

Question

J'ai un projet Maven d'emballage de guerre, dans lequel j'ai un fichier de propriétés Java appelé myapp.properties. Dans ce fichier de propriétés, je stocke certains paramètres, par exemple, les paramètres de connexion à la base de données, qui seront utilisés par la webapp. Dans un environnement d'intégration continue ou dans mon environnement de développement, je souhaite définir des paramètres de test dans myapp.properties pour me connecter à ma base de données de test, par exemple.

Dans le même temps, je veux laisser ces paramètres vides dans mon paquet de guerre final afin que les utilisateurs puissent ajouter ces valeurs par eux-mêmes lors du déploiement dans leur environnement. Le paquet de guerre final doit être un artefact de génération généré dans l'environnement d'intégration continue. Pour l'essentiel, il existe deux versions du fichier myapp.properties que je souhaite utiliser dans différents cas. Ma question est, quelle est la façon Maven de résoudre ce problème? J'utilise Eclipse + WTP + m2eclipse dans mon environnement de développement et j'espère que la solution fonctionnera bien avec mes outils de développement.

Answer 1

Vous pouvez jeter un oeil sur ce blog: http://blog.jayway.com/2010/01/21/one-artifact-with-multiple-configurations-in-maven/

Ils construisent différents fichiers-guerre et d'utiliser classificateur différents (au lieu de profils différents). Je ne sais pas si c'est le maven, mais ça marche pour certains de mes projets.

Answer 2

Je voudrais essayer avec

pom.xml pour votre projet (ou pom parent)

 <build> 
      ... 
     <resource> 
      <directory>src/main/resources</directory> 
      <includes> 
       <include>**/*.properties</include> 
      </includes> 
      <filtering>true</filtering> 
     </resource> 
     ... 
     </build> 

dans votre fichier de propriétés (s) par exemple

db.url=${db.url} 

et dans votre settings.xml (voir http://maven.apache.org/settings.html#Profiles)

<db.url>jdbc:mysql://localhost:3306/testdb</db.url> 

selon votre stade de développement (local, construire serveur, etc.), vous pouvez utiliser différentes valeurs db.url

Cela ne laissera pas la propriété db.url vide, mais chaque fois que vous empaquetez l'artefact, vous ne voulez pas qu'il reste vraiment vide, n'est-ce pas?