blog.bressure.net

Carnet professionnel d'un informaticien

Gestion de projet, Paramétrage

Un environnement de developpement Java: mise en place d’Archiva

admin

Un concept fondamental de maven est celle du dépôt de librairie qui met à disposition des projets toutes les librairies dont ils dépendent. Cela permet de ne jamais copier une librairies tiers dans l’arborescence du projet comme on peut le voir dans certains projets fait avec ant. Avec maven on ne met dans le serveur de source uniquement des…sources et tout ce qui est fabriqué à partir de sources doit être mis à disposition dans un dépôt de librairie : le repository. Il y a 2 types de repository: l’un local à l’utilisateur qui est en train de faire un build, l’aute dit distant qui permet à tout utilisateur de bénéficier de librairies produites par d’autre build. Le repository local va accueillir une copie des librairies (dites artefacts) provenant des repository distants mais il ne  s’agit là que d’un mécanisme technique pour accélérer le build. Grâce à maven sur la machine de l’utlisateur une librairies n’est jamais dupliquée entre les projets: tous vont utiliser la librairie qui se trouve dans le repository local.

Le repository distant peut être multiple: une organisation va avoir son  dépôt maven 2 pour accueillir ces propres librairies issues de ces propres projets. Mais ces projets vont sans doute utiliser des librairies tierces en provenance d’internet ne serait-ce que pour avoir les librairies dont dépend maven 2 lui-même. L’accès du build à internet pose un premier problème à certains réseaux d’entreprises. Il faut alors avoir un miroir interne des librairies publiques. En plus la simple fonction de mirroir, le repository distant doit aussi être celui qui contient les différentes librairies interne produite par l’organisation. Dans de larges projets ou quand la gestions des dépendances doit être contrôlée par projet entier, il faut que le serveur de librairies ait une gestion des droits. Par exemple un projet donné va utiliser un repository qui ne va lui fournir que des librairies autorisées. Un autre projet aura droit à d’autres librairies. On peut répondre à ce besoin par l’utilisation de plusieurs repository mais on utilisera avantageusement Archiva qui est un serveur de repository.

Nouc choisissons la version standalone d’archiva. Après avoir décompresser l’archive, aller modifier le fichier <archiva_dir>/conf/jetty.xml afin de spécifier le port http 9090 au lieu de 8080 déjà utilisé par continuum. Modifier aussi le port https en 9443 au lieu de 8443. Installer ensuite archiva en tant que service à l’aide des commandes suivantes

sudo ln -s /home/thierry/Programmes/apache-archiva-1.2-M1/bin/archiva /etc/init.d/archiva

sudo update-rc.d archiva defaults 80

sudo /etc/init.d/archiva start

Maintenant nous allons créer un repository virtuel dédié à notre projet. Le principe est d’avoir une entrée unique dans la définition du repository distant pour tous les artefacts possibles afin de simplifier la configuration dans le projet et de déporter le recensement des repository distant dans archiva. Pour ce faire on déclare dans le projet un seul repository en mettant dans le fichier pom.xml

<repositories>
<repository>
<id>project</id>
<name>Archiva Managed Unified Repository</name>
<url>http://localhost:9090/archiva/repository/vroom/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>

Cette déclaration dit que le projet doit aller chercher es dépendances dans le repository qui porte le même nom que le projet. En fait il s’agira d’un repository virtuel qui va regrouper tous les repository autorisé pour le projet. Nous le créeront plus tard. Pour l’instant définissons le repository de déploiement des artefacts produit. Ainsi dans la section <distributionManagement> du fichier pom.xml ajouter les déclarations suivantes:

<snapshotRepository>
<id>snapshots</id>
<url>http://localhost:9090/archiva/repository/vroom-snapshots</url>
</snapshotRepository>
<repository>
<id>internal</id>
<url>http://localhost:9090/archiva/repository/vroom-internal/</url>
</repository>

On voit que le nom du repository de déploiement ne respecte pas la convention mais archiva utilise l’identifiant du repository comme suffixe de l’url. Je propose donc un contournement <nom_repo>-snaphots en <nom_repo>-internal. Dans déclaration on indique 2 repository distincts pour les snapshots et les versions finales. Dans le cadre de notre article l’usage dun repository pour le projet peut paraître surfait mais cette pratique prend son sens quand on veux regrouper dans un repository des projets ayant un lien et que l’on ne veux pas partager avec d’autres projets.

Maintenant on peut créer le repository virtuel pour le projet vroom qui va regrouper

Tout d’abord il faurt créer les repository spécifiques au projet. Aller dans le menu de gauche pour sélectionner repositories puis cliquer sur l’icone Add. Voici une capture montrant la création du repositoy vroom-internal :

Archiva repository creation Archiva repository creation snapshot

Enfin il reste à les regrouper dans le repository virtuel: aller dans le menu de gauche pour sélectionner Repositories Group. Dans le champs n haut à droite saisir vroom comme identifiant puis cliquer sur Add group. Dans le groupe qui vient d’être créé, ajouter les repository réels: il suffit à ce stade d’ajouter tous les repository pour mettre dans le groupe les repository par défaut de continuum (internal et snapshots) ainsi que les 2 spécifiques au projet vroom (vroom-internal et vroom-snapshots).

Archiva virtual repository

Archiva offre un mécanisme de gestion de droit, il nous faudra créer un utilisateur ayant le rôle Observer pour la lecture et Manager pour le déploiement d’artefact. Comme nous utilisons un repository virtuel il est judicieux de choisir un rôle Global Repository Observer afin de ne pas avoir à ajouter de droits à chaque fois qu’on ajoute un nouveau repository réel dans le repository virtuel. Les identifiants et mots de passes sont à renseigner dans le fichier settings.xml :

<server>
<id>snapshots</id>
<username>thierry</username>
<password>xxxxxxx</password>
</server>
<server>
<id>internal</id>
<username>thierry</username>
<password>
xxxxxxx</password>
</server>
<server>
<id>project</id>
<username>thierry</username>
<password>
xxxxxxx</password>
</server>
</servers>

En plus de la centralisation des repository, archiva peut aussi servir de proxy.Nous allons rediriger toute les requêtes vers des repository externes (les différents plugin de maven vont être téléchargé par ce biais) vers archiva qui va alors les stocker pour les prochaines fois. Cela est extrêmement bénéfique quand un autre utiisateur (local à la machine ou dans l’intranet de l’entreprise) lance le même build. Pour cela il faut indiquer un repository virtuel comme miroir dans le fichier settings.xml

<mirror>
<id>archiva.mirror</id>
<url>http://localhost:9090/archiva/repository/mirror</url>
<mirrorOf>*,!project</mirrorOf>
</mirror>

Dans cette déclaration on dit que pour tous les repository autre que project (qui lui est définit dans le projet comme un repository archiva), maven va utiliser le repository archiva appelé mirror. Dans archiva il faudra créer le repository mirror comme repository virtuel (groupe) qui contiendra les repository standard de continuum : internal et snapshot.

Archiva mirror repository

Nous avons vu comment utiliser archiva pour centraliser l’administration des repository distant ainsi que pour mettre en cache les artefacts issus des repository distants pour les partager via archiva avec les autres builds.

Tags:
Back to top