Ca le fait, non ?
25 juin 2009
assembly mon amour...
Le plugin maven-assembly est probablement le plus énervant de la galaxie Maven.
en lançant un mvn -f pom-assembly.xml install maven va enchaîner l'install des modules mais pas celle de ce POM qui n'est plus le parent global.
Comme de nombreux Mavenistes j'utilise "l'héritage naturel" qui consiste à utiliser un même POM pour définir les modules du projet et comme parent commun.
Effet de bord : la construction mvn install commence par le parent, puis les modules, ce qui est logique si on veut que les modules "voient" leur parent dans son état final.
Maintenant, si je veux produire un assembly, ce plugin doit s'exécuter ... après les modules. Le bon vieux problème de l'oeuf et de la poule !
Une solution simple qui peut servir à d'autres : un POM "pom-assembly.xml" qui ne déclare que le plugin assembly attaché à la phase install et un unique module "."
<modules>
<module>.</module>
</modules>
<build>
<defaultgoal>install</defaultgoal>
<plugins>
<plugin>
<artifactid>maven-assembly-plugin</artifactid>
<inherited>false</inherited>
...
</plugin>
</plugins>
</build>
en lançant un mvn -f pom-assembly.xml install maven va enchaîner l'install des modules mais pas celle de ce POM qui n'est plus le parent global.
D:\projets\xx>mvn -f pom-assembly.xml
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] xx parent
[INFO] xx :: Composants GWT
[INFO] xx :: configuration
[INFO] xx :: infrastructure
[INFO] xx :: wsdl
[INFO] xx :: modele
[INFO] xx :: services
[INFO] xx :: persistance
[INFO] xx :: ordonnanceur
[INFO] xx :: services web
[INFO] xx :: batchs
[INFO] xx :: simulateurs
[INFO] xx :: ear
[INFO] xx :: tests d'intÚgration
[INFO] xx :: assembly
[INFO] -----------------------------------------------
Je sais, ça sent le gros hack à deux cents, mais ça dépanne en attendant Maven 3
24 juin 2009
Saber light extreme feedback device
Pour l'alim j'ai indiqué 9v mais peut importe, vu qu'on a un suiveur de tension il faut juste "plus de 5v". Je n'ai pas mis de fusible sur le schéma, mais pensez y tout de même.
Et ne venez pas vous plaindre si vous vous flanquez du 220v dans les didis, j'en ai pris ma dose moi aussi :)
Le monde méconnu de la sécurité
Sur cette vidéo, on découvre comment n'importe quel blaireau avec les bons outils peut pirater le compte gMail de ses petits copains.
En y regardant de près, il ne faut que quelques outils bien ficelés et un peu d'exercice au hacker amateur. La sécurité informatique est un mode étrange dans lequel seuls quelques gars pointus savent comment craquer tel protocole ou application, mais ou l'outillage met cette connaissance entre les mains de tout le monde. C'est un peu l'arme atomique numérique à la portée de tous les Docteurs No du coin.
Dans le cas de gMail il suffit de configurer son compte pour n'être accessible qu'en HTTPS. Combien d'entre nous ont cette option activée ? Dans mon cas elle ne l'était pas (aucune des options n'était cochée, je ne sais pas quel comportement par défaut s'applique dans ce cas).
Reste que ce genre de vidéo, avec la petite musique à la benny hill, montre à quel point la sécurité d'un réseau est à la merci de quelques outils bien lêchés et surtout à quel point on y es peu sensibilisé. On trouve sans chercher bien loin des distributions Linux en live-CD toutes prètes pour attaquer un réseau avec la panoplie complète du petite Ethan Hunt amateur. Et quand on parle sécurité avec un développeur on peut être surpris de la méconnaissance totale du domaine et de ses implications. Demandez juste pour rigoler ce qu'est un DOS (non, pas celui de Microsoft) ou un XSS...
Pour ceux qui auraient raté l'info, en 2007 l'Estonie a été numériquement paralysée (un comble pour un pays qui a tout misé sur le Net) - tout ça pour une histoire de statue déplacée. Un reportage d'Arte sur le sujet suggère que l'attaque provenait non pas des services secrets Russe ou mais de quelques hackers isolés qui ont "protesté" contre une décision en apparence mineure du gouvernement Estonien. Rapidement revenus à des activités plus lucratives ceci expliquerait que l'attaque se soit arrêtée après quelque jours sans que les spécialistes Estoniens aient réussi à faire quoi que ce soit. Comme quoi quelques gars bien outillés et pas manchots peuvent faire bien plus que vous piquer votre compte gMail.
Tiens, une idée pour le prochain concours de développement sur Androïd :
Une appli qui cracke automagiquement toutes les connexions Wifi, WEP ou WPA qui trainent, et permettent ainsi de surfer "gratos et anonyme". Les briques de base existent pour le faire (vous croyez être l'abri ? désolé) reste à en faire une belle appli pour neuneu avec un gros bouton bleu "Connect to Internet"
13 juin 2009
extrem feedback device
Le contexte :
- un bon gros projet (50 personnes * 16 mois),
- un approche "V" pas du tout agile (déjà plus d'un an de conception dans les pattes), ce qui n'interdit pas d'emprunter aux méthodes modernes quelques bonnes pratiques,
- une équipe hétéroclite, avec de nombreux "juniors", regroupés dans 5 équipes par couche technique - sensées collaborer ;) - et des buils Hudson FAILED à tour de bras.
Les piqures de rappel n'ayant pas données de résultats très convaincants, surtout que je suis loin d'être un bon exemple, je voulais expérimenter une approche plus ludique : le feedback visuel
"Extreme feedback device" : trois lampes qui illuminent le couloir pour indiquer l'état du build - difficile de passer à côté et de faire l'indifférent. Un truc comme ça :
La commande se fait depuis le PC via le port parallèle - je sais, les PC modernes n'on plus cette relique du IBM PC, mais ici on a pas encore reçu les nouveaux core i7 triple channel, on doit se contenter ne nos Lenovo un peu asfixiés par Eclipse :)
Le port parallèle, programmé au plus bas niveau, a l'intérêt bien connu des bidouilleurs de se comporter comme un "octet exposé au reste du monde". Ses 8 pins sont contrôlables en 0V / 5V en fonction du byte inscrit sur ce port. Il est donc facile de piloter jusqu'à 8 lampes en y envoyant de 0 à 255.
1er soucis
Le "plus bas niveau" est un peu compliqué sous Windows ou le port parallèle est masqué par l'abstraction matérielle. Il existe cependant des drivers bidouille qui corrigent le tir, ainsi qu'un soft qui assure l'accès exclusif à ce port (sans quoi ça merde de temps en temps).
- le soft qui va bien pour écrire byte par byte sur le port parallèle en Java
- le soft qui va bien pour un accès exclusif sous windows
Un premier "proof of concept" pour allumer une led rouge (en ce moment c'est la couleur dominante) et mettre au point le côté logiciel, basique mais fonctionnel. L'occasion aussi d'amuser la galerie et de préparer l'équipe pour la suite.
Une fois cette formalité remplie et les premier regards amusés des collègues, on sort le fer à souder. Liste de courses :
- un vieux cable d'imprimante "centronics" (comme quoi faut jamais rien jeter)
- quelques composants électroniques (~20€)
- trois ralonges (pour pouvoir placer les lampes à qq mètres de mon bureau),
- une boîte tupperware pour mettre tout ça à l'abris - c'est tout de même du 220v, faut pas déconner.
2ème soucis
Ce premier essai est un bide : rien ne marche. J'ai d'abord cru avoir grillé les optocoupleurs (c'est tout de même du 220V, on hésite à venir y mettre ses doigts). En fait le montage que j'ai voulu utiliser suppose que la prise parallèle débite suffisement de jus ... ce qui était loin d'être le cas au cous de mes essais. Il faut donc ajouter un "étage" suiveur de tension - ressortez vos cours d'électronique sur les transistors ! Dans ma boîte à bricoles j'ai retrouvé tout plein de ces bidules à trois pattes, l'occasion de (re)découvrir à quoi ça sert.
Après un test sur plaque d'essai (attention au 220V :-/) implantation sur circuit imprimé et mise en boîte.
3ème soucis
On branche et ... les plombs sautent. Après une bonne heure à tester chaque module sans trouver de problème, je décide de couper le circuit en deux sous les opto-coupleurs, de manière à avoir une isolation totale entre 220 et 9V - et ça marche. Comme quoi ma plaque d'essai ne devait pas être au top question isolation.
Je vous passe les 4ème, 5ème et 6ème soucis (la LED qui s'allume pas, un fil de masse qui se déssoude ...)
Pour les "signaux visuels" vous pouvez ressortir ces blocs-spots octogonaux en plastique qu'on a tous achetés un jour pour animer une boum - ça peut vous faire un joli feu de signalisation. Moi, j'ai fait une petite folie :
- trois tubes néons de couleur bleu/jaune/rouge (19€ chez alinea)
- un gyrophare rouge pour venir épauler le tube rouge (16€)
et voilà le résultat en action :
Le "Laser Saber Extreme Feedback Devive (TM)"
Pas de photo ? Ben non, j'ai oublié mon appareil, revenez en fin de semaine ...
Effet étonnant : le jour de l'installation, 12 builds bleus alors qu'on plafonnait péniblement à un ou deux par jours au meilleur de notre forme. Pourvu que ça dure !
Autre option pour ce type de montage, utiliser un circuit programmable, comme par exemple celui-ci qui intègre sur quelques cm² un serveur HTTP avec sa prise ethernet. Mais là, ça devient presque de l'industrialisation. Le côté bricolage facilite le succès du bidule auprès de l'équipe ;)
09 juin 2009
Pour une meilleure utilisation d'Eclipse
Julien vient de me suggérer le plugin MouseFeed, qui suggére les raccourcis clavier pour chaque opération pratiquée à la souris dans l'IHM, souris bien pratique mais dont la lenteur relative est bien connue. Un excellent moyen pour apprendre les raccourcis (parfois même leur existence) sur les opérations qu'on pratique en boucle.
Il ne manque plus que le petit trombone animé pour nous tenir la main ;)
03 juin 2009
Sun, Oracle, OpenJDK et Java payant ?
Le rachat de SUN par Oracle a fait couler beaucoup d'encre et lève de nombreuses interrogations (voir inquiétudes). Dans ce contexte, on peut être rassuré que SUN ait passé le code du JDK sous licence GPL peu de temps avant ce changement de propriétaire.
Exemple concret : le nouveau Garbage collector "G1", dont les performances sont encourageantes pour ce qui en a déjà été présenté (même si on présente rarement de mauvais résultats). Un petit tour par la release-note :
"Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased. G1 is supported thru Sun's Java Platform Standard Edition for Business program."
Vous avez bien lu, pour utiliser G1 en production vous devrez passer par le porte monaie et souscrire un contrat de support "business program".
Donc SUN a d'un côté ouvert le JDK en GPL (ce qui lui permet à la fois d'être libre sans risquer de se le faire piquer) et de l'autre finance des développements plus avancés selon un contrat de support classique. Un modèle de développement opensource assez classique en fin de compte, la version "de base", libre, servant à faire adopter la plateforme tandis que la version "business" est orientée support et fonctionnalités avancées.
D'autres éditeurs ayant choisis ce modèle redonnent leur code "avancé" à la version libre une fois que son développement a été amorti. Il semble que ce soit l'idée de SUN pour G1, dont le développement et la mise au point sur des applications stratégiques nécessite des ressources significatives.
Reste à savoir ce que cela va donner à l'avenir, avec bien sûr la question clé de la position d'Oracle sur le sujet, qui n'a pas montré jusqu'ici un engagement fort dans l'opensource. G1 sera t-il réellement "libéré" et intégré à OpenJDK ou faudra t-il attendre un développement alternatif qui s'en inspire ? Qu'en sera t-il des autres évolutions significatives du JDK de sun ?
La polémique autour du rachat de SUN n'est pas prète de s'épuiser ;)
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 ;)
01 juin 2009
container's hell
JEE n'a pas vraiment la cote auprès des développeurs qui lui préfèrent des modèles plus léger. Dernière expérience en date pour ma part : j'ai une application Hibernate, j'y ai mis la toute dernière version GA du framework, et je la "déploie"sur un JBoss un peu ancien - prérequis client oblige.
NoSuchMethodError
Hibernate tente de détecter la présence de Hibernate-validator, et si c'est le cas active ses fonctions optionnelles. JBoss a eu la bonne idée de nous coller d'office un Hibernate dans son serveur d'appli, comme si nous n'étions pas capable de choisir nous même nos outils. Le Hibernate-validator détécté au runtime est celui de JBoss et évidement incompatible avec la version d'Hibernate que j'utilise.
Autrement dit, le "conteneur" me rend là un magnifique service en m'obligeant à intégrer une version plus récente d'Hibernate-validator que je n'utilise pas. Je vous passe les problèmes de parser et d'API XML et les diverses Error associées. Même si après tout c'est ce qui me fait gagner ma croute vu que peu de gens comprennent de quoi il s'agit, je me passerais bien de perdre des heures sur ce genre de sotises.
Question 1 : pourquoi le serveur d'appli devrait-il nous fournir des frameworks, nous privant ainsi du choix d'une version précise ? Il est difficile de faire une mise à jour de serveur sur des machines mutualisées, je me suis coltiné un Websphère 5.0 pendant des années pour cette raison.
Question 2 : Pourquoi le classloader isolé (parent-last) n'est-il pas le mode de fonctionnement par défaut ? Tous ceux qui ont galérés avec commons-logging savent de quoi je parle
Question plus fine : pourquoi le serveur d'appli héberge t-il l'application et pas l'inverse ?
Dans la majorité de mes applis, en dehors de l'API servelt et d'une DataSource le serveur d'appli ne sert pas à grand chose (je suppose que ces fonctions d'exploitation sont mise à profit par mon client). Pour la DataSource, un bon commons-dbcp fait très bien l'affaire et économise les raffinements de la configuration des liens JNDI. Pour l'API servelt, je préférerais autant démarer au sein de mon application un service d'écoute HTTP, un Jetty embedded ou équivalent, quitte à ce que la classe associée soit configurable.
Spring DM Server de ce point de vue me décoit un peu car il ne remet pas en cause cette structuration des applications dans un conteneur (et je reste perplexe sur l'intérêt d'OSGi). J'attendrais du serveur d'application idéal de fournir des services à la carte, mais surtout rien de plus. En gros une JVM++, pas une de ces usines à gaz auxquelles JEE nous a habitués.
29 mai 2009
Google surfe sur la Wave
Pour ceux qui ont suivi l'émergence de HTML5, les navigateurs modernes vont permettre de développer des applications nettement plus riches, basées sur un canevas graphique complet et un modèle de communication complètement débridé (très loin de deux connexions HTTP que l'on a héritées de Mosaïc).
Google suit (anticipe ?) le mouvement en présentant Google Wave, qui se présente comme "ce que seraient le mail et la messagerie instantanée si on les avait inventés aujourd'hui". Ça parait flou ? Explication, basée sur la démo présentée au Google IO :
On part de ce qui ressemble pas mal à gMail, avec liste de contacts et boite de réception. Sauf que pour chaque personne impliquée dans une discussion, Wave signale de nouveaux événements ou contenu (pas juste de nouveaux messages). A l'intérieur d'une discussion on retrouve donc les outils de messagerie instantanée, de partage de profil et autres services "sociaux" devenus communs sur le web. Plutôt que de répondre à un message, on vient en compléter le contenu avec un complément apporté directement à l'original - on est alors à la limite de Google Docs.
Wave est donc en quelque sorte une fusion de tout ce qu'on trouve de collaboratif sur le web. Sur la base d'un sujet, on va inviter de nouveaux participants qui vont enrichir le contenu, ouvrir des discutions (globales ou privées), communiquer on- ou off-line et construire ensemble quelque chose de riche via un environnement unifié.
Subtilité indispensable, la possibilité de "rejouer" l'évolution de ce contenu dans le temps pour retrouver son état à un instant t, bien plus efficace que de remonter l'historique de ses mails !
Réservé à l'échange de document ? Que nenni, la démo présente une partie d'échec, l'échiquier étant le "contenu" partagé sur la Wave ! Autre exemple, une invitation à un barbecue ou chacun donne sa disponibilité. Les utilisations concrètes restent à inventer.
Tout ça ... dans n'importe quel navigateur digne de ce nom (donc n'importe lequel sorti en 2009 à l'exception d'IE qui reste comme toujours l'indécrottable poubelle du web). Pas de plugin, pas de siouxerie, et rapidement on met le navigateur en plein écran pour ne plus en sortir.
Le protocole utilisé par Google Wave est ouvert (http://www.waveprotocol.org/) et les données peuvent ainsi être hébergées sur vos propres serveurs -détail qui freine sensiblement le développement du cloud-computing !
[mon voyant me prédit l'avenir:ON]
Une idée comme ça pour tout ceux qui ont pesté sur les lenteurs d'Eclipse : imaginez une appli utilisant Wave comme éditeur de code, avec le "cloud" comme compilateur en tâche de fond ! J'écris du code, je convie Michel et Julien pour une relecture, je fais du Pair-programming en télétravail, je reviens à la version d'hier matin ... Une sorte de TeamCity poussé jusqu'au PC. Le poste de développement reste la seule (bonne ?) raison de conserver un PC surpuissant. A quand l'environnement de dev distribué ?
[mon voyant me prédit l'avenir:OFF]
A noter dans la même lignée la version Cloud de gOS (le "g" signifiant "good", et pas "google" comme on est très tenté de le penser) qui veut construire un OS ultra allégé (comprendre : net-PC) qui ouvre seulement un navigateur en plein écran contenant toute l'IHM en mode web - "browser operating system".
Quand on vous dit que la révolution du web est en marche...
28 mai 2009
Continuum vs Bamboo vs Hudson
Petit retour d'expérience sur les serveurs d'intégration continue.
J'utilise beaucoup Hudson, qui a le vent en poupe. Interface ultra-conviviale, nombreux plugin et communauté très active. Les builds Maven2 sont découpés en modules automatiquement détectés, ce qui permet de consulter l'état d'un module en particulier. Par contre, le build reste monolithique, c'est à dire qu'Hudson fait un build complet même si un seul module est impacté.
Bamboo est le seul non-opensource de mon test. J'en avais entendu beaucoup de bien, je reviens plutôt déçu. L'interface est très correcte mais l'intégration de Maven est minimale : aucune gestion des modules, ni au build, ni à l'affichage. Par ailleurs, j'ai eu un peu de mal à m'y retrouver dans les onglets, mais c'est sans doute une question d'habitude.
Continuum est le plus moche des trois. L'IHM est vraiment old school et mériterait une belle refonte à grand coup d'Ajax et de styles graphiques plus modernes. Par contre, le support de Maven est sans compromis : chaque module d'un multi-projet est identifié comme tel et géré comme tel. Si une modification impacte un sous-module, celui-ci (et seulement celui-ci) est construit, puis Continuum enchaîne les modules ou autres projets qui en dépendent - ce qu'on attend d'une gestion des dépendances Maven !
Ma conclusion : Hudson est un bon environnement, surtout pour commencer avec l'intégration continue car il est très intuitif. Bamboo n'apporte pas de plus value fondamentale et son support Maven est décevant. Continuum est probablement le meilleur serveur d'intégration continue pour un projet Maven, mais également le moins esthétique et le plus complexe des trois à configurer. Le jour où il sort avec une IHM revisitée et une configuration en trois clics, il risque de déchirer -mais ce n'est qu'une conjecture, encore faut-il trouver les développeurs pour faire le boulot :)
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.
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 :)
18 mai 2009
m2eclipse vs IAM ? Non m2eclipse + IAM
Lorsque la fondation Eclipse a annoncé accepter deux plugins concurrents et assez semblables dans son incubateur on pouvait se poser la question : qui va survivre à la course à l'investiture ?
On aurait pu penser que Eclispe serve de "sélection" pour un unique plugin et encourage le perdant à coopérer, mais il n'en est rien. La fondation a d'ailleurs joué le même tour à Sublcipse / Subversive.
Nous avons donc d'un côté IAM qui fait un gros boulot (peu visible) pour bien rentrer dans les règles de l'incubateur et m2eclipse qui continue son développement et enchaine les pré-versions. Les discutions qu'on a pu suivre entre les deux groupes ne laissaient pas vraiment présumer d'une fusion. Après une gueguerre "c'est pas moi m'sieur, c'est lui qu'a commencé", on nous a expliqué en quoi les deux plugins sont fondamentallement différents et donc ne peuvent céder un pouce de terrain.
Et voila que l'impensable se produit : Michael Poindexter (q4e) travaille actuellement sur la fusion des éditeurs de fichier POM proposé par chaque plugins. Il vient même d'obtenir le sésame utlime : le droit en écriture sur le code de m2eclipse - ce qui doit être nettement plus simple pour faire la fusion :).
On assiste donc à un assainissement de la concurrence entre les plugins, qui sont encore loin de n'en faire qu'un (il reste de lourdes incompatibilités) mais commencent à réfléchir ensemble.
Un peu d'optimisme fait du bien :D
15 mai 2009
m2eclipse vs IAM (q4e)
Après avoir publiquement rennoncé à Archiva pour Nexus on pourrait me croire vendu à Sonatype ... et bien non. Utilisateur de m2eclipse je teste actuellement la dernière mouture de eclipse-iam (aka "q4e") et je le trouve bluffant !
- le build maven est nettement mieux intégré.
- moins de builds inutiles
Si je trouve le "visuel" de m2eclipse plus sympa, voilà deux bonnes raison qui vont me pousser à changer mes habitudes
14 mai 2009
La fin d'une époque
L'époque ou le monde opensource était associé à des universitaires barbus en tongues (et chaussettes, c'est plus confortable) semble loin derrière nous.
Nous sommes quelques un à bien devoir admettre que notre projet à nous, développé en mode "temps libre" a bien du mal à tenir la route face à la concurrence. Archiva est bien joli mais est à la ramasse comparé à Nexus, et la liste de tâche pour le "moderniser" est tellement longue, que je vois mal qui pourrait s'y attaquer. Continuum est tout à fait fonctionnel, mais son ergonomie laisse à désirer comparé à Hudson ou Bamboo, sans parler de la richesse du premier en terme de plugins.
D'où un constat simple : depuis que le modèle opensource n'est plus considéré comme opposé au business, de nombreuses boîtes peuvent mettre du monde à plein temps sur un projet ET en tirer du bénéfice (support, consulting, formation, version "pro", etc).
Nous sommes quelques un à bien devoir admettre que notre projet à nous, développé en mode "temps libre" a bien du mal à tenir la route face à la concurrence. Archiva est bien joli mais est à la ramasse comparé à Nexus, et la liste de tâche pour le "moderniser" est tellement longue, que je vois mal qui pourrait s'y attaquer. Continuum est tout à fait fonctionnel, mais son ergonomie laisse à désirer comparé à Hudson ou Bamboo, sans parler de la richesse du premier en terme de plugins.
D'où un constat simple : depuis que le modèle opensource n'est plus considéré comme opposé au business, de nombreuses boîtes peuvent mettre du monde à plein temps sur un projet ET en tirer du bénéfice (support, consulting, formation, version "pro", etc).
Comment l'équipe d'Archiva pourrait-elle rattraper Nexus, qui bénéficie de l'équipe Sonatype à plein temps ? Comment Continuum peut-il rivaliser en terme de ressources avec un outil commercial comme Bamboo ou un Hudson dont le créateur à été affecté à plein temps par SUN ?
L'opensource du XXIéme sciècle est définitivement professionnel.
Archiva vs Nexus
En écho au blog d'Arnaud, j'ai moi aussi envisagé la migration d'Archiva vers Nexus.
Pour résumer, Archiva à rencontré avec la sortie de maven 2.1 un bug bloquant (une sombre histoire de metadata.xml qui se perdent en route). D'où obligation de migrer, serveur qui ne démarre plus, réinstallation de la base, bugs divers à répétition [ NullPointers :'( ]...
Ca ne donne pas une super image de l'état de stabilité d'Archiva. A l'usage, je n'ai pas rencontré de problème particulier et je n'ai pas non plus instrumenté mon serveur comme l'a fait Arnaud pour évaluer la consommation des ressources. Il est possible que certains de mes soucis soient liés à la consommation excessive qu'en fait Archiva.
Bref, déploiement du WAR Nexus et configuration en quelques minutes (l'IHM d'admin est tout de même nettement plus sympa, même si on y passe pas des heures). Mes premiers tests montrent que Nexus est "au moins aussi bien" qu'Archiva. Certains problèmes de timeout ont même été éliminés.
Dans un premier temps je vais conserver les deux "repo-managers" en parallèle, et laisser l'instance Archiva mourrir tranquilement de sa belle mort (on a encore pas mal de projets Maven1 qui se basent dessus !)
07 mai 2009
javax.inject - enfin !
L'injection de dépendance aura marqué ces dernières années :
- Apache Avalon et dérivés ont montrés la voie, même s'ils étaient sans doute un peu trop précurseurs et largement sous-documentés ;
- Spring a enfoncé le clou et définitivement imposé l'idée grâce à une documentation rarement égalée dans le monde opensource et aux qualités de pédagogue de son créateur ;
- Google Guice a marqué une étape en proposant une solution légère basée sur les annotations ;
- JBoss ne s'y est pas trompé en renommant "sa" JSR299 de Web beans en Java Context and Dependency Injection
Comment éviter d'être lié à un framework donnée ? Via une spécification officielle Java (JSR) !
La JSR299 a cet objectif mais ne remporte pas les suffrages. Ni Google Guice, ni SpringSource n'ont répondu à l'appel ... et on sait enfin pourquoi : Google Guice et SpringSource collaborent à l'élaboration d'une nouvelle JSR, permettant en théorie de passer de Spring à Guice au runtime sans toucher à votre code.
Malgré ses limitations, j'étais jusqu'ici un défenseur de l'injection via l'annotation @Resource (jsr250). Bien que supportée uniquement par Spring (et les EJB3) elle avait au moins l'avantage d'être non liée à un framework. Avec cette nouvelle JSR, on aura donc un moyen de spécifier clairement l'injection de dépendance sans se lier à un framework et une réelle alternative au runtime.
Quel intérêt ? Après tout, c'est vraiment rarissime de passer une appli de Spring à Guice juste pour le fun ! Pensez aux frameworks et bibliothèques, qui vont pouvoir exposer leurs composants et dépendances via cette API. C'est déjà le cas pour l'écosystème Plexus, et j'ai développé une passerelle pour pouvoir les utiliser dans un contexte Spring, mais ça reste du bricolage.
A l'avenir, on pourrait donc imaginer récupérer une bibliothèque utilitaire de type "accès à Google Map en Java" utilisant cette JSR et pouvoir l'exploiter depuis Spring ou Guice sans intermédiaire. Un retour des composants de haut niveau "sur étagère" ?
06 mai 2009
Un Leopard dans mon XP
Vu que personne ne veut m'offrir un beau MacBook 17 pouces, j'ai bricolé mon bon vieux Windows XP avec un BricoPack pour le rendre "MacOS Leopard-like". La solution du pauvre, c'est vrai, mais c'est mieux que rien.
Découverte intéressante qui en dit long sur Windoz : l'économiseur d'écran "Flurry" en version Win32 est ultra lent sur ma machine - la faute au chipset Intel Graphics. En renommant le fichier flurry.scr en flurry.sCr (subtil !) ça devient tout à fait fluide.
Windoz est vraiment un système étonnant, qui nous promet chaque jour une nouvelle surprise !
compile, compile pas
Je rencontre un problème jusqu'ici innexpliqué sous Hudson :
Je suis tombé sur ce qui semble bien être un bug "rigolo" :
Voici la description de la classe WebParam (définie par la spec JAX-WebServices) sur un poste Windows :
[INFO] Compilation failure
/home/hudson/.hudson/jobs/bios/workspace/bios/bios-prise-de-commande/bios-pdc-remoting/target/generated-sources/cxf/com/sfr/pates/PaymentQueryManager.java:[26,18] cannot find symbol
symbol : method partName()
location: @interface javax.jws.WebParam
Je suis tombé sur ce qui semble bien être un bug "rigolo" :
Voici la description de la classe WebParam (définie par la spec JAX-WebServices) sur un poste Windows :
javap -classpath jsr181-1.0.jar javax.jws.WebParamLa même commande, passée sur Hudson (Solaris) :
Compiled from "WebParam.java"
public interface javax.jws.WebParam extends java.lang.annotation.Annotation{
public abstract java.lang.String name();
public abstract java.lang.String partName();
public abstract java.lang.String targetNamespace();
public abstract javax.jws.WebParam$Mode mode();
public abstract boolean header();
}
javap -classpath jsr181-1.0.jar javax.jws.WebParamPas de partName :'(
Compiled from "WebParam.java"public interface javax.jws.WebParam extends java.lang.annotation.Annotation{
public abstract java.lang.String name();
public abstract java.lang.String targetNamespace();
public abstract javax.jws.WebParam$Mode mode();
public abstract boolean header();
}
En gros, la librairie de référence jsr181 que j'ai récupérée est bugguée ... D'ailleurs, elle n'est pas dispo dans le repo maven "central" et le lien dans le POM Maven est cassé - il pointe vers leserveur d'un certain "BEA" :p. Délicat donc de savoir où aller la chercher !
Il existe heureusement une alternative via les jars du serveur Geronimo. J'ai aussi ajouté dans le build Maven un contrôle sur les dépendances qui permet de vérifier qu'on embarque pas cette jsr181 récalcitrante.
01 mai 2009
Retour à la case départ
Mon écart de langage envers le fondateur de Maven n'aura pas eu un grand effet. Quelques autres développeurs ont pris position (de manière plus "diplomate") mais les choses ne bougent pas pour autant.
En résumé :
1. Je me suis pris dans la face un "tu n'as committé que trois fois, et tout ce que tu as fait a du être rollbacké" - ça c'est pour me remettre à ma place.
2. "Maven c'est compliqué, c'est normal qu'on y comprenne rien à moins de s'y mettre à fond". C'est une certaine vision de l'informatique qui s'exprime, je comprend qu'on ait du mal à se mettre d'accord en partant sur cette base.
3. "Va faire mumuse sur maven 2.x, de toute façon l'avenir c'est Maven 3". En un sens c'est presque rassurant, on va au moins pouvoir sortir des versions de maven 2 sans devoir attendre deux ans que ce soit prêt - c'est déjà assez compliqué comme ça !
J'ai bien proposé de rennoncer à mon accès SVN sur Maven si mon état d'esprit ne collait pas avec la "ligne du parti", mais ça ne change pas grand chose. Ce droit sur le trunk ne me sert de toute façon à rien vu que je n'ai tout simplement plus aucune idée de ce qui s'y passe.
Nous en restons donc là, et je vais effectivement essayer de participer plus activement à Maven 2.2. Reste que le développement des plugins Maven reste le moteur le plus significatif pour une grande majorité des committers, et certainement ce que les utilisateurs suivent / attendent le plus. Après tout, maven-core ne fait qu'exécuter ces plugins, peut importe s'il utilise le top-du-top de l'injection de dépendances !
Inscription à :
Articles (Atom)
