new Blog( perso );

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.

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 :)

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é.

Contrairement à m2eclipse, IAM utilise maven 3 exclusivement, ce qui peut paraître gênant à priori mais lui donne la liberté d'une vraie intégration dans Eclipse et sa gestion événementielle. La progression d'un build indique ainsi le démarrage des Mojos et les tâches accomplies.

moins de builds inutiles

L'éditeur de POM est assez intelligent pour ne pas lancer un build "pour rien" lorsque l'édition réalisée n'a aucun impact. Je râle assez souvent sur m2eclipse qui me fait des builds en série pour pas grand chose, et je finis souvent par désactiver le "build automatically".

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).

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

sans parler des outsiders que j'oublie probablement... Bref POJO et injection de dépendances deviennent les éléments incontournables de toute bonne architecture moderne.

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 :


[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.WebParam
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();
}

La même commande, passée sur Hudson (Solaris) :

javap -classpath jsr181-1.0.jar javax.jws.WebParam
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();
}

Pas de partName :'(

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 !

27 avril 2009

Différentes façons de faire de l'opensource

Pour ceux qui auraient raté mon précédent billet, voici une petite explication de texte : il y a de nombreuses façons de faire de l'open-source.

Prennons d'abord la fondation Apache - si on se réfère à la doc de l'incubateur :

The minimum requirements that a Podling SHALL meet prior to being graduated to the ASF are :

(...)

Demonstrate an active and diverse development community
The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)

Pour faire court, la Fondation Apache considère qu'un projet open-source est surtout porté par une communauté diverse et active. La qualité intrisèque du code a peu d'importance s'il n'y a pas du monde motivé derrière.

Passons maintenant à CodeHaus :

The Codehaus recognizes that some committers, based upon metrics, longevity and appointed management, have greater say on a project than others
The Codehaus places a high bar on entry for projects
In case of disagreement, The Despots are right

Ici la phylosophie est très différente : un projet opensource se doit d'être bien ficellé, production-ready, et supporté par des développeurs talentueux. Pas forcément "des" développeurs d'ailleurs.

On a donc deux approches très différentes. Apache favorise l'approche communautaire. Les commons-* en sont la meilleure démonstration, certains composant dormant depuis de longues années dans le bac à sable. Codehaus préfère l'excellence technique, quitte à passer par ce qu'ils appellent sans nuance des "despotes"

Qui a raison ? Les deux mon capitaine ! L'opensource est un monde varié, les deux approches ont abouties à des outils remarquables, le tout est de ne pas se tromper d'adresse.

25 avril 2009

Do you have a Mac ?

The GWT-maven-plugin developement is going well and I expect a 1.1 release soon. Still have to fix some issues, check the docs and provide more samples.

I'm now building a IT-test harness to check I don't break things anymore when changing code.

The last "oups, I broke the plugin" is related to running GWT-SDK tools on Mac. I don't have one myself so can't test on this platform.

If you want to support the gwt-maven-plugin, please lend me a Mac Book or Mac mini (low-cost Mac, if 600€ can be considered "low"). If your company want's to support the plugin I'd be pleased to add a sponsoring link on the plugin site.

--> mailto:nicolas@apache.org

22 avril 2009

OPA hostile sur Maven

Notre bon amis Jason, quelques soient ses mérites, à la fâcheuse habitude d'avoir des idées très arrêtées et de les imposer par le fait accompli.

On a eu le droit au développement concurrent d'Archiva et Nexus, le premier - plan de longue date de la communauté maven (cf wiki et mailing list), le second - projet perso de Jason & Friends
On a eu droit à XBR sur maven3 pour remplacer Plexus (vous ne connaissez ni l'un ni l'autre ? comme c'est étrange !)
On a eu droit à la refonte complète du mécanisme de transport de Maven (wagon) par l'équipe de Jetty (-> mercury) sans avoir eu le temps d'en discuter sur la liste dev avant que ce soit déjà en place. C'était peut être utile, voir nécessaire, mais on pourrait en causer un peu avant, non ?
J'ai même eu droit à un mail perso de Jason (on est super pôtes) pour me proposer d'intégrer le plugin GWT à la Sonatype forge - quel honneur !

J'en rate probablement, vu que je ne suis pas au courant de tout (c'est pas facile à suivre), mais nous sommes nombreux à nous être (poliement) accroché avec le Monsieur et à baisser les bras.

