Brancher Nexus sur Active Directory (LDAP)

Après avoir perdu un peu de temps à configurer Nexus sur Active Directory par l'intermédiaire du protocole LDAP, Je vous propose de vous faire partager mon expérience sur le sujet et en français

Mon besoin était le suivant :

• Mettre en place un Nexus.
• Mettre en place un système d'authentification pour l'administration du Nexus.
• Réutiliser le  référentiel d'utilisateur de l'entreprise.
• Ne pas ouvrir l'administration de Nexus à tous les utilisateurs présents dans l'AD mais seulement à un groupe.

Une documentation très bien faite est mise à disposition par Sonatype Ici.

Le problème n'est pas dans la qualité de la documentation mais se brancher sur un AD par l'intermédiaire de LDAP n'est jamais simple : beaucoup d'options, de paramétrages, des contenu dans les référentiels LDAP très différents.

Etape 1 : Obtenir un accès

Avant de commencer, il faut obtenir un utilisateur/mot de passe qui soit capable de naviguer en lecture au sein de l'AD. En général, il faut créer ou faire créer un utilisateur générique par lequel vos applicatifs (comme Nexus) viendront interroger votre AD.

Une fois cet utilisateur en poche (ça peut prendre du temps à avoir ce genre de choses...) , je vous conseille de le tester avec un browser LDAP. Je me suis servi d'Apache Directory Studio. Il est Open Source et c'est une application RCP. Bref, il fait plutôt bien le job.

Il vous suffit donc de créer une connexion (host et port de l'AD, user, password) et hop vous pouvez naviguer à l'intérieur.

Il faut aussi créer un groupe AD et y rattacher les utilisateurs à qui vous souhaitez donner l'accès à l'administration de Nexus. Votre AD possède peut être déjà un groupe qui correspond à la population qui vous intéresse. Vous pouvez dans ce cas le réutiliser. Pour la suite de l'article, nous appellerons ce groupe "equipe-de-developpement".

Mais ça n'est pas fini...

Etape 2 : Obtenir une bonne vision de l'arborescence de l'AD

Le plus important et de récupérer l'adresse LDAP racine dans laquelle tous les utilisateurs se trouvent. Nous l’appellerons pour la suite de l'article "l'adresse racine utilisateur".

par exemple : CN=Users,DC=votreDomaine,DC=com

Mais ça n'est pas fini...

Etape 3 : configurer la partie LDAP de Nexus

Connectez-vous en admin sur Nexus et déplacez-vous dans la partie Security > "LDAP Configuration" accessible depuis le menu latéral gauche. C'est parti pour la partie conf : 

• Connection : (permet de définir les paramètres de connexion à l'AD)
• Protocol : Ldap
• Hostname : adresse de l'AD (le même que vous avez utilisé avec botre browser LDAP).
• Port : port de l'AD (en général c'est 389).
• Search Base : c'est l'adresse par défaut à partir de laquelle le requêtage LDAP se fera une fois connecté. Remplissez le avec l'adresse racine utilisateur.
• Authentication : (permet de définir la manière dont Nexus s'authentifie sur l'AD)
• Authentication method : Choisir "Simple Authentication"
• SASL Realm  : laisser vide.
• Username : le username de votre utilisateur générique ayant accès en lecture à AD.
• Password : le password de votre utilisateur générique ayant accès en lecture à AD.

Vous pouvez faire un "check authentication". Si tout est ok vous devez avoir un "LDAP connection and authentication test completed successfully." Ça veut dire que votre Nexus sait se connecter à votre AD.

• User Element mapping : (permet de définir la manière dont Nexus va vérifier si un user existe)
• Base DN : laisser vide (si vous avez bien renseigné dans la partie connection que l'adresse par défaut de requêtage est bien l'adresse racine utilisateur).
• User Subtree : à cocher.
• Object Class : Saisir "Person", c'est le type d'objet LDAP contenant les utilisateurs.
• User ID Attribute : Il faut indiquer le nom de l'attribut LDAP qui contient les logins utilisateurs AD. Saisir : "sAMAccountName"
• Real Name Attribute : Il faut indiquer le nom de l'attribut LDAP qui contient le nom complet des utilisateurs AD. Saisir : "displayName".
• E-Mail Attribute : Il faut indiquer le nom de l'attribut LDAP qui contient l'adresse mail des utilisateurs AD. Saisir : "mail".
• Password Attribute : Il faut indiquer le nom de l'attribut qui contient le mot de passe des utilisateurs AD. Laisser vide (c'est un attribut par défaut).
• Group Element Mapping : (permet de définir la manière donc Nexus va récupérer la liste des groupes).
• Group Type : Saisir "Dynamic Groups". Il y a 2 types de groupes LDAP : un groupe dynamique correspondant à un attribut dans un objet "user" LDAP. Un groupe statique, c'est le contraire, c'est la référence à une liste d'utilisateurs dans un objet LDAP "group". Avec AD, à priori, quand un groupe est créé il l'est en statique et dynamique. Autant donc choisir dynamique car il y a beaucoup moins de configuration ;-).
• Member Of Attribute : Il faut indiquer le nom de l'attribut LDAP dans lequel un groupe dynamique est défini. Saisir : "memberOf".

