NMaven dans la software-factory .NET

| Peter C. DJOMGA  | (Centre de Développements Projets forfaits .NET, KOOSSERY TECHNOLOGY) | Baké Jc. BAKENEGHE  (Software Coordinator) |

Ce document traite de l'outil NMaven et s'adresse aux équipes intervenant dans des projets .NET: développeurs, chefs de projet, personnes en charge de l'intégration ou de l'assemblage.
Vos réactions par l'intermédiaire de ce fil: Commentez

- Titre : NMaven dans la software-factory .NET

- Auteurs : Peter C. DJOMGA , (Centre de Développements Projets forfaits .NET, KOOSSERY TECHNOLOGY), Baké Jc. BAKENEGHE  (Software Coordinator)

- Parution : 12 octobre 2009

- Mise à jour : 12 octobre 2009

- Licence :

Sommaire

- I. Introduction

- II. NMaven c'est quoi ?

- III. Avantages de la gestion du cycle de vie logiciel avec NMaven

- III-1. Convention, puis configuration

- III-2. Interfaces communes

- III-3. Centralisation de la définition du projet: pom.xml

- III-4. Meilleure gestion des dépendances

- III-5. Gestion robuste de la qualité du projet

- III-6. Meilleure gestion du cycle de vie d'un projet: gestion des releases, gestion des livraisons sur divers environnements

- IV. NMaven: concepts et commandes de base

- IV-1. Le cycle de vie du projet

- IV-2. Les repository

- IV-3. Organisation du repository

- IV-4. Commandes de bases

- IV-4-1. Création de la solution

- IV-4-2. Compilation de la solution

- IV-4-3. Exécution des tests

- IV-4-4. Installation dans votre Repo Local

- IV-4-5. Empaquetage

- IV-4-6. Déploiement dans le Repo de l'entreprise

- IV-4-7. Exécution de plusieurs phases

- V. Etapes de la mise en oeuvre de NMaven

- V-1. Pré-réquis

- V-1-1. Installation du JDK Java

- V-1-2. Installation de Maven

- V-2. Installation de NMaven et configuration du setting.xml

- V-2-1. Télécharger le code

- V-2-2. Configuration du fichier setting.xml

- V-2-3. Installation

- V-3. Gestion des ressources avec NMaven

- V-4. Configuration NMaven - Visual Studio

- V-5. Installation et configuration d'un repository interne à l'aide de Nexus

- V-5-1. Téléchargement de Nexus Open Source

- V-5-2. Installation d'un repository interne Nexus

- V-5-3. Configuration du repository interne Nexus

- V-5-4. Configurer NMaven pour utilisation de Nexus

- VI. NMaven en action

- VI-1. Cycle de vie d'un projet dans une software factory

- VI-1-1. Description d'un cycle de vie

- VI-1-2. Rôle de NMaven

- VII. Conclusion

I - Introduction

NMaven est un outil open source pour le build et la gestion des projets .NET. C'est une migration en .NET de Maven (qui est très populaire en Java).

Adopter NMaven procure d'énormes avantages et une aisance de gestion de projet similaires à ceux de Maven en Java tels que la mise en place de standards de développements, la réduction du temps d'écriture et de maintenance des scripts de build, une meilleure gestion des dépendances notamment les dépendances transitives, une automatisation de la gestion du cycle de vie d'un projet, etc.

Dans ce document nous allons tour à tour aborder:

- une présentation de NMaven

- les avantages de l'adoption de NMaven dans un projet .NET

- les concepts fondamentaux de NMaven

- l'installation et la mise en oeuvre de NMaven

- NMaven en action dans un projet .NET

II - NMaven c'est quoi ?

La définition qu'on peut donner à cet outil varie en fonction du poste qu'on occupe dans un projet .NET.

Pour un développeur NMaven est un outil qui permet de construire (build) des artefacts à partir d'un code source au même titre que Nant avec cependant des avantages indéniables pour NMaven (cf ). NMaven permet aussi au développeur de gérer de façon élégante les dépendances de son projet.

Pour des personnes en charge de l'intégration ou la gestion des projets, c'est un outil de gestion du cycle de vie du projet : construction des releases du projet, construction des paquets, gestion des livraisons sur différents environnements (DEV, INT, .., PROD), etc. En outre par l'intégration de divers plugins, il est possible de suivre la générer un certain nombre de rapports parmi lesquels le rapport d'exécution des tests unitaires, le rapport de couverture de code par les tests unitaires, etc.

