new Blog( perso );

Petit retour d'expérience sur les serveurs d'intégration continue.

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

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 ?

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 !

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

En écho au blog d'Arnaud, j'ai moi aussi envisagé la migration d'Archiva vers Nexus.

L'injection de dépendance aura marqué ces dernières années :

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.

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.

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.

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. 

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.

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. 

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

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

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 (!)

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

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

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 !

Je serais vendredi prochain à l'inauguration du PoitouCharenteJUG pour y présenter Maven.

Vendredi dernier j'ai voulu sortir un peu de quatre jours à corriger des bugs en série pour réussir à faire passer le projet dans l'intégration continue Hudson. Le temps d'appliquer une correction, deux nouvelles boulettes appraissaient sous Subversion.

Sur ma toute belle appli d'en ce moment que j'adore nous gérons la persistence avec JPA. Comme je suis un grand fan de la testabilité par POJOs (ce qui est super original de nos jours), je préconise d'utiliser spring-test-context pour tester la persistence.

Les dernières stats d'utilisation des navigateurs web sont sans appel : IE6 décline face à IE7 et Firefox3 qui se partagent le marché en 50/50

Vous l'avez sans doute lu un peu partout, IBM pourrait bien s'offrir SUN. La crise aidant, les cours sont au plus bas et donc les rachats deviennent possible, même les plus innattendus.

Sur mon projet actuel, d'une taille assez colossale, tout (et même le reste) est configurable, si bien qu'il faut une appli de gestion de la conf qui à elle toute seule est déjà une belle appli web.

Dans le milieu des "architectes Java" on se targe d'appliquer des patterns, de structurer des architectures et d'offrir des applications flexibles, maintenables et évolutives.

Ce week-end j'organisais un "apéro Wii". On m'a donc gentillement prêté deux WiiMotes et un Wii Fit, et bien sur les jeux qui vont avec.

Les petits gars de GWT, n'utilisant pas Maven, sont confrontés à une armée d'utilisateur qui se casse les dents à faire fontionner ensemble les deux outils. En tant que développeur du plugin Mojo gwt-maven-plugin ils m'ont donc demandé de leur accorder un peu de temps pour écrire une page de doc sur le sujet, à intégrer dans GWT 1.6.

Si vous voulez connaître ma vision de l'informatique du XXIème siècle, un petit tour par la vidéo tournée par JavaBlackBelt lors de l'anniversaire du ParisJug s'impose :

Juste un petit coup de pub pour vous annoncer l'ouverture du blog d'Arnaud Héritier, développeur et membre du "Project Management Committee" de Maven.

Le ParisJug fête son anniversaire mardi soir. 

Invité sur Facebook, et pour une fois par quelqu'un que je connais vraiment, je découvre l'application de "social networking" qui fait craquer les moins de 25 ans. Comme j'ai (un peu) passé ce cap, je reste relativement septique sur l'utilité au quotidien de cet outil. Il faut reconnaitre tout de même la grande maîtrise de ses créateurs : IHM simple mais très complète, plein de chtit trucs Ajax pour une bonne ergonomie. De quoi passer quelques heures par jour pour savoir qui acheter comme ami.

Depuis peu, google propose le très attendu gMail offline.

GXT (== ext-gwt) est une adaptation de EXTJs en GWT. Pas juste un wrapper, mais une reécriture. Donc a priori un truc super optimisé et qui s'intègre parfaitement dans la logique GWT.

Le BeJug, à l'origine du site de conférence Parleys.com (si vous ne connaissez pas, c'est le moment d'aller y perdre .. quelques heures) proposera sous peu un espace gratuit pour les Java User Group.
Je suis donc en train d'équiper le BreizhJug de tout le nécessaire pour capturer nos sessions dans les meilleures conditions. Après le caméscope à disque dur (que nous avons depuis le début) qui donne une image correcte - sans plus - du speaker, nous avons désormais un dispositif de capture VGA (vga2usb) qui permet de capturer toutes les démos faites par nos conférenciers et d'un micro semi-pro pour avoir un son irréprochable, ce qui changera du style "caméra cachée" que nous obtenions jusqu'ici avec le micro intégré du caméscope.

