On a souvent besoin de plusieurs profils lors du développement d'une application. Prenons par exemple une application web qui a besoin de 2 profils : - un profil auth
, où l'authentification est activée. C'est la version de production - un profil noauth
, où l'authentification est désactivée. C'est la version par défaut, utile pour les développeurs.
L'objectif de cet article est d'illustrer comment gérer cette situation avec Maven. On souhaite donc utiliser Maven pour réussir à :
Cela à l'air simple comme cela, mais dans la réalité, c'est loin d'être facile. Après beaucoup d'effort, voici une solution qui fonctionne.
Il faut
classifier
pour le profil noauth
noauth
sous un autre artifactId, en utilisant le goal deploy-file
du plugin deploy
Voici les 2 bouts de configuration pour faire cela :
<plugin>
<artifactid>maven-war-plugin</artifactid>
<configuration>
<classifier>noauth</classifier>
</configuration>
</plugin>
<plugin>
<artifactid>maven-deploy-plugin</artifactid>
<version>2.4</version>
<configuration>
<skip>true</skip>
</configuration>
<executions>
<execution>
<id>deploy-mock</id>
<goals>
<goal>deploy-file</goal>
</goals>
<phase>deploy</phase>
<configuration>
<repositoryid>${project.distributionManagementArtifactRepository.id}</repositoryid>
<file>${build.directory}/${build.finalName}-noauth.${packaging}</file>
<url>${project.distributionManagementArtifactRepository.url}</url>
<artifactid>${artifactId}-noauth</artifactid>
<groupid>${groupId}</groupid>
<version>${version}</version>
<packaging>${packaging}</packaging>
</configuration>
</execution>
</executions>
</plugin>
Pour déployer les 2 versions lors de la release, le plus simple est d'utiliser les commandes suivantes :
mvn release:prepare -P auth
mvn release:perform -P auth
cd target/checkout
mvn clean deploy
Ainsi, la release est effectuée et les 2 versions seront déployées correctement. Note : comme la version de prod est la vesion auth
, la release est faite avec ce profil. Note : on peut utiliser l'option --batch-mode
pour éviter la saisie des paramètres lors de la commande mvn release:prepare
, et automatiser la release dans le serveur d'intégration continue.
Pour que les autres équipes (qualification, pre prod, prod) puissent récupérer les versions, on utilise le pom suivant :
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelversion>4.0.0</modelversion>
<groupid>com.octo.tools</groupid>
<artifactid>maven-artifact-getter</artifactid>
<packaging>pom</packaging>
<version>0.0.1-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<artifactid>maven-dependency-plugin</artifactid>
<configuration>
<artifactitems>
<artifactitem>
<groupid>${artifact.groupId}</groupid>
<artifactid>${artifact.artifactId}</artifactid>
<version>${artifact.version}</version>
<type>${artifact.packaging}</type>
<destfilename>${artifact.fileName}</destfilename>
</artifactitem>
</artifactitems>
</configuration>
</plugin>
</plugins>
</build>
</project>
Après l'exécution de cette commande, le war demandé se trouve dans target/dependency/monprojet.war
. On peut donc le déployer facilement dans un serveur d'application, soit avec maven, soit avec des commandes shell. Il suffit de changer l'artifactId en monprojet-noauth
pour récupérer la version noauth
. Cela fonctionne pour une version SNAPSHOT ou une version release (Cela s'adapte donc parfaitement dans un job Hudson paramétré).
En vrac, quelques-uns des problèmes rencontrés
deploy
plante sur des artefact avec classifier
classifier
le plugin deploy
2.4