04 juillet 2012

Maven n'aime pas WebDav

Maven 2 disposait d'un client webdav pour le déploiement d'artifacts dans les dépôts de ce type
Maven 3, pourtant conçu pour être 100% compatible, n'a plus cet extension. 

La conséquence immédiate, c'est qu'il n'est plus possible de faire une "mvn deploy:deploy-file" vers ce type de repository. On est obligé d'avoir recours à une astuce pourrie, consistant à avoir un pom.xml bidon qui configure maven avec l'extension nécessaire, juste pour invoquer le deploy-file :

<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/POM/4.0.0" 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.example</groupid>
    <artifactid>webdav-deploy-pom</artifactid>
    <packaging>pom</packaging>
    <version>1</version>
    <name>Webdav Deployment POM</name>

    <build>
        <extensions>
            <extension>
                <groupid>org.apache.maven.wagon</groupid>
                <artifactid>wagon-webdav</artifactid>
                <version>1.0-beta-2</version>
            </extension>
        </extensions>
    </build>

</project>


Ca c'était pour l'astuce du jour.
On peut aussi chercher le pourquoi de cette incompatibilité. 

  • Il faut admettre que le composant wagon-webdav, péniblement amené à une version 1.0-beta-2 est un morceau de code assez obscur et peu maintenu. Dans la refonte générale à l'origine de Maven 3, il n'était pas aberrant de le mettre au placard.
  • Il faut aussi admettre que c'est un protocole assez merdique, qui va nécessiter 40 requêtes HTTP pour tester puis créer chaque niveau de répertoire pour finalement n'uploader qu'un unique fichier  - avis personnel, il a sans doute aussi des avantages.
  • Il faut aussi savoir que Nexus gère le déploiement en HTTP POST "brut" et crée la hiérarchie de répertoires à la volée. Je ne suis pas sur pour Artifactory ou Archiva mais c'est bien possible qu'ils fassent de même vu que dans ces systèmes le "groupId" n'est plus un répertoire mais un identifiant logique. Tous ceux qui utilisent ces outils n'ont donc que faire de ce wagon-webdav.

Cependant, aujourd'hui le projet Apache Maven dispose d'un nouveau composant WebDav basé sur jackrabbit, 100% fonctionnel, bien conçu et supporté. Le premier argument saute. Le second est discutable, mais si on n'utilisait que des outils et des protocoles bien foutus on ne ferait pas grand chose de nos ordis. Quand au troisième... il me semble que le retour de WebDav dans maven 3.0.x serait la preuve que le projet est indépendant de tout éditeur.

Enfin, je ne voudrais influencer personne ;)

3 commentaires:

Jérôme a dit…

Tout à fait d'accord :-)

Unknown a dit…

Je ne suis pas tout à fait d'accord.
Rajouter l'extension permet d'indiquer quel protocole, on va utiliser pour deploy, webdav, ssh, ftp, etc...

D'ailleurs aucun des protocoles cités ci-dessus n'est dans le core de maven, une extension doit être à chaque fois précisée.

Pour le FTP :
http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ftp.html

Pour le SSH :
http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ssh-external.html

Pourquoi je préfère la solution actuelle, car je pense que maven doit être une base et on rajoute les composants qu'on souhaite utiliser. D'ailleurs depuis maven 3, il est conseillé de précisé les versions des plugins qu'on utilise, une extension n'est pas une sorte de plugin ?

Cela permettra si un jour le composant webdav est modifié (il y a aucune raison à cela change, quoi que la trace degeu qu'on aperçoit au déploiement d'un artifact) de changer de version, ce qui ne sera pas possible si il était incorporé dans le core de maven. Mais ceci est un avis perso :)

Unknown a dit…
Ce commentaire a été supprimé par l'auteur.