Enfin afin de faciliter la communication du projet, NMaven permet de générer le site web du projet. Le site web du projet contient un certain nombre d'informations telles que la liste des développeurs du projet, les tutoriaux du projet, les kits starter à l'attention d'un nouveau développeur entrant dans le projet, les documentations utiles sur les différents modules du projet.

III - Avantages de la gestion du cycle de vie logiciel avec NMaven

Ce chapitre va nous permettre de voir les différents avantages que NMaven nous apporte. Il s'agit en réalité des mêmes avantages qu'apporte Maven dans le monde Java.

III-1 - Convention, puis configuration

Un des premiers avantages de NMaven est qu'il place au devant un certain nombre de conventions. C'est après cela que viennent les configurations, ce qui est tout le contraire de plusieurs outils (NANT notamment).

Ceci a l'avantage que:

- la convention étant connue de tous, la prise en main d'un nouveau code est plus aisée.

- la maintenance du code est plus facile, car les utilisateurs se sentent obligés d'utiliser les mêmes méthodes et les mêmes approches.

- avec un minimum de configuration (à la limite une configuration par défaut), vous pouvez réaliser un projet sans difficultés.

- cela évite aussi d'avoir à se perdre dans des configurations très complexes.

Selon la convention, l'organisation par défaut du code source est la suivante:

Figure 1 : organisation du code source avec NMaven

- src\main\csharp: répertoire où sont rangés les fichiers sources.
- src\main\resource: répertoire où sont rangées les ressources.
- src\main\config: répertoire où sont rangées les configurations.
- src\main\win32Icon: ou est rangé l'icône de l'application.

- src\test\csharp: source pour les tests.
- src\test\resource: les ressources pour les tests.
- src\main\config: répertoire où sont rangées les configurations.

Dit de cette façon cela est un peu trivial. Mais avec un outil comme Nant, il faut encore faire cette réflexion.

NMaven ne s'arrête pas là. Il définit un cycle de vie des projets et un ensemble de plugin par défaut qui savent comment compiler et assembler des types de projets. Il suffit juste de respecter les conventions pour n'avoir ni à faire, ni à réfléchir ou à définir aucune configuration que ce soit.

Il est à bien noter que ces conventions peuvent être customisées en fonction de vos besoins. Ceci passera par une configuration et/ou par un plugin que vous aurez écrit ou alors qui est disponible sur la toile.

III-2 - Interfaces communes

Pour chaque projet .NET non géré par NMaven, il faudra toujours prendre du temps pour comprendre l'organisation des fichiers et aussi quels sont les outils nécessaires pour réaliser les compilations et les assemblages.

Avec l'outil NMaven les choses sont différentes car il suffira à chaque utilisateur d'apprendre simplement les conventions de cet outil et il pourra du même coup comprendre et intégrer sans difficulté un projet géré par NMaven.

III-3 - Centralisation de la définition du projet: pom.xml

Toutes les informations principales que NMaven utilise pour builder le projet se trouvent centralisées dans un fichier pom.xml (fichier de configuration du projet).

Ce fichier contient la déclaration des dépendances du projet ainsi que les plugins particuliers que ce projet utilise. On y renseigne aussi la version du projet, la liste des développeurs etc.

III-4 - Meilleure gestion des dépendances

Lorsqu'on travaille avec Nant ou tout autre système de build, on est obligé de renseigner toutes les dépendances du projet. De plus très souvent le développeur est obligé d'embarquer toutes les .dll dans son projet.

Avec NMaven, plus besoin d'embarquer les dll dans son projet : en effet, les .dll sont stockées dans un repository et le projet les référence à partir de cet endroit.

Un autre avantage de taille est la gestion des dépendances transitives : en effet, avec tout autre outil, si le projet dépend de A et que A dépend à son tour de B et C, alors on est obligé de renseigner A, B et C au niveau des dépendances du projet. Avec NMaven on bénéficie de la gestion des dépendances transitives. C'est-à-dire que dans notre cas précédent eh bien on renseigne juste A comme dépendance et NMaven lui-même détectera automatiquement que A dépend de B et C et donc résoudra cette dépendance transitive automatiquement.

III-5 - Gestion robuste de la qualité du projet

Il est possible d'étendre les fonctionnalités de NMaven via l'intégration de divers plugins. On obtient alors des fonctionnalités de suivi de la qualité du projet via la génération des rapports suivants:

