new Blog( perso );

Après quelques jours de débats plus ou moins houleux, quelques uns ont tenté de désamorce le conflit, pour permettre l'inclusion de Spice et Aether dans Maven 3.

Petit rappel : Spice permet à Maven3 (comme Nexus) d'exploiter Google Guice à la place de Plexus, sans modification des API (c'est donc une couche Adapter). Aether quand à lui est un redéveloppement de la gestion des Artefacts, des dépendances transitives et du repository - autrement dit le remplaçant du mort-né Mercury qui remplaçait lui-même un code historique dont tout le monde s'accorde pour dire qu'il était un boulet pour Maven.

Sauf que, en dehors de la forme employée par Sonatype et en particulier son patron Jason Van Zyl pour imposer cette évolution, les tentatives de conciliations se sont globalement heurtées à un mur.  La proposition plutôt équilibrée d'Arnaud de sortir une beta 2 avec le code actuel, suivie d'une beta 3 incluant Spice et Aether, ce qui permettrait de tester avec et sans Aether et de valider rapidement une éventuelle régression (et il y en a), a été rejetée d'un trait, comme de nombreuses autres
- "c'est ça ou merde" (j'exagère à peine le ton).


Le soucis, c'est que Aether reprend un pan entier des fonctionnalités supportées par Maven. Celui-ci deviendrait une coquille demi-vide qui exécute juste des plugins dans l'ordre. Ralph Goers ne s'y est pas trompé et menace de voter "-1", ce qui en langage Apache veut dire "toi même". Cas historique à ma connaissance. Son autre option serait de forker de force le code d'Aether dans le SVN Apache (ce qu'autorise la licence), pas vraiment mieux. Ralph accuser clairement Sonatype de vouloir s'approprier le projet Maven, ce qui - je l'ai déjà dit - ne me choquerais pas nécessairement, mais à condition de le faire ouvertement et pas par des tours de passe-passe de ce genre.

Hors sujet, mais notez le nombre de lois impopulaires qui sont votées en plein été, pendant que personne n'est là pour gueuler. Coïncidence ou stratégie ? 

De nombreux membres historiques du projet, réveillés par ce débat, se sentent dépossédés. L'argument de Jason est qu'il ne contribuent plus au code et donc n'ont plus droit à la parole. Pourtant ils contribuent activement au succès de Maven, par des conférences, formations, articles, support, etc en plus d'avoir une vision de l'historique et de l'esprit du projet, qui a tout son sens. Les bonnes volontés ne manquent pourtant pas pour s'intéresser à l'API, essayer ce nouveau composant, ou proposer des modèles intermédiaires laissant dans Maven ce qui lui est spécifique (l'un des objectifs d'Aether est de supporter aussi les repository Eclipse P2).

OK, Sonatype a besoin de faire avancer Maven pour gagner sa croute, avancer vite et dans le sens qu'il veut lui donner, mais il y'a des façons moins brutales de faire.

Ca sent mauvais tout ça. Bien malin celui qui dira comment ça va se terminer.

La contribution de Sonatype au développement de Maven 3 est proche de 100%, aussi il ne faut pas s'étonner qu'il soit difficile de suivre ce qu'ils font depuis l'extérieur ... mais quelque fois ça devient plus que difficile.

Je vous ai déjà parlé de l'intégration de Guice comme conteneur de Maven 3. L'idée a été poussée par Olivier Lamy qui tente d'intégrer correctement Maven 3 dans Hudson, ce qui est nettement plus simple avec la branche Guice qu'avec le code historique Plexus. Fin de non recevoir, avec renvoi dans les cordes comme quoi ce code n'est pas suffisamment testé et que nous (pauvres développeurs indépendants) sommes mal placé pour juger de sa stabilité.

Et voilà un petit message amusant sur la Mailing List Maven :

Les réactions n'ont pas tardé. En effet, ces développements se sont fait purement en interne chez Sonatype, en particulier pour Aether. Le meilleur moyen pour se tenir au courant était alors de suivre le twitter de Jason, et le PMC (Project Management Committee) Maven est donc quasiment le dernier consulté.

Perso je ne comprend pas pourquoi Sonatype ne prend pas tout simplement les commandes de Maven 3 "hors Apache", comme SpringSource le fait de son framework ou JBoss de son serveur d'applications, ce qui ne nous empêche pas de les utiliser sans plus de questions.

Maven est déjà largement utilisé et n'a plus besoin de l'aura "Apache" pour se faire connaître. Dans le pire des cas ça pourrait être un fork dans la douleur, mais vu l'avance de Sonatype sur le sujet ça ne changerait pas grand chose. iBatis a quitté la fondation Apache dans des conditions moins politiquement correctes sans que ça fasse plus de vagues, et de toute façon la base des utilisateurs s'en moque.

Update :

"
Jason van Zyl
During the course of development of Maven 3.x development only Kristian and Olivier have dug in. I honestly don't believe droves of people here are going to all of a sudden start making huge contributions to the effort. 
( ... ) Having several people who haven't been even remotely involved in the project over the last year tell me what we should do with the code we wrote doesn't sit very well with me philosophically to be perfectly frank. You do the work, you earn the merit, and therefore the right to decide the fate of the code.
"


Si la philosophie de la fondation Apache, pour laquelle un PMC conserve son poste ad vitam même s'il ne contribue plus au code (il y a bien d'autres façons de contribuer), ne convient pas ... alors pourquoi s'encombrer avec cette fondation ?


à suivre.

Je passe l'été en compagnie de jMeter, parce que la plage c'est ringard et qu'on y prend des coups de soleil.

jMeter est un outil bien rodé, mais qui cache tout de même mal son âge. Si on pardonne l'IHM Swing assez moche, la logique de manipulation des éléments de contrôle est assez étrange. En particulier, les temps d'attente qu'il faut attacher en fils pour qu'ils s'exécutent avant une requête, plutôt que de les mettre ... avant elle, c'est assez tordu. Ceci dit, une fois qu'on a pigé le truc on arrive à s'y faire (« c'est pas pire que de passer à Maven » diraient certains).

Si on regarde sous le capot, là aussi ça sent fort le old school, jMeter date tout de même de 1998 (regardez le code de vos projets de 1998 pour rigoler). Il y a clairement une dette technique sur ce projet, même si ça ne l'empêche pas de rester pertinent. Pour ma part j'ai du développer un Sampler qui récupère les métriques JMX (java.lang:type=Memory) de la JVM sous charge, ainsi qu'un Listener qui stocke les mesures brutes dans une base Derby plutôt qu'un fichier CSV (données plus faciles à exploiter par la suite avec BIRT par exemple, voir ici). Ca se fait sans grande difficulté, mais c'est pas du code magnifiquement découpé comme on en fait tous aujourd'hui (ah bon, pas vous ? :P)

Une astuce à connaître : Quand on capture un scénario avec le proxy HTTP, on peut regrouper toutes les requêtes liées à un clic sous un contrôleur, ce qui clarifie le scénario. En remplaçant ces contrôleurs "génériques" par des "Transaction Controller" (et là on est bien content que le script soit en XML) on obtient une métrique pour chaque page de l'appli web, ce qui reflète mieux la performance ressentie par l'utilisateur que les résultats HTTP bruts.

Gros gros bémol à l'utilisation de jMeter : le reporting en est quasiment absent, et on est donc obligé d'exporter les données brutes en CSV (ou en base dans mon cas) pour une consolidation externe. D'un autre côté, quand on voit les tarifs de LoadRunner ou même de NeoLoad, on se dit que c'est l'occasion de s'essayer au reporting BIRT...

Autre soucis : jMeter utilise un Thread par utilisateur virtuel. C'est nettement plus simple pour son implémentation interne, mais pour simuler des milliers d'utilisateurs, même si chacun ne fait qu'une requête par minute, ça pose de gros soucis : chaque Thread occupe de la mémoire (native+heap) et on est vite à cours de ressources, sans parler de la surcharge pour l'OS qui doit gérer en masse les changements de contexte de ces Threads, qui ne font pourtant pas grand chose. Je me lancerais bien dans un gros refactoring de jMeter mais ... euh ... bon, vous aurez compris.

Ceci dit, la question est de savoir ce qu'on désire faire avec jMeter. Dans un esprit "consulting", on lui demande de valider une SLA et de fournir de jolis graphes 3D pour mettre dans le joli rapport d'audit en couleur sous Office 2010. Dans un esprit "main dans le cambouis" on lui demande de charger l'appli qu'on aura mis préalablement sous monitoring / profiling pour en déceler les faiblesses et y remédier. Ce n'est donc pas un hasard si jMeter supporte une dizaine de protocoles, mais sort péniblement un graphe tout moche : il a choisit son camp.

En tout cas, et jusqu'à preuve du contraire, jMeter est le seul outil à se greffer facilement dans une intégration continue pour faire de l'analyse d'évolution de perf, ce qui est nettement mieux que d'attendre la pré-prod pour tester l'appli et se rendre compte d'un gros problème de conception ...