Libellés

Affichage des articles dont le libellé est maven. Afficher tous les articles
Affichage des articles dont le libellé est maven. Afficher tous les articles

mardi 5 juillet 2011

Maven : créer un projet multi-module

Maven, le très célèbre outil de build et gestionnaire de dépendances nous offre quelques possibilités bien sympatique.

Vous connaissez sûrement les projets multi-modules, qui permettent de découper un projet pour plus de modularité.

Par exemple vous construisez un projet P. Ce projet est constitué de plusieurs sous-projet A, B, C ayant comme dépendances respectives :

P :
  - A (A1, O)
  - B (O)
  - C (C1, A)

Comme vous le voyez, C dépend de A, mais pas de B. De plus la dépendance O est partagée entre plusieurs sous-projet.

Maven va bous permettre de gérer ses trois sous projet en réduisant le nombre de lignes de code copiées collées.



Voici le pom de P, le projet coordinateur :

<project ....>

    <groupId>org.groupId</groupId>
    <artifactId>P</artifactId>
    <packaging>pom</packaging>
    <version>1.0.0</version>
    <modelVersion>4.0.0</modelVersion>
    
    <modules>
        <module>A</module>
        <module>B</module>
        <module>C</module>
    </modules>
</project>


Il faut remarquer deux choses :
 
  - le packaging == pom, qui nous dit que ce projet n'aura pas de code source
  - la section modules qui représente notre structure.


Ensuite à la racine de ce projet, nous allons créer les 3 sous projets : A, B, C

/my-project
|--pom.xml
|--A
|  `--pom.xml
|--B
|  `--pom.xml
`--C
   `--pom.xml     



Voici le pom du sous-projet A  :

<project ...>
    <parent>
        <artifactId>P</artifactId>
        <groupId>org.groupId</groupId>
        <version>1.0.0</version>
    </parent>
    
    <modelVersion>4.0.0</modelVersion>
    <artifactId>A</artifactId>
    
....


Dans la balise parent, on défini la dépendance vers notre projet parent P.

Nous remarquons que pour A, il n'y a pas de balise groupId ni de balise version à définir A.
En effet, ces valeurs sont héritées du pom parent, pratique !!!!



Maintenant prenons le cas où certains sous-projets aient des dépendances en commun. A et B dépendent de O.

On pourrait tout a fait déclarer dans A et dans B les dépendances complètes (avec la version) :
<dependencies>
    <dependency>
        <groupId>com.aProject</groupId>
        <artifactId>O</artifactId>
        <version>5.6.7</version>
    </dependency>
</dependencies>


Mais le jours, on l'on changera la version de O ( 5.6.7 ---> 5.6.8 ) dans A, on oubliera sûrement de changer la version de O dans B, et l'on se retrouvera avec un pom dégelasse avec plein de dépendances différentes.

La solution consiste donc à ne pas déclarer les versions dans les poms des sous-projets, mais dans le pom parent.


Je vous donne un exemple :

<project ....>

    <groupId>org.groupId</groupId>
    <artifactId>P</artifactId>
    <packaging>pom</packaging>
    <version>1.0.0</version>
    <modelVersion>4.0.0</modelVersion>
    
    <modules>
        <module>A</module>
        <module>B</module>
        <module>C</module>
    </modules>
    
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>commons-io</groupId>
                <artifactId>commons-io</artifactId>
                <version>2.0.1</version>
            </dependency>
            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
                <version>4.8.2</version>
            </dependency>
        </dependencies>
    </dependencyManagement>
</project>




Dans le pom d'un sous-projet, la section de dépendance ressemblera à :
<dependencies>
    <dependency>
        <groupId>commons-io</groupId>
        <artifactId>commons-io</artifactId>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

Cool, on a supprimé la version !!!!



Maintenant voyons le cas où C dépend de A, c'est à dire étudions les dépendances entre sous-projets.

Voici la section de dépendance de C :
<dependencies>
    ....
    <dependency>
        <groupId>${parent.groupId}</groupId>
        <artifactId>A</artifactId>
        <version>${parent.version}</version>
    </dependency>
    ....