- rapport d'exécution des tests unitaires Nunit.

- rapport de couverture de code par les tests unitaires Nunit.

- rapport sur le respect des conventions de codage.

- rapport permettant d'analyser le code afin de trouver les problèmes potentiels tels que: le code mort, le code non optimal, les expressions trop compliqués.

- rapport indiquant si le code est bien documenté.

III-6 - Meilleure gestion du cycle de vie d'un projet: gestion des releases, gestion des livraisons sur divers environnements

NMaven en interagissant avec le système de contrôle de version de sources (SVN, CVS, etc.), permet une gestion efficace et automatique des release d'un projet. Les commandes intervenant dans le mode opératoire pour la gestion des release avec NMaven sont décrites dans la partie . NMaven permet aussi une gestion automatisée de la livraison des releases sur divers environnements (cf commandes décrites dans le )

IV - NMaven: concepts et commandes de base

IV-1 - Le cycle de vie du projet

Les cycles de vie des projets sont un concept central de NMaven. La plupart des développeurs sont familiers avec les notions de phases du build comme compile, test et deploy. NAnt a des cibles (targets) avec des noms semblables. Dans NMaven cette notion est standardisée dans un groupe de phases de cycle de vie bien définies (voir Figure 2). Dans NMaven le développeur lance l'action liée à une phase du cycle de vie.

Figure 2 : les phases du cycle de vie NMaven

Dans la figure 2 les principales phases du cycle de vie de NMaven sont:

- generate-sources: Génère le code source supplémentaire nécessité par l'application, ce qui est généralement accompli par les plugins appropriés.
- compile: Compile le code source du projet.
- test-compile: Compile les tests unitaires du projet.
- test: Exécute les tests unitaires (typiquement avec Nunit).
- integration-test: Réalise et déploie le package si nécessaire dans un environnement dans lequel les tests d'intégration peuvent être effectués.
- install: Installe les artefact (dll, etc.) dans l'entrepôt local. Ils pourront être utilisés comme dépendance des autres projets sur votre machine locale.
- deploy: Réalisé dans un environnement d'intégration ou de production, copie l'artefact final dans un entrepôt distant pour être partagé avec d'autres développeurs ou projets.

Ces phases illustrent le bénéfice des pratiques recommandées et encouragées par NMaven: une fois que le développeur est familiarisé avec les phases principales, il devrait se sentir à l'aise avec les phases du cycle de vie de n'importe quel projet .NET géré par NMaven.

Appeler une phase du cycle de vie appelle automatiquement les phases précédentes du cycle de vie. C'est à dire que si on invoque la phase install, alors les phases suivantes seront appelées dans l'ordre : generate-sources, compile, test-compile, test, integration-test, et enfin install

Comme les phases du cycle de vie sont en nombre limité, faciles à comprendre et bien organisées, se familiariser avec le cycle de vie d'un nouveau projet NMaven est très simple.

IV-2 - Les repository

Les repository sont des répertoires où sont stockées les différentes librairies (dll, etc) nécessaires ou produites lors des développements. Pour ce qui est de NMaven, il existe 3 repository qu'on peut utiliser:

- Repository Local : : il s'agit du repository qui se trouve sur le poste du développeur. Toute dépendance sera recherchée automatiquement dans ce repository.
- Repository Central ou distant : Lorsqu'un développeur réalise par exemple une compilation et que les dépendances nécessaires ne sont pas trouvées dans le repository local, NMaven va les chercher dans un repository distant qui aura au préalable été configuré (dans le fichier setting.xml). NMaven met le repository local à jour après avoir téléchargé les dépendances à partir du repository distant. Il faut noter que toute l'opération de téléchargement et d'installation des dépendances en question se fait automatiquement par NMaven.
- Repository Proxy : Dans le contexte d'une entreprise, il est nécessaire d'avoir en interne un repository proxy qui sert à faire les téléchargements une seule fois pour tous les développeurs. En effet en passant par le Repository Proxy, les téléchargements sur les Repository distants (téléchargements qui peuvent être très longs) sont faits seulement par ce dernier. Tout autre téléchargement de dépendance du Repository Local à partir du Repository Proxy est plus rapide car dans un Intranet.

Figure 3 : Mise en oeuvre d'un repository proxy

IV-3 - Organisation du repository

