Maven nuiton pom
2009-08-22

Présentation

Le projet mavenpom est un pom de type Corporate dont héritent tous les projets code Lutin.

Depuis la version 3.3, le changelog se trouve ici.

Il ne sera plus maintenu sur cette page.

Nouveautés de la version 3.4.2

Utilisation des apiKey de redmine plutôt que login/passsword

Depuis la version 3.4.2, on utilise pour se connecter sur le serveur redmine de l'apiKey plutôt que des login/password.

Pour ce faire il faut ajouter dans votre settings.xml une balise

  <privateKey>{Votre api key encodée}</privateKey>

dans chacun des serveurs de login redmine, à savoir donc :

  • redmine-nuiton.org
  • redmine-chorem.org
  • redmine-forge.codelutin.com

Vous trouverez votre apiKey (pour chaque forge) dans la page de votre compte.

Nouveautés de la version 3.1

Changement du maven-helper-plugin

Depuis la version 1.4, maven-helper-plugin devien helper-maven-plugin (tout du moins son GAV). Le site du projet reste bien (pour le moment) http://maven-site.nuiton.org/maven-helper-plugin.

Nouveautés de la version 3.0.3

Correction des déployements de site

La version 3.0.3 corrige les problèmes suite au passage sur le maven-site-plugin 3.0.

L'héritage des définitions de site ne fonctionne plus, on ne peut donc plus gérer cela au niveau de mavenpom et ses fils.

Il faut donc dans chaque projet client ajouter ceci :

  <distributionManagement>
    <site>
      <id>${platform}</id>
      <url>${our.site.repository}/${projectId}</url>
    </site>
  </distributionManagement>

Les variables *site.repository* et *site.server* ne sont donc plus utiliséees et sont supprimées sauf pour les projets héritants du mavenpom4labs.

Déployements via nexus (plutôt que par ssh)

On utilise désormais le déployement en http via nexus.

Il faut donc avoir un nouveau server dans son settings.xml

    <!-- nexus deployment user -->
    <server>
      <id>nuiton-nexus-deploy</id>
      <username>deployment</username>
      <password>{le mot de passe qui va bien :)}</password>
    </server>

Nouveautés de la version 3.0

La version 3.0 survient avec une nouvelle forge http://forge.codelutin.com

Cette forge est basée sur redmine et cela a nécessité du coup de revoir légèrement l'utilisation de la variable platform et des serveurs dans le settings.xml.

Modification du settings.xml

Il faut donc ajouter les serveurs suivants (dans le settings.xml) :

    <!-- depot site maven sur nuiton.org -->
    <server>
      <id>nuiton.org</id>
      <username>publish</username>
      <filePermissions>664</filePermissions>
      <directoryPermissions>775</directoryPermissions>
    </server>


    <!-- depot maven + site maven sur chorem.org -->
    <server>
      <id>chorem.org</id>
      <username>publish</username>
      <filePermissions>664</filePermissions>
      <directoryPermissions>775</directoryPermissions>
    </server>

    <!-- depot maven + site maven sur forge.codelutin.com -->
    <server>
      <id>forge.codelutin.com</id>
      <username>publish</username>
      <filePermissions>664</filePermissions>
      <directoryPermissions>775</directoryPermissions>
    </server>

    <!-- depot maven + site maven sur le labs -->
    <server>
      <id>labs.libre-entreprise.org</id>
      <username>votre login sur le labs</username>
      <filePermissions>664</filePermissions>
      <directoryPermissions>775</directoryPermissions>
    </server>

    <!-- login to forge.codelutin.com -->
    <server>
      <id>redmine-forge.codelutin.com</id>
      <username>votre login sur le redmine forge.codelutin.com </username>
      <password>{votre password encodé sur forge.codelutin.com}</password>
    </server>

Migration des projets

En théorie, rien à faire tout reste compatible sauf pour les projets utilisant mavenpom4labs.

Il faut désormais rajouter la section de définition du server de site car cela ne fonctionne plus très bien depuis le passage sur le maven-site-plugin 3.

Nouveautés de la version 2.5

Depuis la version 2.5, chaque librairie ou plugin utilisé dans le mavenpom ou un de ses fils est configurable via une propriété, il s'agit d'une généralisation de ce qui était déjà fait sur nos propres plugins et les librairies.

Cela permet de pouvoir dans un projet utilisant un des mavenpom de pouvoir changer les versions de librairies ou plugins sans avoir à redéfinir les dépendances.

Mise à jour plugins

Nouveautés de la version 2.4

Depuis la version 2.4, on introduit on gère les librairies les plus souvent utilisées dans nos projets et ceci pour éviter de repasser dans les poms : c'est plus facile de changer de mavenpom que de changer les versions dans chaque projet.

Voir la page des propriétés pour connaitre toutes les librairies connues au niveau du mavenpom.

