Le bug Maven du jour : MRESOURCES-104

Apache MavenIl 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.

GD Star Rating
loading...
GD Star Rating
loading...
Le bug Maven du jour : MRESOURCES-104, 6.6 out of 10 based on 5 ratings

10 thoughts on “Le bug Maven du jour : MRESOURCES-104”

  1. merci pour cette info :-)
    dis nous si tu auras réussi à corriger le bug en 30min !!

    GD Star Rating
    loading...
    GD Star Rating
    loading...
  2. J’ai eu le même soucis avec une propriété qui donne l’URL de la base de données :

    dataBase.url = jdbc:oracle:thin:@localhost:1521:xe

    et j’ai évidemment comme toi perdu du temps et mes nerfs sur ce problème avant d’arriver à la même conclusion. Il faudrait qu’on connecte nos cerveaux, on gagnerait du temps du coup

    GD Star Rating
    loading...
    GD Star Rating
    loading...
    1. Perso j’ai pas du voter sur les dernières releases de ce plugin mais on aurait du mettre en avant ce bug pour qu’il soit corrigé.
      Il y a pas mal d’issues liée à ce problème :
      http://jira.codehaus.org/browse/MRESOURCES-117
      http://jira.codehaus.org/browse/MRESOURCES-112
      http://jira.codehaus.org/browse/MRESOURCES-70
      Et comme le dis un utilisateur, ça marche depuis des lustres avec Ant le filtrage avec @XXX@.(Et oui réinventer la roue ça n’a pas que du bon – cf Thread sur la ml des Cast Codeurs à propos de Maven).

      GD Star Rating
      loading...
      GD Star Rating
      loading...
    1. C’est ce que j’ai fait mais c’est un contournement et une régression par rapport à la version 1.3 à cause du rajout du format @XXX@
      Enfin, une fois de plus les logs sont à chier car le parser pourrait dire qu’il tombe sur un truc qu’il aime pas.

      GD Star Rating
      loading...
      GD Star Rating
      loading...
  3. Bonjour,

    Problème ou comportement normal ? scope “optional” et maven-war-plugin !!!
    Dans un module web je déclare une dépendance “optional” et surprise dans le war,
    la dépendance (ains que ses propres dépendances) apparait bien dans la manifest du projet – c’est normal
    par contre, dans le “WEB-INF/lib”, je retrouve toutes les dépendances de ma dépendance !!!! je sais pas si c’est claire ????

    GD Star Rating
    loading...
    GD Star Rating
    loading...

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>