Dernier fait d'arme en date, Eugene Kuleshov, développeur émérite de m2eclipse , vient de se faire sortir à coup de pied au c... du projet qu'il soutiens depuis 5 ans. Sans doute n'avait il pas le profil assez "lisse" pour se plier aux idées du "reste de l'équipe" qu'il perturberait (?). Ca doit faire très mal à l'égo, je n'aimerais pas être à sa place.

On arrive donc de plus en plus clairement à un putch en règle sur la direction de l'écosystème Maven, certes par son créateur, mais très loin de l'esprit d'un logiciel communautaire - règle de base de la fondation Apache !

Je crois (encore) au potentiel de Maven, même si les promesses de maven 3 semblent très très très lointaines (depuis le temps qu'on l'attend), mais cette attitude me fait franchement douter. Maven va rapidement souffrir des reproches qu'on peut entendre sur Spring ou JBoss, accusés d'être des projets opensource "fermés". Le développement commence à se faire presque exclusivement sous le contrôle de Sonatype, à quand un "Maven Pro" payant intégrant des extensions propriétaires ?

A ce rythme je vais finir par revenir au bon vieux Ant et son pôte ivy.

20 avril 2009

Sun racheté par Oracle

J'apprend juste l'achat de SUN par Oracle. IBM s'est donc fait couper l'herbe sous le pied.

Reste à savoir ce qu'Oracle va faire de sa nouvelle acquisition. Depuis le rachat de BEA par exemple, il est devenu impossible de télécharger la JRockit, JVM réputée de l'ex-BEA. Les pages téléchargement existent toujours mais plus de liens... sauf peut être à avoir un compte support Oracle.

Difficile de prédire quelle orientation Oracle va donner, et en particulier comment la partie "soft" va s'en sortir. Oracle continuera t-il à investir dans des projets comme NetBeans ou GlassFish ?

18 avril 2009

Appengine Java ... réfractaire à Maven !

En tentant de "Mavenizer" le SDK Java d'AppEngine, je tombe sur de nombreuses librairies du SDK qui ne collent pas aux artefacts Maven (somme md5 différente) :

commons-el, commons-logging, jasper-compiler, jasper-runtime, jstl, standard, ant, ant-launcher

rien que ça !

Une petite recherche me fait découvrir une classe de commons-el dont la taille binaire est différente entre les deux JAR. Google aurait-il eu besoin d'adapter ces classes pour son runtime ? Après décompilation : aucune différence !?

Première hypothèse : Google a recompilé lui-même ces librairies. Pourquoi pas, mais ça parrait un drôle d'idée.

Seconde hypothèse : Google a eu besoin de modifier ces classes, non pas dans leur code source mais dans leur structure bytecode. Après tout, le runtime AppEngine a de grande chance de ne pas utiliser une JRE SUN classique, mais plutôt un JVM Dalvik déjà maîtrisé par Google puisqu'elle est au coeur d'Androïd - mais ce n'est que pure spéculation !

Troisème hypothèse : Goole a pris des jars qui trainaient sur un coin de table (ou de disque dur), de toute façon ils n'ont rien compris au problème des dépendances Maven et s'en tappent : ils ne l'utilisent pas (même problème avec GWT-dev). Hypothèse la moins avantageuse car dans ce cas on est pas près de savoir si on peut utiliser les JAR "standard" du dépôt Maven sans risque.

Quatrième hypothèse : Google n'aime tellement pas Maven (il n'y a qu'à voir combien de ses projets majeurs l'utilisent) qu'ils ont décidé de tripatouiller les JARs juste pour nous emmbêter. Un complot mondial je vous dis !

Dernière hypothèse : Jason (Van Zyl, Mr "j'ai créé Maven") a voulu s'assurer l'exlusivité d'un plugin GAE, augmentant ainsi sa mainmise sur l'écosystème Maven. Il a donc collaboré avec Google (dont les bureaux sont voisins) pour s'assurer que ceux qui ne sont pas dans le secret ne s'en sortiraient pas.