Il ne reste plus qu'à apprendre à maîtriser Parleys Publisher, l'environnement d'édition vidéo associé...

Rendez vous en ligne ... sous peu !

Blooger n'est pas très adapté pour fournir des fragments de code. La librairie syntaxhighlighter semble fournir une solution fonctionnelle pour contourner ces limitations.

Ceci est un test intégrant du code source Java :

public abstract class ConfigurableBean
{
 /** Configurer used to inject dependencies in ConfigurableBean instances */
 private static BeanConfigurer configurer;

 /**
  * Constructeur par d�faut
  */
 public ConfigurableBean()
 {
     if ( configurer != null )
     {
         configurer.configure( this );
     }
 }
}

La JSR 295 a été crée pour définir un mécanisme de binding en Java. L'idée simple et supportée par de nombreux langages est que deux attributs de deux beans soit "liés", ce qui permet par exemple à un widget graphique de toujours rester synchronisé avec l'objet modèle qu'il affiche, sans devoir écrire du code de mise à jour fastidieux et répétitif.

Devoxx se termine avec la projection d'un film pour certains, et les derniers "BOFs" pour les autres.

J'espère que vous avez apprécié mon "en direct", si vous trouvez des blogs/docs équivalents sur le net laissez un commentaire, que tout le monde en profite.

Et pour les membres du BreizhJUG, rendez-vous le 5 Janvier pour une session qui sera au couleur de JavaFX.

A l'occasion de son passage à Rennes pour donner une formation GWT, Sami Jaber nous fait le plaisir d'accepter l'invitation du BreizhJug. 

Charlie Collins, project lead of gwt-maven, a Maven plugin for GWT, join the Mojo team o merge it's plugin with gwt-maven-plugin

Voici mon témoignage. Notez l'excellent (si si) jeux de mot.

Après plusieurs mois de mise au point et de test sur le terrain, je viens de lancer un vote pour une permière version "officielle" de mon plugin GWT pour maven.

Microsoft a récemment proposé aux développeurs de la fondation Apache un abonnement MSDN gratuit. Celui-ci comporte entre autre un accès à la logithèque Microsoft, dont Visual Studio dont il s'agit de faire la promotion, mais aussi Windows, Office & Cie. Apparemment, l'opération a eu un très grand succès auprès des développeurs Apache, bien qu'ils soient nombreux à travailler sur Mac et/ou Linux.

Je vais peut être tester Vistual Studio par acquis de conscience, même s'il risque de ne pas trop faire l'affaire pour mes développements Java / Maven, quelque soient les reproches que l'on puisse faire à Eclipse ;)

A l'heure ou je préparais Mme à passer le PC de la maison sous Ubuntu, après avoir converti tous ceux de l'école dont elle est la directrice, en plus de mon eee-pc et du portable qui me permet d'écrice ce billet, je vais donc peut être ré-installer un Windows XP totalement légal sur notre PC de bureau (bien sur, quand je dis "ré-installer", c'est parce que le système est tout vérollé après des années de mauvais usages, pas pour un quelconque problème de licence).

Mon extension pour m2eclipse commence à fonctionner. Elle permet de lire la configuration Checkstyle à partir du plugin maven et de l'appliquer au plugin eclipse.

Le NantesJug organise une soirée Maven, animée par Arnaud Héritier, membre du "Project Development Commity" Maven. Pour ceux qui connaissent mal les raffinements de la fondation Apache, cela signifie qu'Arnaud a gravi tous les échelons de la méritocratie sur le projet Maven et que son vote pèse dans chaque décision majeure.

SpringSource vient de s'offrir G2One, la société fondée pour soutenir le développement de Groovy et Grails.

L'intégration de maven sous Eclipse est un sujet qui a pris .. un certain retard si on compare à NetBeans ou Idea. La faute (sans doute) à la gueguerre entre Sonatype et Exists, les deux sociétés qui emploient des core-développeurs de maven, et qui supportent chacune un projet concurrent (m2eclipse vs q4e).