Vous pouvez faire un "Check User Mapping". Si tout est ok, Nexus vous affiche un début de liste d'utilisateurs qu'il a réussi à requêter. 

N'oubliez pas de faire "save" :-)

Mais ça n'est pas fini...

Etape 5 : Mapper votre groupe AD avec un rôle NEXUS.

Il faut maintenant configurer à Nexus pour que les utilisateurs de votre groupe AD equipe-de-developpement correspondent à un rôle dans Nexus, par exemple "Administrateur Nexus".

Déplacez-vous dans la partie "Roles" accessible depuis le menu latéral gauche :

• Sélectionner "Add" > "External Role Mapping"
• Realm : choisir "LDAP"
• Role : La liste des rôle LDAP de votre AD doit être présente. choisir votre groupe equipe-de-developpement
• Ajouter ensuite le Rôle associé en cliquant sur "add"
• Cocher le "Nexus Administrator Role"
• Cliquer sur OK

Mais ça n'est pas fini...

Etape 6 : activer l'authentification LDAP pour Nexus

Il faut maintenant simplement activer l'authentification par LDAP. Je dis "simplement", mais j'ai cherché un bout de temps avant de comprendre pour tout ça ne marchait pas ;-).

Déplacez-vous dans la partie "Administration" > "Server" accessible depuis le menu latéral gauche :

• Dans la partie "Security Settings": déplacer "OSS LDAP Authentication Realm" de "Available Realms" vers "Selected Realms".

That's all...

Ch'ti Jug sur Maven2

A cause du nom de mon blog, je suis obligé d'en parler :-).

J'ai participé hier à la 2ème session du ch'ti Jug dont le sujet était sur Maven2.

C'était Arnaud héritier qui animait la présentation. Il parle d'ailleurs de sa future intervention au Ch'ti Jug ici.

La présentation d'Arnaud était de qualité. Je n'ai pas forcément appris énormément de choses nouvelles sur Maven en revanche, je retiens que je suis d'accord avec lui sur les bonnes pratiques autour de Maven et que je vais dans le bon sens :-).

La petite touche d'humour est que j'ai gagné une licence IntelliJ IDEA, l'IDE dont on dit beaucoup de bien, en répondant à une question sur Maven : De quel projet est-il issu?... "and the answer is..." Turbine.

J'ai été étonné de l'affluence à la présentation. Pour une 2ème session, nous étions dans les 70 personnes "selon la police" :-). Quand on compare ce nombre aux affluences du Jug de Paris par exemple, c'est prometteur pour la suite de ce Jug régional!

Migration Maven 2 : 3ème épisode : retour d'expériences

Il est vrai que je n'avais pas fait de 3ème épisode concernant ce sujet de migration de maven1 vers maven2.

Voici alors le 3ème épisode de la migration plutôt sous la forme d'un retour d'expérience... tintintin...

La migration a été effectuée sur 2 gros projets J2EE avec des processus de build assez complexe. L'utilisation de maven2 est effective depuis maintenant quelques mois. Voici en vrac quelques remarques par rapport à des ajustements effectués après la migration :

• delta au niveau du contenu des archives j2ee. Les archives j2EE ont tendance à prendre de l'enbonpoint (gestion des dépendances transitives, repository différents) : bien définir les exclusions et scopes.
  
• changement de comportement du build suite à l'apparition d'une nouvelle version du plugin : fixer la version de tous les plugins.
• confusion possible avec les fichiers de conf maven1 : une fois que l'utilisation maven2 est bien intégrée, faire le ménage sur les anciens fichiers de conf maven1 qui "polluent" le gestionnaire de sources.

