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

27 janvier 2011

"Mavenizer" un projet

Lorsqu'on cherche à convertir un projet "old-school" sous Maven, l'une des premières tâches consiste à identifier la liste de dépendances du projet. On peut se baser sur le nom des JAR, éventuellement se rassurer en inspectant le fichier MANIFEST (lorsqu'il est renseigné), mais en général c'est :

  • long
  • barbant
  • peu fiable : j'ai déjà vu des JAR "patchés" ou "complétés" avec des classes annexes

Une solution plus propre consiste à se baser sur les empruntes MD5 et SHA1 que le repository Maven conservent pour chaque artefact. Une simple recherche Google sur cette clé retourne l'identification précise d'une bibliothèque (avec parfois des surprises !).

Il y a pourtant encore plus simple...

Le repository manager Nexus propose un moteur de recherche qui prend en entrée l'emprunte SHA1. Basé sur son index interne, il va nous retrouver la bibliothèque, et en plus nous indiquer les versions plus récentes (si on veut en profiter pour un petit lifting). L'avantage de Nexus, c'est qu'il propose une API REST qui permet d'automatiser tout ça. Allons-y donc gaillardement !

J'écrit donc mon tout premier script Ruby ! - et oui, tout fout le camp ma bonne dame - ce langage est génial pour écrire des scripts de ce type, avec des bibliothèques bien puissantes ;)

require 'find'
require 'digest/sha1'
require 'net/http'
require 'rexml/document'
include REXML

for file in Dir.glob("*.jar") do 
    sha = Digest::SHA1.file( file ).hexdigest
    url = "http://myNexus/service/local/lucene/search?sha1=" + sha 
    resp = Net::HTTP.get_response( URI.parse( url ) )
    puts File.basename( file ) + " (" + sha + ") = \n";
    doc = REXML::Document.new( resp.body )
    XPath.each( doc, "//artifact" ) do |r|
          puts "<dependency>"
          puts "   <groupId>#{r.elements["groupId"].text}</groupId>"
          puts "   <artifactId>#{r.elements["artifactId"].text}</artifactId>"
          puts "   <version>#{r.elements["version"].text}</version>"
          puts "</dependency>"
    end  
 
end
Rien de bien méchant, comme vous pouvez le constater, et ce script permet d'analyser rapidement une liste de jar en proposant les éléments à intégrer dans le POM. Il restera "juste" à identifier les bibliothèques qui seront passées entre les mailles du filet.

Maintenant que Maven Indexer est un projet Apache (depuis la version 3.1.0), ce serait bien d'intégrer cette fonctionnalité au plugin dependency [MDEP-269] ... ou ailleurs.

26 janvier 2011

2011, l'année du fork

2011 pourrait bien être l'année du fork.


Non, je ne parle pas du nouvel an chinois, mais de la scission d'une communauté open-source (fork).

Le premier va se dérouler du côté du serveur d'intégration continue Hudson.
Après avoir géle puis migré le projet (sans prévenir) de l'infrastructure java.net vers kenai, Oracle réclame aujourd'hui le pilotage du projet, ou en tout cas l'application de règles strictes de pilotage et de cession des droits sur les contributions. La communauté ne suit pas, prise depuis le début à rebrousse-poil, et a déjà migré sur gitHub et google-groups.

Les dernières tentatives d'accord pour trouver un arrangement acceptable, légitimant une communauté indépendante sans couper les ponts avec Oracle, ne progressent pas. On s'oriente donc à grand pas vers un changement de nom pour Hudson (la seule chose qu'Oracle possède encore c'est ... ce nom "hudson ®") qui deviendra Jenkins.

La communauté Hudson - légitime en terme de lignes de code - se retrouve donc face à Oracle qui ne lâche pas grand chose, fort de sa légitimité sur le nom "hudson" et l'historique du projet.

Le second pourrait se dérouler du côté de Maven. 
Critiqué pour son pilotage unilatéral du projet au travers de sa société Sonatype, Jason Van Zyl a claqué la porte du Project Management Committee Maven. Fondateur du projet, il ne participe donc plus à ces discussions (qui a dit "disputes" ?) et continue à bosser avec ses collègues sur l'outil qui fait vivre sa boite, mais sur gitHub plutôt que dans le SVN Apache. Le code reste opensource, accessible à tous, mais ne suit plus les règles de bonne conduite communautaire édictées par la fondation. Sans a priori sur les personnalités en présence, ce n'est pas la première fois qu'un leader se plaint du modèle Apache et finit par aller voir ailleurs [1].

Les raisons de la crise : une partie non négligeable de Maven (Aether) est désormais hébergée chez Sonatype, et bien que toujours opensource, est vécue par certains contributeurs Maven comme une perte de contrôle (nécessité de signer une CLA pour contribuer). Comme pour ajouter à la sauce, Modello et Plexus, deux projets "socle" de Maven, ont été déplacés sur le gitHub Sonatype puis fermés sur codehaus.

Jusqu'ici les échanges liés à ces frictions sont restés discrets, la fondation Apache ayant pour règle de gérer ce genre de conflit en privé. Avec la contribution de Sonatype dans la fondation Eclipse via le projet m2eclipse, un changement de license [2] sur un composant a ébruité publiquement la situation.

Il ne s'agit pas (encore) d'un fork, mais rien n'interdit à Sonatype de publier ses propres releases de Maven (mais pas Apache Maven) dans le cade de son offre Sonatype Professional, le nom n'étant pas déposé par la fondation. Le PMC doit donc trouver un compromis, définir des règles sur l'utilisation de ces composants "externes" qui constituent pourtant une part importante de Maven 3 (core), et voir comment intégrer les développements de Sonatype tout en conservant un pilotage à la Apache du projet et en continuant à assurer la maintenance des nombreux plugins qui - eux - restent un terrain de jeu équitable pour tous les contributeurs (les moins doués se contentant d'écrire des bouquins sur le sujet).