</dependencies>


On est obligé de spécifier la version, mais regardez bien, nous faisons référence à une variable interne : ${parent.version}, de même pour la balise groupId. Zéro problème pour maintenir ce pom !!!


Et maintenant nous pourrions avoir envie de créer nos propres variables dans le pom parent et d'utiliser n'importe où.
Aussitôt dit, aussitôt fait. Editez votre pom parent et ajoutez la section :
<properties>
    <foo.bar>FooBarValue</foo.bar>
</properties>

Maintenant on peut utiliser cette valeur de partout ce cette façon : ${foo.bar}

Il y a bien sur une limite, la section parent ne peut être défini à partir de variable défini dans le pom parent. Sinon ce n'est pas évident pour deviner qui est le parent quand on lit le pom d'un sous-projet.

lundi 14 février 2011

Rechercher dans Maven Central

Nous avons souvent besoin de rechercher des dépendances pour les inclure dans nos projets maven.

Le problème c'est que maven central est un peu gros. Sonaytype nous dis en 2010 :
"the Central Maven repository contains almost 90000 software artifacts occupying around 70 GB of disk"

Pour trouver nos petits, soit on navigue à la main dans l'arborescence de maven central :
http://repo1.maven.org/maven2/
http://repo2.maven.org/maven2/

Soit on utilise des outils de recherche. J'en connais deux :
  - http://mavencentral.sonatype.com/ : Qui utilise l'indexer maven, open sourcé par sonatype (Cf : http://www.sonatype.com/people/2011/02/maven-indexer-sonatypes-donation-to-repository-search/)

  - http://mvnrepository.com


Je trouve http://mavencentral.sonatype.com/ intéressant car il nous montre si les sources et la javadoc sont téléchargeable via maven.

Quand à http://mvnrepository.com, c'est celui que j'utilise depuis toujours :). Il est bien, mais il génère beaucoup plus de résultats parasites. Par contre il permet une navigation via les dépendances et via les usages.

lundi 3 janvier 2011

Un repository maven gratuit avec github

GitHub permet de créer des repository maven très facilement, ce qui peut être très pratique pour réutiliser ses propres projets perso.

La technique pour créer un repository maven consiste à :


Créer un nouveau projet github, qui ne sera utilisé que pour le repo maven


Si vous n'avez jamais utiliser github je vous conseille de suivre le guide officiel : 
http://help.github.com/


Dans ce repository créer les dossiers snapshots et releases
mkdir snapshots
mkdir releases
Inclure dans le pom.xml la section distributionManagement
Modifier le pom.xml du prijet que l'on souhaite distribuer via le repository maven.

    <distributionManagement>
        <repository>
            <id>repo</id>
            <url>https://Filirom1@github.com/Filirom1/filirom1-mvn-repo.git/raw/master/releases</url>
        </repository>
        <snapshotRepository>
            <id>snapshot-repo</id>
            <url>https://Filirom1@github.com/Filirom1/filirom1-mvn-repo.git/raw/master/snapshots</url>
        </snapshotRepository>
    </distributionManagement>

Faire un deploy
Déployer ce projet dans le repository maven
mvn -DaltDeploymentRepository=repo::default::file:../filirom1-mvn-repo/releases clean install source:jar javadoc:jar deploy   

Attention il faut utiliser le chemin relatif. ~/filirom1-mvn-repo/releases ne fonctionne pas.



Utiliser le repository
Voici un exemple :

<dependencies>
    ....
    <dependency>
        <groupId>org.html2har</groupId>
        <artifactId>html2har</artifactId>
        <version>1.0.0</version>
    </dependency>
    ....
</dependencies>

<repositories>
    <repository>
        <id>filirom1-repo</id>
        <url>https://Filirom1@github.com/Filirom1/filirom1-mvn-repo/raw/master/releases</url>
    </repository>
</repositories>

https://github.com/Filirom1/browsermob-page-perf/blob/master/README.md