Ressources multi environnement

Version imprimable

Bonjour,

Maven suggère d'utiliser les profiles et "maven-antrun-plugin" pour gérer des ressources multi-environnement.

Voici comment j'ai procédé :

Code:

1
2
3
4
5
src/main/ressources
| messages.properties
| platform.properties
+ production
  | platform.properties

Code:

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-antrun-plugin</artifactId>
			<executions>
				<execution>
					<phase>prepare-package</phase>
					<goals>
						<goal>run</goal>
					</goals>
					<configuration>
						<tasks>
							<delete dir="${project.build.outputDirectory}/production" verbose="true" />
						</tasks>
					</configuration>
				</execution>
			</executions>
		</plugin>
	</plugins>
</build>
<profiles>
	<profile>
		<id>production</id>
		<build>
			<plugins>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-antrun-plugin</artifactId>
					<executions>
						<execution>
							<phase>prepare-package</phase>
							<goals>
								<goal>run</goal>
							</goals>
							<configuration>
								<tasks>
									<copy todir="${project.build.outputDirectory}" overwrite="true" failonerror="true" verbose="true">
										<fileset dir="${project.build.outputDirectory}/production" />
									</copy>
									<delete dir="${project.build.outputDirectory}/production" verbose="true" />
								</tasks>
							</configuration>
						</execution>
					</executions>
				</plugin>
			</plugins>
		</build>
	</profile>
</profiles>

Et puis j'ai cherché un moyen plus "propre", plus simple de faire ça :

Code:

1
2
3
4
5
6
src/main/ressources/commons
| messages.properties
src/main/ressources/development
| platform.properties
src/main/ressources/production
| platform.properties

Code:

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
<build>
	<resources>
		<resource>
			<directory>src/main/resources/commons</directory>
		</resource>
		<resource>
			<directory>src/main/resources/development</directory>
		</resource>
	</resources>
</build>
<profiles>
	<profile>
		<id>production</id>
		<build>
			<resources>
				<resource>
					<directory>src/main/resources/commons</directory>
				</resource>
				<resource>
					<directory>src/main/resources/production</directory>
				</resource>
			</resources>
		</build>
	</profile>
</profiles>

Ca ne fonctionne pas, les ressources par défaut (development) sont copiés par dessus les ressources production.

Y'a-t-il d'autres solutions ?

Merci.

12/05/2009, 08h35
romaintaz

Bonjour,

Je pense que ta 2e solution est plus propre qu'utiliser Ant (c'est mon point de vue).
Tu peux éventuellement définir des exclusions dans les ressources, afin d'exclure effectivement les fichiers qui ne devraient pas être présents dans la release finale...

Tout premièrement, il faut essayer de ne pas contenir la variabilité au niveau de l'artefact mais plutôt de la déporter au serveur d'application.
L'idée est d'avoir un artefact générique acceptant en entrée des valeurs JNDI, des proprétés systèmes, … et c'est serveur d'application de développement, de recette, de production d'injecter les bons paramètres.
Dans les applications standardisés JEE : oui c'est possible.
Ainsi, Maven n'a été prévu pour gérer cela nativement.

Dans tous les cas, il faut éviter au maximum l'utilisation du plugin maven-antrun-plugin quand on peut faire autrement.

Ton problème d'écrasement vient du fait que tu a spécifié les ressources de développement en dehors d'un profile.
Le contenu
Code:

1 2 3 4 5 6 7 8 <build> <resources> <resource> ... </resource> </resources> </build>
sera toujours pris en compte meme lors de l'activation d'un profile.

Il te faut donc mettre ici que les ressources communes

Puis réaliser un profile de développement et un profile de production avec respectivement que les ressources de développement et de production
Code:

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 <build> <resources> <resource> <directory>src/main/resources/commons</directory> </resource> </resources> </build> <profiles> <profile> <id>dev</id> <build> <resources> <resource> <directory>src/main/resources/development</directory> </resource> </resources> </build> </profile> <profile> <id>production</id> <build> <resources> <resource> <directory>src/main/resources/production</directory> </resource> </resources> </build> </profile> </profiles>
Juste dernière remarque, comme dans l'exemple du lien du site, ne pas oublier de surcharger le plugin maven-jar-plugin avec un classifier de type 'dev' ou 'prod' pour bien identifier en terme de traçabilité au niveau du nom s'il s'agit d'un artefact de développement ou de production.