La communauté Apache Maven - légitime en terme de contribution historique et de support - se retrouve donc face à Sonatype, fort de sa légitimité sur la quasi-totalité du travail de développement de Maven 3.

Inutile de vous dire à quel point ces querelles de légitimité, de licence, de règles de pilotage sont à la fois passionnantes et barbantes pour les contributeurs qui passent un temps fou à éplucher les mailing-list abreuvées de messages enflammés. 2011 risque de ne pas être une année reposante.




[1] le développement de log4j 1.3 est quasi abandonné, englué dans des discussions sur le maintien de la compatibilité. Ceki Güclü a préféré reprendre à 0 avec l'excellent slf4j.
[2] https://github.com/sonatype/sisu, notez les deux fichiers LICENCE.txt. Sous licence EPL, le code associé n'a plus aucune chance de revenir à la fondation

08 octobre 2010

Maven 3.0 FINAL

Tout est dans le titre,
Après des mois (des années) à attendre Maven "2.1", finalement renommé Maven 3, de nombreux (re)développements et une interminable suite de tests de non-régression, voici enfin venu le renouveau de Maven.

Quel changements pour l'utilisateur ? Aucun ou presque - à part un build plus rapide et moins consommateur de mémoire - car le premier objectif de Maven 3 est d'être compatible (à quelques détails près) avec son prédécesseur. Par contre, le socle technique est autrement plus propice à de futures évolutions, et à son intégration dans d'autres outils comme en témoignent polyglot, tycho, mvnShell ou m2eclipse, et les premiers plugins hudson maven3.

Le meilleur est à venir.

02 septembre 2010

GWT 2.1 will be maven compliant !

Developping gwt-maven-plugin was a pain. GWT was clearly not designed with Maven conventions in mind and we had to find many hacks and workarounds. Google Eclipse Plugin didn't made things simplier as it came with some hard-coded path and we had then to satisfy 3 conflicting points of view...

But things change

With 2.1 release, GWT Team is looking to nicelly integrate with Maven. We are in contact to see what changes could occur on GWT side to better fit into Maven. The first visible effort is a new "-maven" option in webAppCreator script to generate a maven compliant project structure and the adequate POM.

The maven plugin allready includes an archetype for same purpose. I'll upgrade it to match the webAppCreator one, with some improvements (including Google Eclipse configuration). I've sent the GWT / Google Eclipse Team a list of feature requests to make Maven / Eclipse / GWT work better together.

As a result, I expect to release a 2.1.0 preview releases of gwt-maven plugin for next GWT Milestones, so that the plugin could benefict from changes made on Google side, and the POM generated by webAppCreator could also use those new features.

I also called for a vote on Mojo Dev List to change the development process so that new release of he plugin match a GWT release, and don't support anymore all SDK history. This will make things technically simplier and will drop a large set of obsolete parameters.

Good days Maven users, GWT will become your favorite toolkit in near future !

Update :
You can test a first preview early-adopter draft SNAPSHOT.
Doc is deployed at http://people.apache.org/~nicolas/gwt-maven-plugin-2.1/ (much cleanup needed)
same URL is a maven repo to get the plugin. Test it using (as a single line) :

