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.

[evenisse]

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

Je trouve aussi, mais c'était le plus rapide à écrire

[minimarch76]

La solution consistant à avoir différents répertoires contenant les ressources pour les différents environnements de déploiement me plait bien, mais cela veut-il dire que vous n'avez plus de /src/main/resources ?

En résumé, vous avez :

/src/main/env-resources/production
/src/main/env-resources/recette
/src/main/env-resources/developpement

et un seul d'entre eux est pris au moment de la compilation par maven.

Mais est-ce env-resources qui est défini comme répertoire dans le classpath ou tous les sous-répertoires ?

Merci pour vos réponses, je pense que le résultat sera parfait...

[Tomekaa]

Le répertoire /src/main/resources peut toujours exister, pour contenir les resources communes à tous les environnements.

Mais est-ce env-resources qui est défini comme répertoire dans le classpath ou tous les sous-répertoires ?

Dans l'exemple de configuration que j'ai posté, les resources présentes dans les dossiers env-* se retrouveront in fine au même endroit que celles de src/main/resources, il faut voir cela comme un répertoires de resources supplémentaire, et donc ne pas spécifier env-ENV quand on veut accéder à la resource via le classpath.

Et cette structure permet justement d'utiliser des resources avec le même nom de fichier

[minimarch76]

Je viens de mettre en oeuvre cette solution, c'est tout bonnement génial ! Plus je l'utilise, plus j'adore Maven.

En revanche, j'ai un gros souci : quand je compile pour l'environnement de recette, mon répertoire env-recette vient écraser totalement mon répertoire /src/main/resources. Du coup, les ressources qui s'y trouvent ne sont plus présentes dans le WAR final...

N'y a-t-il pas une option supplémentaire pour signaler que les répertoires env-* viennent en plus du répertoire principal, et non en remplacement ?

[Tomekaa]

Pour cela il te suffit de rajouter (hors des profils) la configuration "normale" des resources :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
</profiles>
(...)
<build>		
	<resources>
		<resource>
			<directory>src/main/resources</directory>
			<filtering>true</filtering>
		</resource>
	</resources>
(...)

[rseM2]

Bonjour,

Pour information, il est intéressant de noter que la solution proposée (ressources + profiles) fonctionne pour la production de jar.

En effet, si c'est pour produire des war, cela ne fonctionne pas. Il faut utiliser pour une autre solution (webRessources + profiles). Nous avons mis cela en place pour la gestion de descripteurs de container web (weblogic.xml, jonas-web.xml...). Cela marche très bien.

Rémy

[minimarch76]

Alors là, il y a des informations contradictoires : Tomekaa m'a donné une solution qui fonctionne (je viens d'essayer) et rseM2 dit que cela ne marche pas.

J'aurais plutôt tendance à croire Tomekaa

En tout cas, le tout fonctionne nickel.

Merci à tous pour vos réponses.

[Tomekaa]

Les répertoires spécifiés par <webresources> peuvent être utilisées en surplus des resources "standard" et sont, me semble-t-il, indiquées plutôt dans les cas où il faut que les resources aboutissent à un autre endroit que WEB-INF/classes.

[rseM2]

Alors là, il y a des informations contradictoires : Tomekaa m'a donné une solution qui fonctionne (je viens d'essayer) et rseM2 dit que cela ne marche pas.

Petite rectification, je n'ai pas dit que la solution (ressources + profiles) ne fonctionne pas. J'ai juste indiqué que pour la gestion d'archive war, le mécanisme peut être différent.

Mais effectivement comme l'a souligné Tomekaa, j'ai pas été assez précis.
En fait, il faut utiliser ressources pour les fichiers de ressources qui vont dans classes (pour les jars) et WEB-INF/classes (pour les war) et webRessources pour les fichiers qui vont ailleurs que WEB-INF/classes (pour les war).

Rémy