Dans le monde opensource on a coutume de dire que la concurrence est bénéfique. Seulement dans ce cas, chacun développe grosso-modo les mêmes fonctionnalités, et sur la base de la même plateforme à quelques détails techniques près.

m2eclipse remporte pour ma part un court avantage (mais ce n'est qu'un avis parmi tant d'autres) : les échanges que j'ai pu avoir avec les développeurs montrent une grande réactivité et une réelle volonté d'ouverture.

Dans mon cas, j'ai voulu ajouter le support de CheckStyle à m2eclipse; autrement dit, une extension m2eclipse qui va lire la conf de maven-checkstyle-plugin et la "traduire" pour configurer eclipse-cs, le plugin Checkstyle pour Eclipse.

Le bon point de départ, c'est que la plateforme Eclipse est conçue pour ce type de greffe de fonctionnalités (les fameux plugins) et m2eclipse ne déroge pas à la règle. Il y a donc une API très simple pour venir participer à la phase de configuration d'un projet Maven sous Eclipse.

La mauvaise surprise, c'est que cete API est un peu trop simple même dès qu'on a besoin de manipuler des concepts maven (classpath, résolution de dependances, ...). Comme il faut en plus découvrir comment se programme le plugin eclipse qu'on désire supporter, ça fait beaucoup de choses. A moins d'être un pro d'Eclipse + un guru de Maven, on en bave !

De rapides échanges avec Eugene Kuleshov m'ont convaincu que :

1. je ne suis pas tout seul dans cette galère, et toute l'équipe de dev de maven est prête à apporter aide et conseils
2. le seul moyen d'améliorer les choses est de "communiquer" pour que chacun apporte sa petite pierre à l'édifice.
   

Voici donc ma petite pierre :

• une page du Wiki qui décrit le principe et les pratiques à connaître.
• un ticket Jira pour permettre à chaque contributeur qui est contraint de réinventer l'eau chaude de "mutualiser" ses efforts.
  

Après le dual-core, puis le quad-core, voici une nouvelle génération de processeur qui va venir motoriser nos PCs de demain : le quintuple coeur.

Mon projet actuel utilise activement la modélisation UML pour sa conception. Nous avons donc une panoplie complète de diagrammes, et bien sur des documents au format Word à produire, respectant le formalisme maison et une structure stricte.

L'outil de modélisation UML utilisé n'ayant pas le bon goût de supporter notre format de sortie, nous sommes passé par une solution (si on peut dire) d'une simplicité impressionnante :

• export du modèle UML en XMI (compter 30 minutes)
• lancement d'une transformation XSL:FO pour produire les documents en RTF (compter 15 bonnes minutes)
• utilisation d'une macro word pour la mise en forme (compter 15 bonnes minutes par document)

Des optimisations sont très probablement possibles, mais dans tous les cas c'est très long...

Comment automatiser tout ça, pour éviter de passer des heures devant son PC à attendre l'étape suivante ?

Pour la transformation XSL, j'ai crée un petit plugin maven basé sur FOP. Ce n'était pas le plus difficile

Pour le reste ... je suis tombé sur le projet JACOB, qui permet de manipuler en Java l'API COM de Windows, et donc de faire de l' "automation" d'applications sous Windows. J'ai donc réussi à :

• lancer word,
  
• ouvrir le fichier RTF,
  
• copier/coller son contenu dans le document contenant les macros,
  
• ... qui sont ensuite exécutées
  
• et enfin sauvegarder le résultat dans le répertorie cible (ouf!).

Il faut encore que j'essaie d'utiliser le même mécanisme pour piloter l'extraction XMI, qui n'est pas "légère" elle non plus.

Comme quoi, l'automatisation de la chaîne de production n'est pas impossible (parfois juste un peu délicate). Et au final, on pourra avoir une version complète des docs en cohérence avec le modèle UML deux fois par jour.

Vous voulez tester Google Androïd avant tout le monde ? Vous êtes un Geek pur et dur du genre incurable ?

Il sera disponible dès le 10 novembre ici...

pour ceux qui ont un buget Geekitude solide !