mvn archetype:generate -DarchetypeRepository=http://people.apache.org/~nicolas/gwt-maven-plugin-2.1 \
 -DarchetypeGroupId=org.codehaus.mojo \
 -DarchetypeArtifactId=gwt-maven-plugin _\
 -DarchetypeVersion=2.1-SNAPSHOT  

13 août 2010

Dallas, ton univers impitoyable ...

Les récents remous sur la ML Maven-dev, que je vous ai rapportés à chaud, m'amènent à m'interroger sur la stratégie de Sonatype.

Tout d'abord une mise au point : l'avenir de Maven n'est pas, mais alors pas du tout remis en question. Au contraire, l'activité supersonique de Sonatype sur le sujet et les réactions des committers montrent que l'intérêt pour le projet est bien vivant, que les idées et les bonnes volontés ne manquent pas. En témoigne le premier bug OutOfMemory identifié par Arnaud et les nombreux commentaires techniques qu'on peut lire entre deux trolls.

Ce qui crée la prise de tête, ce sont des aspects purement politico-phylosophiques, entre Jason qui veut aller vite, très vite avec la dream-team qu'il s'est créé, le clan des bisounours Apache-forever qui défendent bec et ongle le modèle du consensus, et la majorité de ceux qui veulent juste que le train avance sans perdre trop de wagons en chemin (1).

Ceci étant dit, on est en droit de s'interroger sur la stratégie de Sonatype. Plusieurs hypothèses :

Scénario 1 : Santa barbara
Brian est parti avec Jason, et du coup Brett lui en veut à mort, alors il s'est associé à Maria pour le lui faire payer. Comment va réagir Stephen ? Vous le saurez en suivant le prochain épisode de votre feuilleton de l'été. Pas convaincu ?



Scénario 2 : L'apocalyspe
Jason est l'antéchrist et Sonatype son église. Ils veulent détruire l'informatique de l'intérieur. Heuresement, les valeureux Apachistes défendent la terre promise de ses assauts. Bon, on passe.



Scénario 3 : Le complot
Une société secrète s'en montée et tente de nous dégouter de Maven, malgré les tentatives de Sonatype de sortir le projet de ses culs-de-sac techniques. Gradle tirerait les ficelles dans l'ombre et aurait prévu le coup de longue date en mettant de nombreux committers historiques sous hypnose. Improbable.

Scénario 4 : L'OPA
Sonatype veut fagociter Maven, pour suivre le modèle d'un JBoss, SpringSource, et autre eXoPlatform qui ouvrent leur source tout en gardant la main sur la roadmap. Comme tous les committers ne sont pas à vendre, la seule solution qui reste est le fork, et dans cet objectif il faut construire une cause acceptable : l'immobilisme face aux forces innovantes par exemple ?

J'avoue que j'ai pas mal penché pour cette hypothèse, mais ça c'était avant de croiser Jason à Devoxx pour sa conférence sur Maven 3...

Scénario 5 : Les Geeks en action
Jason est un gars dont les capacités de communication et de diplomatie sont inversement proportionnelles à son talent de programmeur; et c'est un excellent programmeur. Son objectif est de faire vivre sa boite avec le projet qu'il a créé de ses mains, et de le développer à sa guise sans qu'on vienne lui casser les pieds. Si le succès de Maven ne peut lui être attribué seul, son influence n'a jamais faibli.

C'est le pur Geek qui ne s'intéresse qu'au code et n'a que peu de complaisance pour les interminables discussions philosophiques sur la façon de faire telle ou telle chose; "Montre moi du code qui marche et on verra". Avec cet éclairage, accrochages et prises de bec avec les autres committers deviennent inévitables, mais cela ne retire rien à la pertinence de ses propositions.

Vous l'aurez compris, cette dernière explication est la bonne. Ne cherchez pas à dénigrer Maven en pointant du doigt son développement mouvementé. Soyez plutôt jaloux de voir autant de monde impliqué, et même une société qui vit et investit corps et âme sur son développement.

(1) avez-vous noté le subtil jeu de mot ? Wagon est l'un des composants de Maven qui va être remisé avec l'arrivée d'Aether :P

06 août 2010

Maven3, ça part en couille

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.

04 août 2010

Maven3, Guice, Aether ... et petite prise de bec

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 :

Jason van Zyl

Hi,

We have two major pieces that we, Sonatype, would like to merge into Maven 3.x trunk.

The first are the Guice changes that we've been talking about for a while, and the second is the introduction of Aether which is our second attempt at a stand-alone repository API. The PMC is aware of Aether as Brian reported it in our quarterly report to the Apache Board, but other developers who are not on the PMC and the community in general might not know much about it.

I just posted an entry giving a very high level description:

http://www.sonatype.com/people/2010/08/introducing-aether/
(...)
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.

24 juin 2010

Deux ans de Maven - le bilan


Après des années à trainer sur la mailing list de Maven, j'ai été invité dans la communauté Mojo qui héberge une large panoplie de plugins Maven "non stratégiques" - comprendre non supportés par le projet Maven lui-même. J'y ai lancé les javascript-maven-tools (à l'état dormant depuis) et repris le flambeau sur le plugin GWT. Ce projet, relativement ouvert aux nouveaux contributeurs, fonctionne sur ce modèle : proposer, supporter, passer la main. Un plugin n'y vit que si des développeurs sont là pour le soutenir, développeurs qui sont souvent ses premiers utilisateurs.

Je suis ensuite passé dans le code d'Archiva pour des besoins internes. Ayant du temps plus ou moins officiellement dégagé sur cette tâche j'ai pu m'investir et faire des évolutions intéressantes, créer des liens forts avec les développeurs, qui m'on finalement invités à rejoindre le projet Maven - à l'époque non différenciée d'Archiva. Nous sommes fin 2007.

Depuis cette date, j'ai continué à oeuvrer sur le plugin Mojo GWT et j'ai quelquefois apporté ma pierre à l'édifice Maven, via quelques contributions mineures (release:stage, c'est moi). Mes tentatives pour rentrer dans le "core" se sont soldées par un échec : soit j'ai clairement fait des boulettes et j'ai été vite renvoyé dans les cordes [svn rollback], soit mes propositions sont restées sur le pavé. En 30 mois je n'ai donc rien committé de concret dans le svn Maven.

Par contre, j'ai activement participé à la com' sur Maven, à travers les JUGs et ce fameux bouquin dans lequel j'ai réussi à embarquer Arnaud. Tout ça c'est du temps libre, ça ne rapporte rien en dehors de l'estime de la communauté - ce qui est déjà beaucoup.

Mon activité pro ne consiste pas à développer Maven, déjà que contribuer à corriger des bugs ou à améliorer quelques plugins ne soit pas une tâche tout à fait officielle. Mon temps libre est déjà largement amputé par l'organisation du BreizhJug. Je n'ai plus le temps pour élaborer des idées, développer un POC et le faire challenger par ceux qui passent leurs journées sur le projet. Même si cela parait nécessaire le coût est trop important pour un simple contributeur comme moi.

J'ai donc fait le choix symbolique de me retirer de la liste des développeurs Maven. Cela ne me retire pas le droit de commit, rassurez-vous, je pourrais donc encore venir appliquer quelques patchs intéressants pour corriger un bug que je rencontre dans mon boulot de tous les jours. Par contre je ne compte plus m'impliquer dans le développement de Maven.

Hudson utilise un modèle assez étrange au premier abord : pour devenir committer, il suffit de montrer patte blanche. "Bonjour, j'ai écrit un patch pour l'ano ###" (et/ou) "J'ai écrit un plugin rigolo boite-à-meuh-hudson-plugin". La réponse ne tarde pas : "Quel est ton ID java.net, comme ça tu pourras le committer toi même". Hudson fonctionne sur la confiance : ceux qui participent sont déjà une toute petite sous-catégorie de gens motivés, il ne faut surtout pas les freiner. Un plugin hudson ne vit que parce qu'un ou deux développeurs le supportent, et le projet a besoin de sang neuf pour vivre et s'épanouir.
C'est vrai que lorsqu'on regarde sous SVN, Hudson paraît particulièrement bordélique. C'est un effet de bord totalement assumé ! Obliger les développeurs à suivre des conventions trop rigides c'est créer une barrière aux contributeurs. Si un plugin est proposé, même dans un état discutable, mais avec de la motivation et du temps pour s'en occuper, alors feu vert. S'il devient vraiment utile et attire d'autres développeurs il sera toujours temps pour le "nettoyer". Jusqu'ici, le projet n'a pas eu à souffrir de ce qui ressemble a priori à un manque de rigueur. Les versions se succèdent à un bon rythme, avec des corrections rapides et de nouvelles idées.

Deux approches opposées,

  • le modèle Apache Maven : les règles et les consensus à la Apache, et un pilotage "business-driven", 
  • le modèle Hudson : "open-bar" ouvert à toutes les bonnes volontés. 

Les deux outils ont fait leurs preuves et sont devenus l'un comme l'autre des incontournables, avec un excellent niveau de stabilité. Comme quoi tout n'est pas gravé dans le marbre

07 juin 2010

Maven 3 reloaded : Guice