Ici nous devons bien comprendre comment est ce que NMaven range les artefact dans le repository. Chaque artefact a une adresse unique qui de la forme:

<groupId>.<artefactId>.<version>.[<classifier>]

Exemple:

<groupId>dotnet.nunit</groupId>
<artifactId>nunit.framework</artifactId>
<version>2.4.5.0</version>

Donne l'adresse : dotnet.nunit.nunit.framework.2.4.5.0

Au niveau du repository, voici ce que cela donne comme résultat (figure 4):

Figure 4 : Organisation du repository

En somme tout projet qui donne lieu à un artéfact doit avoir un GroupId, un ArtefactId et une version. Le Classifier étant optionnel.

IV-4 - Commandes de bases

Dans la gestion de projet on va partir de la création d'un projet jusqu'à son déploiement sur les plateformes de recettes en passant par les Build, les tests ou encore la génération de la documentation.

IV-4-1 - Création de la solution

Mvn archetype:create -DgroupId=com.koossery.tuto
-DartifactId=tutointro
-Dversion=1.0
-DarchetypeGroupId=org.apache.maven.dotnet.csharp
-DarchetypeArtifactId=maven-archetype-class-library

Dans l'exemple ci-dessus on créé un projet de type "library" (Ceci est précisé par l'option -DarchetypeArtifactId). Bien entendu on pourrait créer d'autre type de projet:

- Console: dans ce cas archetypeArtifactId = maven-archetype-console-application
- Winexe : dans ce cas archetypeArtifactId = maven-archetype-windows-application
- Controle : dans ce cas archetypeArtifactId = maven-archetype-windows-control

IV-4-2 - Compilation de la solution

mvn compile

IV-4-3 - Exécution des tests

mvn test

IV-4-4 - Installation dans votre Repo Local

mvn install

IV-4-5 - Empaquetage

mvn package

IV-4-6 - Déploiement dans le Repo de l'entreprise

mvn deploy

IV-4-7 - Exécution de plusieurs phases

mvn clean compile test

V - Etapes de la mise en oeuvre de NMaven

V-1 - Pré-réquis

Nmaven est par définition un ensemble de plugin de l'outil Maven. Cela impose donc une installation préalable de ce dernier.

V-1-1 - Installation du JDK Java

Vous pouvez trouver le JDK Java ici: http://java.sun.com/javase/downloads/index.jsp

V-1-2 - Installation de Maven

Vous pouvez télécharger Maven à partir du site de ce projet sur apache à l'adresse: http://maven.apache.org/download.html
NOTE: Nmaven ne marche qu'avec les versions 2.0.9 et ultérieure.

Vous aller donc télécharger une archive qui faudra décompresser à un endroit de votre disque (Exemple : G:\apache-maven-2.0.9). Le contenu de l'archive correspond au schéma ci-après.

Figure 5 : unzip de maven-2.0.9

La suite de l'installation consiste à mettre à jour les variables d'environnement de votre système comme suit:
Créer les variables M2_HOME, M2, M2_REPO qui pointe vers votre répertoire d'installation.

Figure 6 : variables M2_HOME, M2, M2_REPO

Ajouter à la variable PATH la valeur de M2. Ceci ce fait en ajoutant simplement à la fin de la valeur du PATH, la chaine " ;%M2% ".

JAVA_HOME = G:\Program Files\JAVA\jdk1.6.0_O1    // rep. d'installation JDK
M2_HOME = G:\apache-maven-2.0.9           // Répertoire d'installation
M2 = %M2_HOME%\bin          // Bin du répertoire d'installation
M2_REPO = D:\MAVEN-REPO      // répertoire de votre repo Local
Path = "ancien_valeur";%M2%

V-2 - Installation de NMaven et configuration du setting.xml

V-2-1 - Télécharger le code

Le code source de Nmaven est disponible sur un serveur SVN à l'adresse: https://svn.apache.org/repos/asf/incubator/nmaven/trunk
Le rapatriement peut se faire avec un client SVN comme "TortoiseSVN".
Pour plus de détails se rendre sur le site de Nmaven: http://nmaven.codeplex.com/

Figure 7 : téléchargement de NMaven

V-2-2 - Configuration du fichier setting.xml