On a aussi renommer toutes les propriétés de versin en utilisant le camelStyle pour faire comme les petits copains de chez Maven. Par exemple maven.version devient mavenVersion.

On a ajouté un profile analyze-dependencies qui est automatiquement déclanché lors d'une release pour vérifier la consistance des dépendances d'un projet.

Pour le reste, c'est ici.

Nouveautés de la version 2.3

Depuis la version 2.3, un nouveau type de pom nommé du mavenpom4redmineAndCentral pour tous les projets déployés sur redmine et synchronisés sur Maven central.

Il hérite du mavenpom4redmine et rajoute la configuration pour que cela soit déployé sur maven central.

Pour plus d'informations, voir la page de de mavenpom4redmineAndCentral.

Nouveautés de la version 2.2.2

Simplification des noms de dépôts

On a supprimé nuiton- de tous les noms de dépôts de release

Configuration central-safe améliorée

La configuration central-safe a été améliorée, il s'agit désormais d'un profile central-safe qui n'est pas activé lors d'une release.

Les projets central-safe modifie la configuration du plugin release pour inclure explicitement ce profile et en prepare et en perform.

Mise à jour plugins

Nouveautés de la version 2.2.1

Depuis la version 2.2.1 on utilise maven-license-plugin 2.3.

Cela permet d'améliorer la qualité des fichiers THIRD-PARTY générés (dépendances sans license, licenses dupliquées,...).

On a aussi dans cette version de mavenpom ajouté une configuration pour permettre en phase de préparation de release (release:prepare) d'activer les profiles de releases afin de pouvoir détecter d'éventuelles problèmes avant le tag svn.

Nouveautés de la version 2.2

Depuis la version 2.2 on a amélioré la configuration des serveurs de déployement et introduit la notion de projet central-safe.

Un tel projet répond aux pré-requis d'un projet synchronisable sur central :

  • avoir un pom de bonne qualité (informations scm, url, license, ...)
  • être auto-conteneur (pas besoin d'autre dépôts que central)
  • être signé via gpg
  • javadoc et sources disponibles

Pour plus d'informations, voir la page de configuration des serveurs.

Les propriétés

Voir la page des propriétés.

Les profiles

Mavenpom définit un certain nombre de profiles. Certains sont dédiés exclusivement à la préparation de releases, tandis que d'autres permettent de réaliser certaines tâches pendant le développement (mise à jour des entêtes des fichiers sources par exemple).

La page des profiles décrit l'ensemble des profiles.

Vérification de conformité

On effectue sur le pom des contrôles de conformités via le plugin maven-enforcer-plugin.

propriétés obligatoires

Aucune à l'heure actuelle

Fichiers obligatoires

README.txt
changelog.txt
LICENSE.txt

Configuration des plugins

Mavenpom fixe les versions d'un certain nombre de plugins et ceci pour plusieurs raisons :

  • la reproductibilité : en effet, si on ne fixe pas les versions des plugins on s'expose d'un build à l'autre à ne pas utiliser la même version des plugins, et donc dans le temps on ne peut pas garantir que le build d'un projet sera exactement le même. Ceci est une préconisation de maven.
  • l'uniformisation : le fait de fixer le plus grand nombre de versions de plugin permet aussi de faire profiter à tous les projets héritant de mavenpom d'une certaine stabilité et de faire profiter à tous des dernières versions des plugins testées.
  • un dernier point intéressant est le fait que si on utilise correctement mavenpom, on ne doit pas à avoir à gérer les versions des plugins hormis les exceptions citées dans la section suivante.

Les plugins configurés dans mavenpom

On distingue deux types de plugins :

  • les plugins internes que nous produisont (et donc qui dépendent de mavenpom).
  • les plugins externes (ceux d'apache, codehaus, plexus,...) qui ne dépendent pas de mavenpom

Plugins internes

Nos plugins ne doivent pas être décrit dans mavenpom et ceci pour la simple raison que nos propres plugins utilisent mavenpom, 3 exceptions existent cependant :

  • maven-helper-plugin : il est utilisé pour construire les releases
  • maven-jredmine-plugin : aussi utilisé pour construire les releases
  • maven-license-plugin : utilisé dans les profiles de mises à jour des entêtes de licenses.

Tous nos autres plugins ne sont pas référencés ici et doivent donc être entièrement définies (version + configuration) dans vos pom.

Plugin externes

Pour tout plugin dit externe, il peut être référencé dans mavenpom.

Bonnes pratiques sur l'utilisant d'un plugin externe dans votre pom

Avant de vouloir utiliser un nouveau plugin dans votre pom, consulter en premier la page des plugins connus par mavenpom.

Si le plugin est connu, alors pas de question à se poser, on peut l'utiliser sans spécifier sa version utilisant celle définit dans mavenpom.

Si le plugin n'existe pas, faites une demande d'évolution sur le projet mavenpom, il sera rapidemment ajouté et vous pourrez l'utiliser en vous plaçant sur la dernière snapshot de mavenpom.