Maven1 est en train d'être oublié par les équipes de développement, preuve que la migration est un succès.

Maven et les dépendances transitives

Une des évolutions de maven2 par rapport à maven1 concerne la gestion de dépendances transitives : La définition d'une dépendance au niveau d'un projet entraîne la récupération des dépendances de cette dépendance et ainsi de suite...

Sur de gros projets, la gestion des dépendances avec Maven est quasiment indispensable. J'ai même dû mal à comprendre qu'on puisse faire sans.

Avec les dépendances transitives, on se retrouve vite à récupérer la terre entière et à avoir des dépendances qui utilisent des dépendances transitives communes mais dans des versions différentes...

On voit apparaître des exceptions du type "NoClassDefFoundError" à l'exécution et c'est là que le casse tête commence...

Voici ce que j'utilise pour résoudre ce genre de problème :

• la commande du plugin maven "dependency" pour découvrir les dépendances en double :
  

  mvn dependency:tree

• La mise en place de tags d'exclusion au niveau des pom.xml pour permettre de définir une dépendance mais d'exclure certaines de ces dépendances transitives :
  

  <dependency>
   <groupId>yourDependencyGroupId</groupId>
   <artifactId>yourDependencyArtifactId</artifactId>
   <version>yourDependencyVersion</version>
   <exclusions>
     <exclusion>
       <groupId>ExcludedTransitiveDependencyGroupId</groupId>
       <artifactId>ExcludedTransitiveDependencyArtifactId</artifactId>
     </exclusion>
   </exclusions>
  </dependency>

Java: Scanner un répertoire

Dans la cadre du développement de plugin maven 2, récupérer un ensemble de fichier selon certains critères peut être intéressant :
- récupérer un sous ensemble de fichiers source java.
- récupérer un ensemble de properties.
- ...

Plexus est là! Cette librairie est déjà largement utilisée par les plugins maven 2.

La classe DirectoryScanner vous permettra de faire ça.
Il faut lui spécifier :
- un répertoire de base.
- des patterns d'inclusions et d'exclusions (en options) du style "**/**.properties".
puis appeler la méthode scan() et récupérer ensuite un tableau avec l'ensemble des chemins des fichiers correspondant à la recherche.

Pour plus d'informations, tout est dans la javadoc de la classe.

wonderfull!

Migration Maven 2 : 2ème épisode : la procédure

Suite de la migration... Comme je le précisais dans le première épisode dans ce post. J'ai procédé à la migration de gros applicatifs J2EE de maven 1 vers maven 2.

Une fois devant l'écran, un peu comme un écrivain, c'est un peu la page blanche : Par où commencer???

Je vais m'efforcer de vous décrire la procédure que j'ai appliquée:

• Maitriser et comprendre l'applicatif et le processus de build maven 1 existant :

Avant tout, je pense qu'il faut bien connaître l'applicatif ainsi que le processus de build à migrer, en tous cas d'un point de vue technique. Cette connaissance va permettre de déceler les points sur lesquels il va falloir mettre l'accent plus particulièrement (où ça va coincer :-))
Dans mon cas, il se trouve que quasiment chaque projet java (l'applicatif est composé d'un ensemble de projets java) est muni de son project.xml mais surtout est quasiment toujours accompagné d'un fichier maven.xml. Pas de chance, il y a pas mal de spécificités de build qui ont été mises en œuvre : génération de code source en tout genre, concaténation de fichiers, exécution de tâches ant diverses et variées,...

• Posséder une plateforme "témoin" :

Un des principales objectifs est de réussir à fournir, avec un processus de build différent, les mêmes livrables j2EE (un ear et plusieurs wars dans mon cas). Je me suis installé l'ensemble de la plateforme de développement et effectué des builds avec le processus de build maven 1 existant. Ce système permet d'avoir un environnement "témoin" permettant d'effectuer des comparaisons entre l'ancien build et le nouveau build. Concrètement, ça revient à récupérer 2 fois les projets de sources sur le poste:
- les projets de sources maven 1 "témoin".
- les projets de sources sur lesquels travailler pour effectuer la migration maven 2.

• Migrer les dépendances