Lors de la conf "Maven3" au ParisJug avec Arnaud Héritier, nous avons indiqué que le remplacement du coeur de Maven (Plexus) par Google Guice était repoussé à une version 3.1 de Maven. Les choses semblent cependant s'accélerer.

Pour les besoins de Nexus, Sonatype a développé une couche d'abstraction "Spice" qui permet d'utiliser la syntaxe Plexus avec un conteneur autre, typiquement Google Guice qui est le nouveau moteur de Nexus. Cette expérience réussie donne une sérieuse crédibilité à cette option de migration en douceur.

La même approche a été testée par Sonatype pour Maven3, et Olivier Lamy a importé ces modifications dans une branche du SVN Apache. Ce code passe déjà les tests IT de Maven, même s'il reste quelques incompatibilités liées à de mauvaises pratiques dans certains plugins (modification des composants internes de Maven) que ce nouveau moteur n'autorise plus. Ces signaux plutôt positifs pourraient aider à faire passer Guice comme moteur de Maven dès la version 3.0, ce qui aurait de nombreux effets bénéfiques :

Pour les utilisateurs ou développeurs de plugin, ce changement n'apporte rien de visible, sinon des logs plus clairs quand la configuration est incorrecte - ce qui, avec Plexus, donne parfois le signal de départ pour de longues heures d'analyse. A plus long terme, l'utilisation de Guice permet d'envisager une migration plus profonde des "bons usages" de développement de plugins Maven vers les annotations @Inject (JSR330). Ceci supposera cependant que les plugins qui suivent cette voie soient dédiés Maven3, ce qui promet de longues discutions sur la liste de dev :)

Pour ceux qui veulent embarquer Maven3 dans un autre outil par contre, ce changement est significatif. La configuration de Guice dans ce mode est nettement plus simple. L'intégration de Maven 3 sur Hudson nécessite ce genre d'acrobatie, et Guice sera le bienvenu pour ne pas inutilement compliquer la tâche.

Maven 3 est donc bien en mouvement, mais avec sa très large base d'utilisateurs il ne peut pas se permettre de changements brutaux sans fournir de harnais de sécurité. C'est ce qui le différencie de quelques concurrents comme Gradle, qui apportent de nouvelles idées, mais ont surtout la liberté de tout casser s'ils ont pris une mauvaise orientation.

05 mai 2010

Maven 3 au ParisJUG

Je serais le 11 mai au ParisJug pour présenter en compagnie de mon Arnaud Héritier préféré une synthèse rapide des nouveautés de Maven 3. Rapide parce que le ParisJug ne nous laisse que 30 minutes, aussi nous avons choisi pour notre sujet une formule ... inhabituelle.

Si vous avez aimé le bouquin, le ton que nous allons (essayer de) donner à cette intervention devrait vous plaire. Et pour ceux qui ne peuvent se contenter de 30 minutes, un petit détour par la troisième mi-temps devra combler ce manque.

Infos, inscriptions, et toute ce genre de choses sur ParisJug.org.

12 avril 2010

Maven 3 en multithread

Une grande majorité des projets basés sur Maven suit la convention de décomposer le projet en modules, selon l'architecture ou les domaines fonctionnels de l'application. Assez fréquemment on retrouve donc quelques modules bas niveau sur lesquels sont basés des module plus avancés, services web, batchs ou IHM web.

Un build "classique" enchaîne la construction de ces modules sans tirer parti du parallélisme de l'architecture de la machine. Si les I/O restent un élément important dans la vélocité du build (pour ma part, mon repository local est dans un RamDisk ce qui booste bien les choses), il est dommage de laisser nos quad-core dormir en attendant la prochaine compilation.

Depuis la semaine dernière, le trunk de Maven3 intègre une évolution qui était pour l'instant développée sur GitHub en pure expérimentation : il s'agit de la parallélisation du build. Pour expérimenter cette option, vous pouvez récupérer un nightly-build de maven 3 sur l'intégration continue du projet.

L'option -T permet de définir le nombre de threads qui vont supporter le build. Maven se charge de répartir la construction des modules du projet sur ces différents Threads et de réordonner le log pour qu'il reste lisible selon un ordre "classique".

Pour ma part, je n'ai pas réussi à le faire fonctionner sur des projets significatifs. Avec mon "gros" projet, je tombe sur une ConcurrentModificationException lors de la compilation AspectJ. Sur un build Archiva qui trainait sur mon disque (nostalgie...) c'est l'instrumentation JPox qui échoue.

