Discussion :

[minimarch76]

Bonjour,

nous sommes en train de modifier nos différents projets d'entreprise afin d'utiliser Maven au mieux, et surtout de nous simplifier la tâche. C'est plutôt bien parti, mais je suis bloqué sur un point particulier.

J'ai un fichier de configuration "wsf.properties" qui se trouve actuellement dans src/main/resources. Ce fichier contient des configurations différentes si le projet est déployé sur la production ou le recettage. Pour le moment je me paluche les modifications à la main à chaque compilation, en espérant ne pas l'oublier (ce qui va arriver un jour ou l'autre).

Je souhaiterais donc avoir 2 fichiers, un pour la production et un pour la recette, de façon à pouvoir configurer Maven pour qu'il me choisisse l'un ou l'autre en fonction du profile choisi (nos profiles fonctionnent sans souci).

Le problème vient du fait que je charge ce fichier dans le code à partir de son URI, et que le nom du fichier ne peut donc pas changer.

Quelle solution conseillez-vous ?

Y a-t-il possibilité de demander à Maven de copier un fichier d'un certain nom "src/main/resources/production/wsf.properties" vers "src/main/resources/wsf.properties", le tout sans conflit ?

Merci par avance pour vos réponses,
MiniMarch'

[romaintaz]

Bonne question, mais je ne crois pas qu'il y a de façon simple de faire...

Quelques idées :

Tu as donc wsf-prod.properties et wsf-recettes.properties.

1. Utiliser le plugin ant-run de Maven pour le renommage du fichier wsf-XXX.properties en wsf.properties...

2. Je ne sais pas si ça marche, mais tu peux peut-être demander à Maven de filtrer ton fichier source Java et au lieu d'avoir (dans le Java) :

String URI_FILE = "/wsf.properties";

tu aurais :

String URI_FILE = "/${wsf.properties}";
que remplacerait Maven selon le profil en cours... (qui vaudrait donc soit wsf-prod.properties ou wsf-recettes.properties...

3. Modifier le code source Java de façon à tester l'existence du fichier. Tu essaies de charger les propriétés du fichier wsf-recettes.properties, et si tu ne le trouve pas, tu prends wsf-recettes.properties... Mais bon, c'est pas terrible comme solution.

[evenisse]

Il faut utiliser les profiles maven, c'est fait pour celà entre autres

[minimarch76]

evenisse > Oui, je suis en train de configurer les profiles. Mais je cherche justement le moyen de les utiliser pour répondre à cette problématique. Je n'ai rien trouvé qui me permettait d'avoir systématiquement un fichier précis sous un nom précis avec un contenu différent en fonction de l'environnement de déploiement.

romaintaz > J'avais effectivement penser à modifier le code pour prendre en compte une adresse de fichier différente. Malheureusement, ce fichier de configuration est utilisé par des clients de Web Services se trouvant eux-mêmes dans des Jar indépendant. Je pourrais m'en sortir, mais ce n'est effectivement pas très joli, et c'est dommage ne pas profiter d'une solution plus élégante et générique.

Quand tu proposes :

String URI_FILE = "/${wsf.properties}";

que signifie ce "/${...}" ? Il s'agit d'une commande Java ou Maven ?

Merci pour tes propositions en tout cas.

[evenisse]

evenisse > Oui, je suis en train de configurer les profiles. Mais je cherche justement le moyen de les utiliser pour répondre à cette problématique. Je n'ai rien trouvé qui me permettait d'avoir systématiquement un fichier précis sous un nom précis avec un contenu différent en fonction de l'environnement de déploiement.

Regarde ce doc : http://maven.apache.org/guides/mini/...ironments.html

[Tomekaa]

N'étant pas un grand fan de l'utilisation de ant via Maven, j'utiliserais pour ma part cette solution :
Définir des répertoires resources additionnels selon les profils.

Voilci un exemple de ce que cela peut donner, en imaginant avoir un dossier src/main/env-resources contenant les resources spécifiques à chaque environnement, dans des dossiers séparés.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
<profiles>
	<profile>
		<id>prod</id>
		<activation>
			<activeByDefault>true</activeByDefault>
		</activation>			
		<build>		
			<resources>
				<resource>
					<directory>src/main/env-resources/prod</directory>
					<filtering>true</filtering>
				</resource>
			</resources>
		</build>
	</profile>
	<profile>
		<id>test</id>
		<activation>
			<property>
				<name>env</name>
				<value>test</value>
			</property>
		</activation>			
		<build>		
			<resources>
				<resource>
					<directory>src/main/env-resources/test</directory>
					<filtering>true</filtering>
				</resource>
			</resources>
		</build>
	</profile>	
</profiles>

C'est à mon sens plus "propre" que la solution définie dans le mini guide.