Après quelques vacances, voici de retour les nouvelles sur Apache Maven et sa communauté. Comme vous allez le voir ci-dessous la période estivale 2008 aura été productive. De nombreuses livraisons (... comparativement à d'habitude), et surtout un gros effort pour répondre aux besoins des utilisateurs et pour offrir de jour en jour des livrables de meilleur qualité.
En gras les releases "majeures" (non alpha, beta, RC et autres versions pas encore considérées comme abouties).
En italique les annonces "périmées" par une annonce plus récente.
Sur la dynamique des livraisons il faut reconnaître qu'ils n'ont pas tout à fait tord ... tout du moins en apparence. Il est déjà arrivé de devoir attendre des mois, voir plus d'un an, pour obtenir la publication d'une nouvelle version d'un plugin.
Le problème est cependant plus la conséquence d'un manque de ressources et/ou de rigueur dans le processus de développement que d'un problème d'écoute. Tous ceux qui participent à ce projet en sont aussi les premiers utilisateurs. Nous faisons notre possible en fonction de nos moyens. Peu d'entre nous ont la possibilité de consacrer du temps professionnel en conséquence pour contribuer au projet dans son ensemble. Il faut donc avouer que, comme dans beaucoup d'autres projets en open-source, les bénévoles privilégient souvent leurs propres besoins (ou ceux de leurs clients) au détriment de ceux de la communauté. Cela n'est pas un manque d'écoute mais bel et bien un manque de temps.
Pour mieux répondre aux besoins des utilisateurs, nous les avons donc solicités à travers un vote pour nous aider à classer la priorité de publication des plugins. Suite à ce vote, les plugins les plus demandés ont été publiés. Aujourd'hui les plugins SCM, WAR, Enforcer sont disponibles.
Nous avons aussi automatisé en utilisant Swizzle le reporting sur les votes des issues qui se trouvent dans Jira. Nous sommes désormais capables de suivre le nombre de votes sur les issues ouvertes sur le noyau et sur les plugins. Pour nous aider à sélectionner les plugins pour lesquels une publication serait nécessaire nous avons aussi un rapport qui nous comptabilise les votes sur les issues fermées des plugins non publiés. Nous faisons donc notre possible pour produire le maximum de valeur pour les utilisateurs. N'hésitez pas à voter pour vos issues, cela sera pris en compte lors de nos choix.
Pour pallier au manque de ressources actives, nous avons peu de leviers. Il y a beaucoup de facteurs personnels ou professionnels qui influent sur la participation des développeurs. Pour les plugins hébergés chez Apache, il est difficile d'étendre l'équipe. Les règles d'admission sont assez strictes (un bien pour un mal) et demandent un investissement conséquent. Pour limiter ce problème nous limitons le nombre de plugins à maintenir chez Apache et nous laissons une marge de manoeuvre beaucoup plus forte au projet mojo.codehaus.org. Si une personne est volontaire pour participer au développement d'un plugin, nous la faisons rentrer dans cette communauté et nous l'aidons à y faire ces premiers pas. Est-ce risqué en terme de qualité des plugins délivrés par mojo.codehaus.org ? En fait non, car nous avons un espace d'incubation pour juger de la viabilité des nouveaux plugins. Concernant les développeurs, nous n'avons jamais eu à nous plaindre de la qualité livrée. Elle est peut-être perfectible mais souvent les participants essaient de livrer le meilleur d'eux-mêmes (chose qu'ils ne peuvent pas toujours faire dans leur quotidien du fait des délais exercés sur les projets).
En effet depuis plusieurs mois nous souffrions de l'instabilité du serveur nous hébergeant chez Apache (problème lié au serveur physique et non pas à continuum). De ce fait, notre intégration continue était régulièrement indisponible et ne nous offrait plus les services escomptés. En parallèle, nous avons complètement revu nos propres builds internes pour les standardiser encore plus (nommage des profils, etc) et séparer les tests d'intégration des tests unitaires dans les plugins (histoire qu'une fois de plus les cordonniers ne restent pas les plus mal chaussés).
Si vous êtes un projet dans une entreprise, privilégiez la mise en place d'un gestionnaire de repository qui vous offrira des services pour gérer un cache des artefacts externes et le stockage de vos propres livrables internes. Archiva en mode standalone ou Nexus se déploient en quelques minutes. Pas besoin de faire de la surconception. Par défaut, mettez en place deux repositories : un pour gérer le cache des releases externes, l'autre pour les snapshots. Ensuite quand le besoin vous vient de partager vos librairies entre plusieurs projets de l'entreprise, rajoutez un repository pour stocker vos releases internes et un autre pour vos snapshots. Configurez vos descripteurs de projets pour publier dessus. Enfin, vous mettrez souvent en place un cinquième repository pour les librairies tierces d'éditeurs propriétaires (drivers de base de données, librairies SUN protégées, ...). Pour éviter de demander à vos équipes de modifier leurs paramétrages à chaque modification de votre architecture sur ce serveur, utilisez la notion de groupe pour n'exposer qu'un repository virtuel pour les releases et un autre pour les snapshots (en plus cela améliorera grandement le temps de vos builds puisque maven ne cherchera à télécharger ces artefacts qu'à un seul endroit).
Au niveau du noyau Maven il y a eu beaucoup de suspense et de rebondissements. Petit résumé sur le feuilleton de l'été : "La valse des versions".
Pour revenir un peu en arrière sur maven 2.0.x, il faut remarquer que les différentes versions publiées à ce jour avaient des niveaux de qualité très variables (mais en nette amélioration depuis la 2.0.8). La fréquence des publications était aussi très irrégulière et certaines améliorations dépassaient largement le cadre d'une maintenance corrective :
Au début de l'été, toute l'équipe partait donc sur la publication d'une version 2.0.10. Le focus était une fois de plus sur la correction des régressions avec en particulier les problèmes de résolution de variables dans des cas assez complexes (fork de lifecycle par exemple). Nous avons repris le principe de la 2.0.9 en publiant des Releases Candidates pour validation par l'équipe et les utilisateurs. Nous avons référencé plusieurs builds complexes afin de les tester systématiquement avec les nouvelles RCs.
Il s'est avéré que la tâche fut plus compliquée qu'il n'y paraissait. Les corrections de bugs impactaient les performances, l'amélioration des performances créait des bugs. Les RCs s'enchainèrent pour trouver la stabilité requise à une nouvelle version. Parallèlement à cela, le besoin est revenu de publier une version 2.1 de Maven (le fameux saint graal depuis des années) afin qu'elle puisse être utilisée par les outils qui utilisent l'API Embedded de Maven (Le plugin m2eclipse par exemple). Après de longs débats, il fut admis que les evolutions prévues jusqu'alors pour la 2.1 étaient dantesques. Il était donc nécessaire de lisser ces évolutions dans des versions 2.X pour celles qui n'entraîneraient pas d'incompatibilités et dans des versions 3.X pour celles qui étaient plus importantes. L'équipe a donc planché sur l'écriture de Release Plans pour les versions 2.1.0 et 2.2.0. Les modifications entreprises sur la version 2.0.10 furent donc relayés dans une première milestone de la version 2.1. La 2.0.10 devrait voir le jour mais avec un nombre de correctifs plus restreint. La correction de la résolution des variables est trop importante pour un maintenance corrective.
Vous êtes perdus ? En résumé :