Il est probable qu'aucun plugin maven ou outil impliqué dans le build n'ai prévu jusqu'ici d'être utilisé dans un cadre multi-threadé de ce type... il va donc y avoir une grosse campagne de test et d'évangélisation à prévoir. En attendant, Maven est à ma connaissance le seul outil de build a expérimenter cette voie, qui devrait prendre tout son sens sur les fermes d'intégration continue disposant de multi-coeurs et qui pourraient ainsi devenir très réactives.

Wait & See...

23 novembre 2009

Dans toutes les bonnes libraires

Arnaud a (enfin) trouvé notre bouquin dans les rayons de la FNAC. On sera un peu surpris par la catégorie dans laquelle il a été mis, mais au moins il est dispo en vrai cette fois ;)

44588735

18 novembre 2009

Apache Maven@Devoxx

Ca y est, mon bouquin est présent sur Devoxx !

bouquin

Ca aura été un peu compliqué à organiser, Merci à Pearson d’avoir réglé le problème dans l’urgence. Il n’est malheureusement pas disponible à la vente et je ne pourrais pas vous le dédicacer – rendez vous au Monde en Tique où une journée sera organisé bientôt pour cela – par contre vous pourrez tout de même le feuilleter : demandez l’unique exemplaire disponible à la caisse !

12 novembre 2009

Maven multi-threadé ?

On a vu de nombreux billets du blog Sonatype montrant les premiers effets de la lourde refonte du coeur de Maven en "Maven 3", par exemple de la possibilité d'utiliser d'autres format que le XML pour définir le POM.

Sur ce billet on peut découvrir comment, devenu plus accessible, le code encourage à nouveau des développeurs talentueux à soulever le capot et à se salir les mains. Ce premier exemple est plus un proof of concept, et vise à apporter à Maven l'exécution en parallèle du build (pensez aux projets multi-modules dont certaines branches sont indépendantes).

Au delà du gain de performance possible et de la date d'inclusion dans une version fonctionnelle de Maven, c'est bien une preuve pratique qu'on peut enfin entrer dans le code de Maven, le comprendre et l'enrichir de manière significative - un peu plus que du bug fix.

Peut m'importe ici la fonctionnalité proposée, même si elle semble intéressante, ce que je remarque (et que souligne aussi le blog Sonatype) c'est que la contribution vient d'une personne extérieure à Sonatype, signe de la ré-ouverture de Maven-core aux développeurs de la communauté. Vous savez que j'ai été très critique sur la gestion de Maven3, développé sans par Sonatype, sans visibilité pour ceux qui ne suivent pas les listes et IRC à plein temps, et laissant la communauté en attente d'un résultat palpable. La roadmap de Maven3 a très longtemps été un flou total.

Si j'y suis allé sans doute un peu fort -- je doute que Jason accepte à présent de devenir mon amis sur FaceBook :) -- cela aura au moins participé à pousser Sonatype vers plus de transparence. Entre autre, les releases alpha de Maven3 se multiplient et les signes de redémarrage d'un développement pluripartite apparaissent. Avec ce nouvel élan, Maven 3 va donc être une base pour cristalliser de nouvelle idées, bien au delà du simple nettoyage de code - et les idées ne manquent pas !


18 septembre 2009

premiers pas avec GWT 2.0

Le plugin gwt-maven-plugin est disponible en version 1.2-SNAPSHOT avec un aperçu du support GWT 2.0. Les fonctionnalités ne sont pas forcément sans bugs et probablement encore incomplètes, mais les nouvelles options du compilateur sont déjà proposées.

La mise en oeuvre nécessite de récupérer le SDK (prendre par exemple les builds proposés par SFEIR). Configurer ensuite le plugin en affectant le paramètre gwtHome, pour le forcer à utiliser cette version, alors que par défaut il s'adapte à vos dépendances.

Vous avez alors accès à tout plein de nouvelles fonctionnalités, comme par exemple le draftCompile pour accélérer votre intégration continue, ou le rapport SOYC pour analyser la traduction de votre code Java en JavaScript et ses points noirs.

Pas de date prévue pour la finalisation de cette version 1.2, mais je vais essayer de coller à l'actualité de GWT 2.0.

30 juillet 2009

maven, eclipse et aspectJ : si si, ça marche

Mon projet préféré du moment est une énorme usine à gaz avec un bon paquet de modules Maven. Sous Eclipse avec m2eclipse, des builds Maven se lancent en pagaille si on active le "build automatically".

Soucis, mon projet dépend énormément d'aspectJ (via mon Fonzie à moi que j'ai) et la compilation maven prend des plombes.

  • option 1 :
décocher le build automatique. Il faut alors lancer des builds à la main et bien sur dans le bon ordre, autant dire que c'est galère aussi et qu'on se retrouve souvent à exécuter du code qui ne colle pas aux sources
  • option 2 :