Le fichier setting.xml se trouve dans le répertoire "conf" du lieu ou est installé Maven sur votre poste de travail (exemple : G:\apache-maven-2.0.9\conf). Ce fichier contient l'essentiel des configurations de base Maven : entre autre le lieu où se trouve le repository local, les repository proxy s'il y'en a, ainsi que les repository distants. Les configurations par défaut pointent sur le repository distant (Maven Central).
Pour un début nous allons simplement modifier le lieu où doit se trouver le repository local.

<localRepository>D:/maven-repo</localRepository>

V-2-3 - Installation

Nmaven est un projet avec la structure Maven. Son installation correspond simplement à une installation des artéfacts dans votre repository local:

- Lancer la console de commande.
- Se rendre au niveau du répertoire où est rapatrié le code de Nmaven.
- Taper la commande "mvn install".

V-3 - Gestion des ressources avec NMaven

NMaven dans sa version actuelle ne gère pas les ressources des projets. Koossery Technology a développé un plugin pour remédier à cela. Vous pouvez le télécharger sur le lien suivant: plugin NMaven pour la gestion des ressources dans le cycle de vie.
Les instructions d'installation se trouvent dans l'archive que vous aurez téléchargée.

La notion de ressource est un concept étendu dans le monde .NET. Il en existe à peu près quatre qui requièrent chacune une gestion spécifique lors de la phase de compilation. Le plugin développé redéfini certaines phases du cycle de vie en y insérant du code spécifique pour la gestion des ressources. Les phases redéfinies sont les suivantes:

- generate-sources: génère le code source supplémentaire nécessité par l'application, ce qui est généralement accompli par des plug-ins appropriés.

- compile: compile le code source du projet.

- test-compile: compile les tests unitaires du projet.

Pour installer le plugin il suffit de télécharger le plugin, de lancer la fenêtre de commandes cmd, de vous placer dans le répertoire racine du plugin et d'exécuter la commande:

mvn install

Comment utiliser le plugin ?

Considérons un projet P contenant plusieurs modules m1, m2, m3, etc. Dans le pom parent on configure le plugin au niveau de la section pluginManagement c'est à dire :

<pluginManagement>
<plugins>
<plugin>
<groupId>com.koossery.maven.dotnet.plugins</groupId>
<artifactId>maven-koossery-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<resources>
<resource>
<directory>${project.basedir}/src/main/resources/resource</directory>
<includes>
<include>**/**.xml</include>
</includes>
<namespace>src.main.resources.resource</namespace>
<type>resource</type>
</resource>
<resource>
<directory>${project.basedir}/src/main/csharp</directory>
<includes>
<include>**/**.resx</include>
</includes>
<namespace>src.main.csharp</namespace>
<type>resource</type>
</resource>
<resource>
<directory>${project.basedir}/src/main/resources/linkresource</directory>
<includes>
<include>**/**.xml</include>
<include>**/**.config</include>
</includes>
<namespace>src.main.resources.linkresource</namespace>
<type>linkresource</type>
</resource>
<resource>
<directory>${project.basedir}/src/main/resources/win32Icon</directory>
<includes>
<include>Icon1.ico</include>
</includes>
<namespace>src.main.resources.win32Icon</namespace>
<type>win32Icon</type>
</resource>
</resources>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.dotnet.plugins</groupId>
<artifactId>maven-dotnet-test-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<resources>
<resource>
<directory>${project.basedir}/src/main/resources/linkresource</directory>
<includes>
<include>**/**.xml</include>
<include>**/**.config</include>
</includes>
<namespace>src.main.resources.linkresource</namespace>
<type>linkresource</type>
</resource>
</resources>
</configuration>
</plugin>
</plugins>
</pluginManagement>

Dans la configuration ci-dessus toutes les ressources du projet doivent être explicitement définies dans la sous-section configuration du plugin utilisé. Pour chaque ressource on renseigne son type, le répertoire où la trouver, les fichiers à inclure via leur extension; on peut aussi explicitement indiquer les fichiers ressources à exclure.

Dans les pom des modules on signale juste le plugin sachant qu'il va alors hériter des configurations faites au niveau du pom parent.

<sourceDirectory>.</sourceDirectory>
<testSourceDirectory>./src/test/csharp</testSourceDirectory>

<resources>
<resource>
<directory>src/test/resources</directory>
<includes>
<include>**/**.xml</include>
</includes>
</resource>
<resource>
<directory>src/main/resources</directory>
<includes>
<include>**/**.*</include>
</includes>
</resource>
</resources>
<plugins>
<plugin>
<groupId>com.koossery.maven.dotnet.plugins</groupId>
<artifactId>maven-koossery-plugin</artifactId>
<extensions>true</extensions>
</plugin>
<plugin>
<groupId>org.apache.maven.dotnet.plugins</groupId>
<artifactId>maven-dotnet-test-plugin</artifactId>
<extensions>true</extensions>
</plugin>
</plugins>