Dans tous les cas, il va falloir patienter encore pour avoir une première SNAPSHOT d'un plugin GAE ... ou alors tenter le coup avec les artefacts "officiels" Maven pour voir.

16 avril 2009

breizhjug channel

Annoncée depuis décembre, avec des démos à n'en plus finir de nous allécher, parleys.com se prépare d'ici une semaine à ouvrir une "private beta" de son publisher, qui permettra de monter et diffuser une présentation vidéo/slides sur le site que vous connaissez déjà tous (!)

Pour avoir testé la précédente bêta en octobre, la nouvelle mouture s'annonce fantastique (par rapport à un montage manuel qui est ultra pénible).

Cerise sur le gâteau, Stephan offre l'hébergement aux JUGs du monde entier, à croire qu'il à un super prix sur son accès Internet ;) Parleys va vite devenir la plateforme vidéo incontournable pour ce type de contenu.

Ajoutez à ça que Adobe vient de m'envoyer une suite complète CS3 production premium en cadeau pour avoir accueilli François en février, et ça vous donne une idée de mon occupation pour le week-en à venir (surtout si le temps se maintien...)

12 avril 2009

Maven @ PoitouCharentesJUG

Le PoitouCharentesJUG m’a invité pour son inauguration à venir présenter Maven. J’ai donc rencontré la communauté enthousiaste et accueillante d’une région que je connais bien pour y avoir fait mon service militaire et déniché ma moitié.

14^ème JUG français, le « bravitudeJUG » (surnom totalement non-officiel mais qui leur va si bien) est l’exemple d’une réussite : organisation sans faille, équipe motivée, public pointu, participatif et très chaleureux. Pour une première, qui plus est la veille du week-end de pâques, les 25 membres présents sont une preuve de la dynamique locale, surtout pour une session organisée en à peine 10 jours !

J’ai très largement débordé des 90 minutes qui étaient prévues pour la session, sans pour autant perdre qui que se soit en route. De très nombreuses questions ont été posées par un public mixte : le monde de l’entreprise rencontre ici les universitaires et le secteur public local – une diversité qui promet des échanges riches !

La vidéo et les slides de la session sont disponibles, en attendant que je puisse la diffuser sur Parleys.com. N’hésitez pas à contacter l’équipe du tout jeune PoitouCharentesJUG pour les encourager ou pour leur proposer votre collaboration. La prochaine session devrait être organisée sur Niort et portera sur les IHM, web (GWT) et desktop (Eclipse RCP). Encore une soirée riche en perspective ;)

09 avril 2009

Google Developer Day – community feedback

Google organisait jeudi en fin d’après midi une soirée pour présenter son AppEngine en version Java à la communauté et récolter un premier feedback. Didier Girard était de la partie, décidément toujours sur les bons coups :)

L'annonce, c'est bien sur Google App Engine for Java + GWT 1.6 + un plugin Eclipse.

Premier point, la plateforme est un pseudo tomcat tournant sur un Java6 « à la sauce Google ». Comprenez que certaines API Java sont blacklistées, soit parce qu’elles n’ont aucun sens sur le « cloud » (java.io.File par exemple), soit pour des questions de sécurité. Il n’est par exemple pas possible de lancer un Thread, et certaines pratiques de réflexion ne sont pas autorisées.

Ces petites limitations ont un gros impact sur les frameworks que nous pouvons utiliser. Guillaume Laforge a fait un gros travail d’analyse sur Groovy pour le rendre compatible (et accompagner ainsi l’annonce très relayée de Google). De nombreux autres frameworks ne sont apparemment pas compatibles. La liste des outils (in)compatibles reste bien sur à construire (je projette d'ailleurs de faire ma première appli AppEngine sur ce sujet).

Autre restriction, la « base de données » de AppEngine n’est autre que BigTable, l’espace de stockage géantissime de Google – et qui n’a rien à voir avec une base relationnelle. DataNucleus (l’ex JPOX) a été choisi pour fournir aux développeurs une approche JDO ou JPA. Bizarrement, c’est la première qui est mise en avant par les wizards et exemples du SDK. JPox était en effet un outil JDO de premier plan, mais la compatibilité JPA n’en est qu’une surcouche. Autre point, déjà JPA a tendance à nous faire faire des choses « pas très bonne au sens relationnel » car on a tendance à oublier trop facilement la base de données qui se cache derrière. Avec BigTable c’est encore pire, car il ne faut pas envisager de passer par des jointures. Autrement-dit, même API qu’en JEE « traditionnel » mais pas mêmes usages et bonnes pratiques !

Pour ceux qui ne veulent (ou peuvent) pas héberger leurs données en dehors de leur SI, Google propose une API « Secured Data Channel », une sorte de trou de souris dans votre Firewall, sécurisée en SSL, et permettant au « cloud » Google d’accéder à vos données. A priori raisonnable, mais ça sent tout de même le hack ;)