Dans un premier temps, il faut analyser et lister les dépendances dont le projet a besoin. Un bon vieux tableur facilite le travail. Pour chacune de ces dépendances, il faut vérifier si elle est disponible dans un repository maven 2 sur la toile grâce à ce site par exemple. Pour celles qui n'existent pas, il faut les installer dans le repository maven 2 de l'entreprise (s'il n'y en a pas, c'est un travail à faire... et pourquoi pas aussi mettre en œuvre Archiva , oulaaa, je m'emballe!) :

mvn deploy:deploy-file -Durl=file://C:\m2-repo \
                    -DrepositoryId=some.id \
                    -Dfile=your-artifact-1.0.jar \
                    [-DpomFile=your-pom.xml] \
                    [-DgroupId=org.some.group] \
                    [-DartifactId=your-artifact] \
                    [-Dversion=1.0] \
                    [-Dpackaging=jar] \
                    [-Dclassifier=test] \
                    [-DgeneratePom=true] \
                    [-DgeneratePom.description="My Project Description"] \
                    [-DrepositoryLayout=legacy] \
                    [-DuniqueVersion=false]

• Mettre en place un premier pom.xml

Dans le cadre d'applicatif j2EE découpé en un ensemble de projets Java/Maven, il est difficile de migrer l'ensemble des POM en une seule fois. Il est important de procéder de façon itérative et de se concentrer sur la migration d'un des projets (simple en terme de build si possible) pour commencer.

• Capitaliser et centraliser le build

Les possiblités en terme d'héritage et de gestion "multi module" de Maven permettent :
- de réutiliser comportement de Pom en définissant des Pom parent, grand-parent, ...
- de piloter l'ensemble des projets en définissant un Pom multimodule.

En conservant à l'esprit ce type de pratique, j'ai progressivement procédé à des refactorings de Pom au fur et à mesure de la mise en place des Pom des projets. Voici une version simplifiée de mon arborescence de Pom :

pom "base"
pom projet utilitaire
...
pom "webapp"
  pom webapp1
  pom webapp2
  ...
pom "ejb"
  pom ejb1
  pom ejb2
  ...

• Migrer les spécificités maven 1 : "exit maven.xml"

Une fois le comportement global du build définit, les spécificités de build maven 1 viennent vite bloquer le processus de migration, notamment en ce qui concerne la génération de code qui a un impact sur la compilation (ça compile si le code a été généré sinon non...).
Voici quelques exemples de spécificités :
- génération des classes techniques ejb avec ejbDoclet de XDoclet : cette génération était pilotée en Maven 1 par le lancement de tâche Ant. Le plugin maven2 antrun a permis de faire la migration.
- génération d'un fichier par concaténation d'un ensemble de fichiers : La concaténation était effectuée en jelly... La seule solution était de mettre en place un plugin maven 2 qui effectue le travail.

• Rester zen...