ne plus gérer les relations inter-projet sous eclipse en tant que tel, mais passer par les JAR. On lance donc explicitement un gros build Maven avant de tester. Plus prédictif mais pas du tout productif
  • option 3 :
Utiliser AJDT 2.0, dont le build incrémental est un régal. Soucis : si l'intégration avec m2eclipse configure tout bien comme il faut AJDT, le plugin Maven est toujours exécuté lors des builds maven et on retrouve le problème initial. D'où ce magnifique hack :

<profiles>
<profile>
<id>m2eclipse</id>
<activation>
<property>
<name>osgi.bundles.defaultStartLevel</name>
</property>
</activation>

<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<configuration>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
</profile>

Avec cette conf magique, AJDT est correctement configuré par m2eclipse et fait parfaitement son boulot (le hotswap permet ainsi d'éditer le code et de constater le résultat à chaud dans Tomcat), ET les build maven sous eclipse sont raisonablement rapides, le plugin aspectj ne faisant plus rien.

C'est un hack bien pourri, mais ça montre que m2eclipse 0.9.9, une fois le "custom lifecycle mapping" en place et supporté par de nombreux plugins, devrait nous faire oublier toutes ces années de cohabitation difficile entre Maven et Eclipse.

maven, eclipse et aspectJ : si si, ça marche

28 juillet 2009

Maven et Hudson main dans la main


Mon projet prend 30 minutes pour se construire, tests IT compris. Dans de nombreux cas, les modifications associées à un commit ne concernent qu'un sous ensemble de modules et un échec pourrait être détecté en une dizaine de minutes. Même constat pour le retour au bleu : 30 minutes d'attente pour constater qu'une correction en périphérie du projet est valide, avec une reconstruction de 90% du projet qui n'est pas du tout concerné.

Pour le rendre plus réactif, j'ai du découper "manuellement" le projet selon ses modules maven (principaux) et prévoir les chemins SVN et autres commandes MVN pour que seuls les projets considérés soient construits. Ca va déjà nettement mieux, mais pour pousser la logique jusqu'au bout il faudrait configurer un job Hudson pour chaque module maven, et assurer la mise à jour de ces jobs à chaque modification de la structure des modules.

C'est fastidieux, et source de soucis divers, mais bon ça marche et mon build est devenu nettement plus réactif - effet de bord non négligeable, on est passé au grand bleu après de nombreuses heures de gyrophare rouge allumé dans le couloir...


Je pourrais conclure là dessus, mais Hudson n'en finit plus de métonner :

Vous le savez peut être, Maven 2.1 permet de spécifier une liste de modules à construire, plutôt que de se coltiner tous les modules d'un multiprojet. Maven se comporte alors à la make, c'est à dire qu'il va construire les modules spécifiés + tous les modules nécessaires. On peut aussi lui demander de se comporter à la hudson, c'est à dire de construire tous les modules qui peuvent potentiellement être impactés par les modules construits.

Il ne restait donc qu'un pas à franchir pour que Hudson puisse (enfin) construire intelligement les projects Maven un peu trop volumineux en ne sélectionnant que les modules impactés par un commit.

Avec la révision 138 d'Hudson, prévue en fin de semaine, une nouvelle option avancée dans les options de build Maven devrait apporter cette fonctionnalité tant attendue. Jusqu'ici seul Continuum savait gérer finement les modules Maven, voici donc que son concurrent vient lui couper l'herbe sous le pied.

Elle est pas belle la vie ?
(en fait non, il y a encore Eclispe, JBoss, et ma non-augment' de fin d'année à considérer)

02 juin 2009

Maven bouge dans le bon sens

Avec mon précédent billet je me suis attiré quelques foudres de la part de la communauté Maven, mais j'ai aussi mis sur le tapis un état de fait : en dehors des membres de Sonatype qui sont à plein temps sur Maven 3 il est bien difficile de suivre le développement de cette nouvelle version "de l'extérieur".

Les choses évoluent dans le bon sens : Jason a reconnu que le développement de Maven 3 nécessite un gros investissement personnel ne serait-ce que pour se tenir au courant. Il ne compte pas renoncer à son rôle de développeur pour celui de responsable communication en fournissant à la communauté un joli résumé du 'où c'est qu'on en est', mais ne veut pas pour autant se couper de la base communautaire du projet.

Dernier rebondissement, l'organisation de conférences téléphoniques hebdomadaires permettant de discuter "live" de l'état et de l'avenir du projet, une idée reprise du fonctionnement de la fondation Eclipse. Enregistrées pour ceux qui ne sont pas disponibles à l'heure dite (17h pour la france), ou dont l'anglais est trop approximatif pour suivre une discussion sans décrocher, ces débats seront consultables dans les jours qui suivent et pourront être poursuivis par des questions plus précises via la liste de dev.

Ce fonctionnement devrait permettre à plus de monde de mettre un pied dans Maven 3, sans pour autant alourdir le processus de développement. Documenter chaque choix technique mis en oeuvre serait en effet un travail titanesque.

Bonne nouvelle donc. Après la renaissance de Maven 2.x (une 2.2 est en cours de finalisation), Maven 3 va devenir plus visible pour la communauté. Les devs de Maven 3 se focalisent sur la compatibilité avec l'existant maven 2, via une large batterie de tests d'intégration. Un travail important auquel la communauté peut contribuer en proposant de nouveaux tests IT sur des cas spécifiques. Les résultats sont semble t-il encourageants, aussi on peut espérer avec un Maven3-SNAPSHOT fonctionnel, même si la stabilisation définitive va prendre du temps.

En parallèle, des membres francophones de la communauté se sont portés volontaires pour traduire le definitive guide en français, travail à long terme vu le pavé que constitue ce bouquin, mais qui va apporter à Maven une documentation plus accessible - en complément, bien sûr, de mon bouquin ;)

