Il parait que je dis toujours que du bien de Maven (c’est tout du moins ce que certains ressentent en écoutant le podcast Les Cast Codeurs). C’est pourtant, je pense, loin d’être la vérité et ceux qui peuvent assister aux différents Java Users Groups que j’ai pu présenter doivent pouvoir confirmer que je n’hésite pas aussi à casser du sucre dessus.
Certainement pour me punir voilà que je tombe ce soir sur un bug qui m’a fait perdre 30 minutes. Je ne compte pas rédiger un blog par jour pour décrire un bug Maven (même si il y aurait largement de quoi faire) mais en partageant l’information j’espère éviter à quelques autres ce soucis.

Tout débute par un sous projet de GateIn (WSRP) dans lequel on souhaite filtrer un fichier de ressources. Jusque là, rien d’exceptionnel, cela fait partie des fonctionnalités de Maven depuis des années.
On rajoute dans le POM l’activation du filtrage :
<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">
   ...
   <build>
      <resources>
         <resource>
            <directory>src/main/resources</directory>
            <filtering>true</filtering>
         </resource>
      </resources>
   </build>
</project>

Nous plaçons un fichier wsrp.properties dans le répertoire src/main/resources avec la propriété ${project.version} pour que Maven la filtre :
#
# JBoss, a division of Red Hat
# Copyright 2010, Red Hat Middleware, LLC, and individual
# contributors as indicated by the @authors tag. See the
# copyright.txt in the distribution for a full listing of
# individual contributors.
#
# This is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2.1 of
# the License, or (at your option) any later version.
#
# This software is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this software; if not, write to the Free
# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
# 02110-1301 USA, or see the FSF site: http://www.fsf.org.
#
wsrp.service.version=${project.version}

On lance Maven et on s’attend à ce que la propriété soit remplacée dans le fichier properties copiée dans le répertoire target/classes….. mais rien !!
Je me mets alors à tester la syntaxe alternative @project.version@ ainsi qu’un propriété simple injectée via les POM ou la ligne de commande …. rien. Pas de filtrage.
Je commence alors à tester avec différentes versions du plugin resources (le projet utilise la version 2.4.1). Je suis d’ailleurs bien content d’avoir mis sous la forme d’une propriété toutes les versions des plugins pour faire ce genre de test en passant la valeur en ligne de commande. 2.4, 2.4.1, 2.4.2 KO. Par contre la 2.3 fonctionne.
C’est énorme !!!! Comment le filtrage peut ne pas fonctionner et ce sur les 3 versions du plugin ?
Je cherche dans les bug ouverts et voilà que je découvre l’horrible bug MRESOURCES-104 !!
Les délimiteurs des tokens/propriétés à remplacer/filtrer sont par défaut @XXXX@ ou ${XXXX}. Le bug se trouve au niveau du parsing des fichiers car si le plugin trouve un délimiteur de début sans fin, il s’emmele les pinceaux et arrête de filtrer.
De ce fait si dans le fichier à filtrer on trouve un caractère @ seul, comme dans l’entête JBoss, le filtrage ne fonctionne pas.
Il existe cependant un contournement indiqué dans les commentaires qui consiste à désactiver les délimiteurs par défaut pour ne définir que la version ${} :
<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">
   ...
   <build>
      <resources>
         <resource>
            <directory>src/main/resources</directory>
            <filtering>true</filtering>
         </resource>
      </resources>
      <plugins>
         <!-- WORKAROUND for : http://jira.codehaus.org/browse/MRESOURCES-104 -->
         <plugin>
            <artifactid>maven-resources-plugin</artifactid>
            <configuration>
               <delimiters>
                  <delimiter>${*}</delimiter>
               </delimiters>
               <usedefaultdelimiters>false</usedefaultdelimiters>
            </configuration>
         </plugin>
      </plugins>
   </build>
</project>

Et voilà comment j’ai perdu 30 minutes. Et oui Maven n’est pas magique et il existe des bugs !! Le mythe est tombé.
Mais une fois de plus lorsque l’on propose des services de plus en plus haut complexes on s’expose à créer des bugs encore plus pervers. Maintenant je n’ai plus qu’à voir si en 30 minutes j’arrive à le corriger.
Est ce que c’est pour cela que je vais remettre en cause les fondements de Maven ? Et bien non. Rien n’est parfait mais je crois en la nécessité de standardiser le build et je ne pense pas que les autres solutions existantes soient aujourd’hui exemptes de bug. En tout cas je regarde toujours ce qui se passe à coté et j’espère bien que tout ou tard la compétition renaitra pour motiver encore plus l’équipe Maven.