Une fois passé le cap du "BUILD SUCCEFULL" (qui , d'ailleurs, fait bien plaisir), le gros du travail est effectué. Le reste correspond a des ajustements mais des ajustements qui font d'ailleurs perdre pas mal de temps. Dans mon cas , le build du projet dans son ensemble prend dans les 10 minutes. Pour tester une modification, une seule solution : reBUILDER! Il faut savoir être patient et se dire que si on devait le faire soi-même on mettrait 3h pour faire un seul build...

• Comparer les livrables j2EE entre le build maven 1 témoin et le nouveau build maven2

Les principaux ajustements à effectuer pour obtenir des contenus de livrables (ear et wars) identiques concernent les dépendances dans les archives war et ear. Avec maven 2 et la transitivité des dépendances, j'ai dû ajuster les choses en terme de versions et de porter de jars pour finalement obtenir des dossiers de "lib" identiques.

• Tester les nouveaux livrables

Il faut ensuite déployer les nouveaux livrables pour valider que l'application fonctionne toujours... et procéder à des ajustements en terme de fichiers de conf J2EE notamment ceux propres au serveurs d'applications (ex : weblogic.xml, jboss-web.xml, ...).

Une fois ce cap franchi, on pense avoir quasiment terminé... mais il reste des choses à faire...
Ha, mon build vient de se terminer, la suite dans le prochain épisode...

Migration Maven 2 : 1ère épisode : Le contexte

Je me suis attelé ses derniers jours (voir mois) chez mon client à entreprendre la migration de gros applicatifs maven 1 vers maven 2. Je vais essayer de vous faire profiter d'un retour d'expérience sur le sujet car je n'ai pas trouvé de méthodes miracles de migration.

Je vais y consacrer un certains nombres de billets. Le dossier est assez touffu...

Pour commencer, voici le contexte des applicatifs qui doivent être migrer :

• applicatifs j2EE multi module (ear contenant un ensemble d'ejb sessions + mutli war).
• héritage de projet maven.
• utilisation du multi-projet.
• changement du type de packaging (simple jar, ejb-jar ou ejb-jar-client) en fonction de propriétés au moment du build.
• génération des classes techniques des ejbs avec xdoclet (ejbdoclet).
• génération de classes techniques type "delegate" pour simplifier l'appel aux ejbs avec xdoclet (template doclet).
• génération des sites projets.
• utilisation de l'intégration continue avec continuum.
• dans les 8000 fichiers au contrôle de source (sources + ressources).
• une dizaine de minutes à attendre pour faire un build complet.
• entre 5 et 20 développeurs par applicatifs.
• déjà en production pour certains applicatifs.
• application de type stratégiques.
  

Avant tout on peut se demander pourquoi? Voici les arguments que j'ai pu trouver à part de dire qu'il faut le faire :-) :

• Pour permettre d’utiliser les nouvelles fonctionnalités de Maven2 (transitivité des dépendances, profile, scope, …).
• Pour profiter des modifications effectuées sur les fonctionnalités existantes (gestion multiprojet, héritage).
• Pour profiter des améliorations de performances que propose maven 2 (consommation mémoire pendant le build, temps de build …).
• De simplifier les scripts de build.

Je détaillerai par la suite la démarche de migration qui a été mise en œuvre dès que j'ai un peu de temps entre 2 builds :-).

La suite dans le prochaine épisode...

Maven : war dépendant d'un autre war

Comment utiliser la gestion de dépendances de maven entre war.

La problématique posée était la suivante : comment capitaliser et partager des éléments communs dans plusieurs applications web. Ce type de besoin provient en fait à l'existence d'un "framework" proposant des composants communs chez mon client pour permettre de réutiliser des jsp, des scripts Javascripts, des tlds, des images, ... on va l'appeller le "framework war"

Le but pour moi est de récupérer dans les sources de mon application web dans le répertoire racine de la webapp, l'ensemble des composants du framework war.

En cherchant un peu, on peut voir que le plugin war de maven propose un goal war:inplace qui semblerait coller à mon besoin!!! cool!!

Je définis alors en dépendance de mon application web mon framework war :

<?xml version="1.0"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>fr.sevellec.test</groupId>
<artifactId>my-application-webapp</artifactId>
<packaging>war</packaging>
<name>my application de test pour le fwk</name>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>fr.sevellec.fwk</groupId>
<artifactId>fwk-war</artifactId>
<version>1.0</version>
<type>war</type>
</dependency>
</dependencies>
</project>

En plus de la définition des dépendances, il faut préciser le comportement du goal war:inplace :

<!-- plugin WAR -->
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.0.2</version>
<executions>
<execution>
<id>inplace</id>
<phase>generate-sources</phase>
<goals>
 <goal>inplace</goal>
</goals>
</execution>
</executions>

<configuration>
<warSourceDirectory>webapp</warSourceDirectory>
<dependentWarExcludes>
WEB-INF/web.xml,META-INF/**,WEB-INF/classes/**,WEB-INF/lib/**,WEB-INF/conf/**
</dependentWarExcludes>
<warSourceExcludes>/webapp/WEB-INF/lib/**</warSourceExcludes>
<useCache>false</useCache>
</configuration>
</plugin>

La complexité ensuite réside dans les ressources existants à la fois dans mon application web et à la fois dans mon framework war (par exemple, web.xml, struts-config.xml,...). Si j'execute la commande war:inplace, les ressources du framework war vont venir écraser les ressources existantes qui auraient été modifiées. Il faut alors mettre en place un système d'exclusion comme on peu le voir dans la configuration du plugin war :

<dependentWarExcludes>
WEB-INF/web.xml,META-INF/**,WEB-INF/classes/**,WEB-INF/lib/**,WEB-INF/conf/**
</dependentWarExcludes>

J'ai défini des dépendances au niveau de mon framework war. Je les récupère par transitivité dans le war de mon application web. Super! En revanche, l'utilisation du goals war:inplace rapatrie l'ensemble des dépendances transitives de mon framework war dans le dossier WEB-INF/lib de mon application web. Ce comportement me pose problème car en utilisant eclipse/sysdeo/tomcat ou eclipse/wtp/tomcat pour faire du développement en mode "exploded", la gestion du chargement des librairies est déléguées au plugin sysdeo ou WTP. La présence des librairies dans WEB-INF/lib pendant le développement perturbent le comportement des plugins sysdeo ou WTP.
Pour supprimer ces librairies génante en mode "exploded", j'ai utilisé le plugin ant-tun de maven et exécuté un delete... Je sais, ce n'est pas forcément très élégant mais ça à le mérite de fonctionner :

<!-- plugin ANT -->
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
    <execution>
        <phase>generate-sources</phase>
        <configuration>
            <tasks>
                <delete dir="${basedir}/webapp/WEB-INF/lib" />
                <delete dir="${basedir}/webapp/WEB-INF/classes" />
                <delete dir="${basedir}/webapp/META-INF" />
            </tasks>
        </configuration>
        <goals>
            <goal>run</goal>
        </goals>
    </execution>
</executions>
</plugin>

L'ordre de déclaration des plugins dans le pom.xml de ma webapp à une importance. Il faut déclarer le plugin war avant le plugin ant car les goals des 2 plugins s'exécutent dans la même phase.

Continuum, Maven2 et Clearcase

C'est possible!

Faire de l'intégration continue en utilisant le trio Continuum / Maven2 / Subversion est bien répandu. Le trio maintenant bien huilé...

Il se trouve que chez mon client, le système de gestion de contrôle de source est le produit d'IBM : Rational Clearcase.

Dans le cadre de la mise en oeuvre d'un serveur d'intégration continue, il a alors fallu faire fonctionner le trio Continuum / Maven2 / Clearcase. C'est au moment de commencer qu'on ressent un grand moment de solitude... Le but du jeu est de permettre à Continuum par l'intermédiaire de Maven de faire un "update" des sources pour vérifier si des choses ont changées et relancer une commande de build Maven.

Une particularité de Clearcase, qui reste un outil très puissant (mais un peu usine à gaz à mon gout), concerne la façon dont il structure son arborescence de sources sous forme de composants.

La difficulté principale réside dans la définition de l'url du SCM dans chacun des pom des projets.

Voici la procédure de mise en oeuvre :
*rajouter un fichier de conf clearcase sur le serveur d'intégration continue dans le fichier MAVEN_HOME/conf/clearcase-settings.xml avec ce contenu :

<clearcase-settings>
<useVWSParameter>false</useVWSParameter>
<clearcaseType>UCM</clearcaseType>
</clearcase-settings>

*rajouter l'url scm dans chacun des pom de vos projets :

 <scm>
 <connection>scm:clearcase:load \<My_Vob\My\Project\Dir>:/<PVOB_Name>:<View_Name></connection>
</scm>

où :
- My_Vob\My\Project\Dir : nom du vob dans lequel se trouve le projet + chemin d'accès à la racine du projet.
- PVOB_Name : nom du PVOB. le PVOB correspond au nom du projet racine dans le project explorer du client Clearcase.
- View_Name : nom de la vue Clearcase

*Il faut ensuite importer le pom du ou des projets dans continuum

*Il faut enfin définir des commandes maven de build dans chacun des projets. Attention! Il faut modifier le champs "Nom du fichier POM*" : au lieu de :

pom.xml

il faut préciser le chemin relatif d'accès au fichier + le nom du fichier. Il faut renseigner le champ de cette façon :

<My_Vob\My\Project\Dir\>pom.xml

Maven 2, recherche de jars

J'utilise et abuse de maven dans les projets java notamment chez mon client. Comment faisait-on d'ailleurs avant la création de cette outil???

Ce qu'on peut parfois lui reprocher, c'est la perte de temps qu'occasionne la définition des dépendances dans le pom : la recherche de dépendances sur les repositorys distant sur le net prend un temps fou même si le système de dépendance transitive permet d'alléger la déclaration des dépendances dans le pom.

Un collègue m'a présenté un site qui me permet maintenant de gagner beaucoup de temps sur cette recherche :

http://www.mvnrepository.com/

Le site propose un système de recherche permettant de trouver une dépendance :

Une fois la dépendance trouvée et dans la bonne version, il fournit le bout de code xml à rajouter pour la déclarer dans le pom! magique!