26 mai 2009

Maven, Eclipse et GWT main dans la main


Avec la sortie du Plugin Google Eclipse, il me restait à intégrer proprement le couple Maven + GWT avec l'IDE le plus connu des développeurs java - je n'ai pas dit le meilleur ;p

C'est désormais chose faite avec le dernier SNAPSHOT du plugin GWT, qui devrait clore une longue liste avant une release que j'espère proche, le temps de fixer les derniers bugs et erreurs de documentations.

Comme je l'explique sur cette page, la principale difficulté est que le plugin Google Eclipse n'est pas très "maven compliant" et oblige à faire quelques concessions. Cependant, avec l'aide de m2eclipse (ça doit aussi marcher avec IAM, je n'ai pas encore testé) on obtient le résultat suivant, que vous pouvez expérimenter à la maison en utilisant le projet de test it/reactor du plugin, ou sur votre propre projet (dites moi ce que ça donne) :
  • import du projet Maven sous Eclipse par m2eclipse. Les dépendances, répertoires de sources et de génération de code sont identifiées et configurés sous Eclipse, et surtout lesmodules d'un multi-projet et dépendances présentes dans le workspace sont "résolues" en tant que références inter-projet et non via les jars du repository local.
  • ajout du support GWT (étape encore manuelle, j'y travaille) via Google Eclipse Plugin. Soucis ici, le plugin ajoute lui même les dépendances GWT qui font donc doublon avec celles gérées par m2eclipse. Ca n'a pas l'air gênant à condition bien sûr que les versions soient cohérentes. Si quelqu'un à une astuce je prend ;)
  • génération des lanceurs pour les modules de l'application en lançant mvn gwt:eclipse. Cette tâche gère désormais aussi bien les lanceurs "classiques" et ceux exploitant le plugin Google Eclipse (cas par défaut). Au passage, le plugin prépare le répertoire /war du mode hosté.
  • un simple run as > web application sur le lanceur généré et le mode hosté démarre. L'URL de la page web hôte n'étant pas déclarée dans le fichier module, j'ai pris comme convention qu'elle porte le même nom que le module et est présente dans son répertoire public. C'est un peu limitatif mais ça doit être assez courant. Sinon il suffit d'éditer la configuration d'exécution.
Le gros progrès (en terme de confort et de productivité) c'est que si votre application est découpée en modules maven, une modification dans le code source d'un de ces modules sera directement exploitable dans le navigateur hosté par un simple refresh. Pas besoin de repackager un Jar ou tout autre manipulation - perte de temps.

Pour aller au delà du serveur hosté et passer sur un "vrai" serveur d'appli (-noserver) il faut jongler un peu entre le plugin maven-war et les chemins "en dur" choisis par Google, mais on s'en sort.

On a donc enfin une solution productive pour faire du GWT sous Eclipse sans s'empêtrer dans des builds Maven sans fin. Reste à vérifier que tout ça reste bien compatible avec le fonctionnement "hors eclipse" du plugin : La tâche gwt:run a encore ses fans (à moins que ce soit juste du anti-Eclipse ?)

Je n'ai pas testé le support de GWT sous IDea ou NetBeans, mais si un fonctionnement équivalent est possible je serais ravi de l'intégrer au plugin - les patchs sont bienvenus :)