V-4 - Configuration NMaven - Visual Studio

Pour des besoins de convivialité pour les développements, il est nécessaire d'avoir l'essentiel des outils de développement dans son IDE. Koossery Technology est entrain de développer un Addin Visual Studio pour réaliser l'essentiel des taches NMaven à partir de notre IDE VStd.
Cet Addin sera mis à disposition prochainement.

V-5 - Installation et configuration d'un repository interne à l'aide de Nexus

La documentation de référence de Nexus se trouve à l'adresse: http://www.sonatype.com/books/nexus-book/reference/.

V-5-1 - Téléchargement de Nexus Open Source

Nexus existe en deux versions:

- Nexus Open Source: http://nexus.sonatype.org/using/download.html
- Nexus Profesionnal: http://www.sonatype.com/products/downloads

V-5-2 - Installation d'un repository interne Nexus

- Décompresser l'archive téléchargée dans un répertoire de votre choix.
- Se rendre dans le répertoire "xxx\yyy\nexus-webapp-1.0.1\bin\jsw\windows-x86-32"
- Lancer le fichier "installNexus.bat"
- Puis lancer (si nexus n'est pas encore lancé) le fichier "StartNexus.bat"

Figure 8 : téléchargement de Nexus

V-5-3 - Configuration du repository interne Nexus

Vérifier par la suite si l'installation s'est bien passée en se connectant à cette application via l'explorateur Web avec l'adresse: "http://localhost:8080/nexus" ou plus précisement "http://nom_du_serveur:port/nexus".

Figure 9 : page d'accueil de Nexus

La suite porte alors sur les configurations des repository distants où le serveur Nexus ira faire les recherches d'artefacts s'il ne les trouve pas à son niveau.

Les configurations par défaut de Nexus sont dans l'ensemble suffisantes pour une utilisation basique (simple repository proxy). Cependant pour d'autres configurations (comme la création d'un repository pour les artéfacts que vous aurez vous-même produits), lire http://www.sonatype.com/books/nexus-book/reference/config.html.

Il faut noter que Nexus se comporte comme une agrégation de Repository c'est-à-dire qu'au niveau de Nexus on peut définir plusieurs repository en fonction des besoins. Par exemple onpourrait configurer unrepository pour les snapshots, un pour les releases,etc.

Nexus propose par la suite la notion de "Repository Groups". Il s'agit d'une sorte de porte d'entrée unique pour réaliser les recherches sur un ensemble de repository; c'est-à-dire qu'au lieu de définir plusieurs repository dans mon fichier settings, je vais plutôt pointer vers le " repository group " et ensuite aller définir sur Nexus ce "repository groups" qui contiendra tous les repository que je suis supposé utiliser.

Dans la figure ci-dessous vous avez la définition d'un "repository groups" (Public Repositories) qui regroupe par défaut l'ensemble des repository public que les projets utilisent par défaut.

Figure 10 : exemple de repository group avec Nexus

V-5-4 - Configurer NMaven pour utilisation de Nexus

La configuration de NMaven pour une utilisation de Nexus se fait au niveau du fichier "settings.xml". Voici un exemple de configuration du fichier settings.xml

<settings>
<localRepository>D:/maven-repo</localRepository>

<servers>
<server>
<id>releases</id>
<username>koossery</username>
<password>#tochange00</password>
</server>
</servers>
<pluginGroups>
<pluginGroup>org.apache.maven.dotnet.koossery.plugins</pluginGroup>
</pluginGroups>

<mirrors>
<mirror>
<!--This is used to direct the public snapshots repo in the -->
<!--profile below over to a different nexus group -->
<id>nexus-public-snapshots</id>
<mirrorOf>*snapshots*</mirrorOf>
<url>http://192.168.100.30:8081/nexus/content/groups/public-snapshots</url>
</mirror>
<mirror>
<!--This sends everything else to /public -->
<id>nexus</id>
<mirrorOf>!*snapshots*</mirrorOf>
<url>http://192.168.100.30:8081/nexus/content/groups/public</url>
</mirror>
</mirrors>

<profiles>
<profile>
<id>development</id>
<repositories>
<repository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>false</enabled></snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
<profile>
<!--this profile will allow snapshots to be searched when activated-->
<id>public-snapshots</id>
<repositories>
<repository>
<id>public-snapshots</id>
<url>http://public-snapshots</url>
<releases><enabled>false</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>public-snapshots</id>
<url>http://public-snapshots</url>
<releases><enabled>false</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>public-snapshots</activeProfile>
<activeProfile>development</activeProfile>
</activeProfiles>
</settings>

Dans cet exemple nous avons principalement 4 sections qui nous intéressent:

- Servers: dans cette section on définit le compte et mot de passe pour accéder à un repository précis de Nexus. Dans cet exemple nous avons défini un compte (koossery) et un mot de passe (#tochange00) pour le repository dont l'id est "releases".

- Mirrors: dans cette section on définit les miroirs. Ils permettent de donner l'url (élément Url) vers laquelle maven ira chercher un artéfact en fonction de son nom (expression régulière définie au niveau de mirrorOf). Notez ici que les adresses sont ceux du "repository group" pour la plupart des cas.

- Profile : C'est ici qu'on définit les profils avec pour chaque profil l'ensemble des repositories dans lesquels maven ira chercher les artefacts. Il y'a utilisation implicite des miroirs pour déterminer les adresses des repositories.

- ActiveProfiles : c'est ici qu'on décide quels profils sont actifs et lesquels ne le sont pas.

VI - NMaven en action

VI-1 - Cycle de vie d'un projet dans une software factory

VI-1-1 - Description d'un cycle de vie

Figure 11 : cycle de vie d'un projet

Vous avez ci-dessus un schéma représentant un cycle de vie d'un projet dans une software factory. On par ici de l'analyse, conception puis implémentation. L'implémentation se fait au niveau des postes de développeur. Ces derniers réalisent successivement des compilations et tests unitaires des différents modules qui leur sont confiés.

Apres cela ils vont ranger leur code dans un serveur de gestion des versions (exemple : SVN). Il s'en suit une intégration des différents codes (soit par un intégrateur, soit par un serveur d'intégration continue comme CruiseControl). L'intégration permettra de:

- compiler la solution dans son ensemble.

- lancer les tests unitaires de toute la solution.

- évaluer de la couverture de test du code (NCover, PartCover).

- générer la documentation du code et du projet.

- empaqueter les différents artéfacts.

- déployer ces différents artéfacts vers le serveur d'artéfacts (qui ici est Nexus) pour un partage de ces derniers entre les différents membres de l'équipe.

VI-1-2 - Rôle de NMaven

Comme le montre la figure 11 du , NMaven peut intervenir à plusieurs niveaux du cycle de vie et rendre les choses encore plus simple pour les équipes de développement.

Pour le développeur les opérations de compilation, test et paquetage sont prise en compte dans le cycle de vie de NMaven principalement avec les phases "compile, test, install, package".

Pour ce qui est de l'intégration (continue ou pas), les opérations de compilation, test, génération du code du projet, empaquetage et déploiement sont pris en compte dans le cycle de vie de NMaven principalement avec les phases "compile, test, install, package, deploy, site". Cependant toute autre tâche comme la couverture de code peut être intégrée à NMaven via les Plugins.

VII - Conclusion

NMaven a des avantages indéniables pour les équipes de développement:

- Gestion élégante des dépendances des projets.

- Standardisation de l'organisation des projets et donc une meilleur maintenabilité.

- Pour des projets communautaires, la prise en main et l'installation des codes sources deviennent plus simple.

- Cycle de vie standard de projet couvert.

- Meilleur partage des artéfacts avec les repository qui peuvent communiquer.

Il sera proposé ultérieurement un ensemble d'articles techniques sur les plugins réalisés par Koossery Technology pour un enrichissement des fonctionnalités et possibilités de NMaven.

Koossery Technology est une entreprise spécialisée dans les développements de projets au forfait (.NET & Java J2ee) et dispose pour cela d'une cellule Architecture Technique et Outillages ainsi que d'une Usine Logicielle.

Koossery Technology dispose aussi d'un Centre de Service GED-ECM-BPM Alfresco, jBPM pour adresser les projets GED-ECM-BPM sur la base des plate-formes Alfresco et jBoss BPM.

Vos réactions par l'intermédiaire de ce fil: Commentez