Après 9 beta la version 2.0 du plugin release est enfin disponible. Les derniers coups de tournevis apportés à ce dernier devraient en ravir plus d’un !!

• Le plug-in supporte désormais les projets en structure “flat” ou aussi nommée “en râteau”. Pour ces projets ( pour diverses bonnes ou moins bonnes raisons ) le POM parent n’est pas en même temps le réacteur des sous modules. Le parent est un sous-module à part entière. Jusqu’à présent le plug-in release ne fonctionnait pas sur ce type de projet. C’est enfin une chose corrigée.
• Les bugs les plus récalcitrants du goal branch sont corrigés. Vous pouvez utiliser ce dernier par exemple pour créer une branche depuis le trunk avant de faire la release pour passer sur une branche dite de stabilisation. Ou alors vous pouvez créer la branche depuis un tag pour créer une branche de maintenance de la version en question. Dans tous les cas le plugin prend en charge la modification des versions dans les POMs, chose que l’on sait bien ennuyeuse (et dangereuse) à faire à la main.
• Le plug-in release contrôle à nouveau correctement les modifications locales (fichiers modifiés ou ajoutés et non commités) avant de démarrer le processus de release ou de création d’une branche. Cette fonctionnalité était buggée depuis la version 2.0-beta-8 (cf. MRELEASE-481).
• Enfin, je pense qu’il s’agit de la correction la plus attendue de tous : Il n’est plus nécessaire pendant la phase de préparation d’installer les artifacts du projet dans le repository local. A l’origine, lié à un problème dans le noyau de Maven, Il était très souvent nécessaire de configurer le goal prepare du plugin pour faire une installation des artifacts plutot qu’une vérification sans quoi la release échouait faute de trouver les dépendances entre modules. Cela avait les désavantages de couter du temps (le packaging de gros artifacts comme des WARs ou EARs prend beaucoup de temps au niveau du build à cause de l’utilisation intensive des IOs de la machine) et surtout de pouvoir produire lors de cette phase qu’une partie des binaires de la version en cours de release si cette dernière echouait. C’est pour cela que la phase prepare ne doit faire qu’exécuter les tests sans créer les binaires et si tout se passe bien c’est la phase perform qui générera ces derniers. Ceci est désormais rentré dans le bon ordre et suit l’idée d’origine du plugin (la fameuse raison des deux phases).

La documentation du plugin est à jour. Vous pouvez retrouver le détail des modifications dans la Release Note de cette version.

Bonne release à tous !!

Question aux produits concurrents : Vous faites comment pour offrir ce service à vos utilisateurs ?