Je modifierai simplement comme ceci:
Code:

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 <build> <resources> <resource> <directory>src/main/resources/commons</directory> </resource> </resources> </build> <profiles> <profile> <id>production</id> <build> <resources> <resource> <directory>src/main/resources/production</directory> </resource> </resources> </build> </profile> <profile> <id>development</id> <activeByDefault>true</activeByDefault> <build> <resources> <resource> <directory>src/main/resources/development</directory> </resource> </resources> </build> </profile> </profiles>
Lancer avec aucun profile activera les resources commons + development, lancer avec -Pproduction activera les resources commons + production.

Et c'est tout propre en plus ;)

12/05/2009, 15h02
mpasteur

et les filters ?
Bonjour,

si ca peut aider pour les paramètres tel que jndi / chemins ... j'utilise plutôt les filtres (filters)

ce qui donne :
Code:

1 2 3 4 5 6 <build> <filters> <filter>src/main/filters/properties-${env}.properties</filter> </filters> ...
avec des profiles définis tel que:
Code:

1 2 3 4 5 6 7 <id>dev</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <env>dev</env> </properties>
la reference est la : http://maven.apache.org/guides/getti...resource_files

cdlt,
marc

Citation:
Envoyé par Tomekaa
Je modifierai simplement comme ceci:
Code:

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 <build> <resources> <resource> <directory>src/main/resources/commons</directory> </resource> </resources> </build> <profiles> <profile> <id>production</id> <build> <resources> <resource> <directory>src/main/resources/production</directory> </resource> </resources> </build> </profile> <profile> <id>development</id> <activeByDefault>true</activeByDefault> <build> <resources> <resource> <directory>src/main/resources/development</directory> </resource> </resources> </build> </profile> </profiles>
Lancer avec aucun profile activera les resources commons + development, lancer avec -Pproduction activera les resources commons + production.

Et c'est tout propre en plus ;)
Parfait ! Merci.
Quelques notions m'avaient échappé (build par défaut, activation par défaut), mais maintenant c'est enregistré.

18/05/2009, 03h53
Invité

Citation:

Envoyé par gboissinot

Tout premièrement, il faut essayer de ne pas contenir la variabilité au niveau de l'artefact mais plutôt de la déporter au serveur d'application.
L'idée est d'avoir un artefact générique acceptant en entrée des valeurs JNDI, des proprétés systèmes, … et c'est serveur d'application de développement, de recette, de production d'injecter les bons paramètres.
Dans les applications standardisés JEE : oui c'est possible.
Ainsi, Maven n'a été prévu pour gérer cela nativement.

Je comprends cette "philosophie", mais je n'ai pas encore les compétences JNDI. Les seuls fichiers qui diffèrent selon l'environnement sont log4j.xml et platform.properties (utilisé via Spring). Pour l'instant la couche web n'est pas développée et l'application pourrait fonctionner sans serveur d'application. Si tu as des pistes pour m'aiguiller, n'hésite pas. Merci.
18/05/2009, 23h30
gboissinot

Est-ce que tu sais précisément quels sont les éléments des fichiers log4j.xml et platform.xml qui varient?
19/05/2009, 00h17
Invité
Citation:

Envoyé par gboissinot

Est-ce que tu sais précisément quels sont les éléments des fichiers log4j.xml et platform.xml qui varient?

Les fichiers log4j sont très différents :
- development : ConsoleAppender DEBUG
- integration : DailyRollingFileAppender DEBUG
- production : DailyRollingFileAppender / AsyncAppender INFO + SMTPAppender ERROR
Cela dit, il est peut-être possible de les rendre plus similaires en déclarant tous les appenders, et en activant ou désactivant ceux qui nous intéressent selon l'environnement.

Le fichier platform.properties est (pour l'instant) plus succint :
Code:

1 2 3 4 db.url=jdbc:postgresql://localhost:5432/dbname db.user=dbuser db.password=dbpasswd db.debug=true
Bien que ce ne soit pas le sujet du topic, la solution JNDI m'intéresse car elle permettrait d'externaliser les informations confidentielles (identifiants, e-mails) de notre projet, dans le cas d'un éventuel passage à l'open-source.
23/05/2009, 01h13
gboissinot

Pour ton fichier plaform.properties, tu va effectivement pouvoir utiliser sans problème une ressource JNDI. En revanche, concernant ton fichier de configuration log4j.xml, c'est plus délicat.
J'avoue que pour ce besoin, je n'ai pas d'idées si tu veux laisser le fichier packagé dans l'archive Web.
Une solution serait peut-être de le fournir dans le classpath du container.