Tout ça fait beaucoup de restrictions me direz-vous. Bien sur, pour déployer sur AppEngine une appli « hello world » cela prend deux clics, et l’infrastructure Google peut alors prendre en charge des pics de charge faramineux sans qu’on ait rien eu à prévoir.

Quel est la cible de AppEngine for Java ? Pas les applications JEE, vu l’inconnue sur le bon fonctionnement des frameworks, et surtout pas en l’état vu la nécessité de repenser la persistance des données. Par contre, tout développeur qui fait du JEE au boulot se retrouve en terrain connu pour déployer son appli perso. Et c’est bien la cible de Google : plus d’applications = plus d’utilisateurs du web = plus de revenus. Vous qui n’arrivez pas à vous mettre à PHP, qui ne pipez rien à python, vous allez pouvoir faire votre petite appli Java avec les outils habituels, avec votre API JPA pour stocker des données, avec GWT 1.6 pour faire de supers applis Ajax sans rien y connaître, et publier tout ça sur le Net pour pas un radis. Et si jamais votre site de vente de schewing-gum usagé explose les scores en raison d’un Buzz incontrôlé, l’infrastructure Google tiendra le choc !

Vous cherchiez une solution de cloud-computing pour votre entreprise ? Attendez que AppEngine se stabilise - ou plutôt, qu’on apprenne à bien l’utiliser et que les frameworks évoluent en conséquence.
Vous cherchez à héberger votre idée de super appli délire que personne y avait pensé avant, AppEngine est pour vous ! Au mieux, vous allez lancer le nouveau YouTube, au pire, dans 2 ans, vous vous vendrez comme expert AppEngine à tous les cabinets de recrutement ;)

Surprise pour moi de ne pas voir dans le package Google Guice. Le marketing de Google ne semble pas chercher à pousser ce framework, cela aurait pourtant été une occasion sans équivalent.

Au passage, je prépare un chtit plugin Maven pour ceux qui ne veulent pas se contenter du plugin Eclipse proposé par Google : http://svn.codehaus.org/mojo/trunk/sandbox/google-app-engine-maven-plugin/

Merci à Didier de m'avoir transmit une invitaton pour cette soirée, qui a soulevé de nombreuses questions et beaucoup d'intérêt ;)

08 avril 2009

Google App Engine passe à Java 6

Après être resté chasse gardée des développeurs Python, Google App Engine passe à la vitesse supérieure en répondant à la demande numéro 1 : supporter Java !

Au programme : Java 6, Servlets, JavaMail, mais aussi JPA pour accéder au DataStore google. Autrement dit, la plateforme de rêve pour héberger nos applications Java / GWT ! Google propose même un plugin pour Eclipse afin de fournir un environnement clé en main.

http://code.google.com/intl/fr/appengine/docs/java/overview.html

Si on arrive à coller un Spring (ou plus probablement un Google Guice) là dessus, on pourra déployer sur App Engine la même application que sur notre serveur JEE :D

Il serait bon que Google s'intéresse plus à la JSR 299, qui portait au départ sur jBoss Seam mais c'est réorientée sur l'injection de dépendance. Elle permettrait de ne pas être lié à un framework particulié dans notre code. Les annotations proposées sont inspirées de Google Guice, autant dire un appel à peine voilé au soutien de Google - qui répond absent pour l'instant - et si celui-ci y va, SpringSource sera plus ou moins obligé de suivre (en tout cas, d'y réfléchir).

Je suis invité chez Google France demain soir pour discuter avec la communauté de cette annonce technologique phare (à moins qu'ils veuillent m'embaucher ?). Plus d'infos très bientôt donc !