new Blog( perso );

J'ai (enfin) expérimenté sérieusement GWT. Je suis assez bluffé par ce framework.

Mes essais précédents en terme de technos JavaScript se sont tous terminé sur la conclusion : "il va falloir sacrément former les développeurs". Aussi riche que soit une librairie JavaScript, il faut déjà quelques notions pour s'y attaquer. Par ailleurs, tester du code JS, même avec jsUnit, reste un point délicat - surtout si on veut l'effectuer sur un serveur d'intégration continue (en mode console).

GWT a l'énorme avantage qu'on oublie vite qu'on fait en réalité du code JavaScript. J'ai ainsi pu apliquer une jolie décomposition MVC (voir sur le sujet http://blog.springsource.com/main/2008/02/19/enabling-test-driven-development-in-gwt-client-code) sans gros efforts.

Paradoxalement, c'est peut être la plus grande difficulté de GWT : ne pas oublier qu'on développe du code qui sera sur le client : pas de commons-* sous le coude, ni de bean Hibernate !

J'en ai profité pour revoir le plugin gwt pour maven du projet Mojo, qui était plus ou moins à l'abandon (le compilateur GWT ayant le mauvais gout de faire un System.exit() !). Je compte lui ajouter un outil de génération de DTO à partir de beans JPA/Hibernate, à utiliser avec hibernate4Gwt. Mais je ne promet rien, c'est juste un élément de plus dans ma todo-list ;-)

Pour ce qui est de la richesse visuelle des widgets, GWT-ext ou myGWT fournissent une base déjà très intéressante pour faire de jolies applications.

Je suis cette semaine en formation "architecture d'entreprise". Un mot clé (entre autres), la "souplesse", avec derrière la tête l'externalisation et tout ce qui va avec. Les workshops sont édifiants : réduction des couts, rationalisation, recentrage sur le coeur de métier, ... collaboration avec l'Inde...


L'exemple utilisé est très parlant : la major du service informatique qui sert de support aux exercices a une étrange ressemblance avec ma boîte, les mêmes objectifs et la même stratégie. Ce parallèle est parfois amusant mais aussi inquiétant si on considère que l' "exercice" est en cours d'application depuis deux ans. Elément rassurant (?), les "architectes" restent relativement bien placés dans les plans de délocalisation (appelons un chat un chat). La pyramide des postes en fance ressemble cependant dans les scénarios "full-india" à un arbre : un fin tronc et quelques feuilles plus touffues en haut.

Question : comment formera t-on à l'avenir les futurs ingénieurs si aucun poste de début de carrière n'est proposé en occident ???


Un billet un peu politique je l'avoue, mais après 8h de formation à "isoler" puis "externaliser" (quel joli mot) les services de l'entreprise "Lonely Heart", on se rapelle tout d'un coup que la branche sur laquelle on est assi n'est pas plus solide que celle du voisin...

La fondation apache héberge pour ses projets un serveur Continuum ET un serveur Hudson
(http://vmbuild.apache.org/continuum, http://hudson.zones.apache.org/hudson). Continuum étant développé en marge de Maven2, son intégration des projets Maven se doit (dervait?) d'être exemplaire.

Or le serveur Continuum est régulièrement dans les choux. Pas forcément à cause de Continuum bien sur, peut être aussi un peu à cause du serveur HTTP Jetty ou de la "zone" d'hébergement... mais en tout cas une migration sous Hudson est envisagée, au moins à titre expérimental dans un premier temps. Un sérieux revers pour Continuum !

J'utilise moi aussi continnum, tout simplement parce qu'il propose depuis le début la fonction "envoyer un mail à ceux qui on cassé le build", et surtout l'ajout automatique d'un domaine email aux IDs subversion pour identifier les fautifs. Et le rythme de développement d'Hudson est impressionnant !

Ma chère et tendre Delphine me maudit car elle devait profiter des vacances scolaires pour réviser son anglais sur le site de la BBC, afin de préparer son habilitation à l'enseignement de la lange de shakespeare...

Heureusement qu'il me reste le bon vieux modem 56k et la "connexion de secours Free". C'est pas vraiment du mégabit, mais ça permet tout de même de lire ses mails... et d'ouvrir en seulement 47 secondes la page d'édition de blogger.com !

Comme tous les outils de la communauté maven, Archiva (Maven Repoistory Manager) a été construit sur le conteneur Plexus. Qu'on aime ou pas sa philosophie assez spécifique, il faut constater que cet outil manque cruellement de documentation et est méconnu de nombreux développeurs, ce qui n'est pas le cas de Spring.

La liste de développement d'Archiva a réagit avec enthousiasme à la proposition de migrer sous Spring, malgré le gros effort que cela représente (il y a du plexus-* un peut partout).

Je développe un outil de transition, sous le doux nom de "plexus-spring", qui vise à exécuter des composants plexus dans un contexte Spring, en traduisant les fichiers de configuration plexus et les interfaces d'initialisation/destruction dans le vocabulaire Spring.

Après quelques errements dans les circonvolutions du code Spring, j'en suis venu à

• Une transformation XSLT des descripteurs plexus en contextes spring
• un namespace spécifique qui reprend dans spring les déclarations plexus.
  
• une BeanFactory qui se charge de construire le composant plexus, en gérant l'injection directe dans les attributs.
  
• Un BeanPostPorcessor vient compléter le tout pour gérer l'initialisation/destruction.
  

Et en bonus, une classe de test PlexusInSpringTestCase pour remplacer sans modification du code les PlexusTestCase.

Une idée apparemment bonne car on m'a tout de suite demandé le niveau de maturité de ce code pour l'appliquer sur Continuum ! Comme quoi plexus n'a pas vraiment que des admirateurs.

Udate 29/02 :
Je viens de démarrer pour la première fois mon application web Archiva, de la configurer et d'obtenir un premier Jar , tout ça avec Spring comme conteneur ! Il y aura probablement encore quelques ajustements à faire mais c'est très prometteur : grâce à plexus-spring, je n'ai eu aucune adaptation à faire au code d'Archiva !

A quoi sert System.nanoTime() en Java ? Qui a VRAIMENT besoin d'une précision en nanosecondes ?

Premier élément de réponse, System.nanoTime() ne fournit pas un compteur en ns, mais le meilleur compteur disponible sur le système. La précision réellement obtenue est donc ... indéterminée.

C'est d'ailleurs également le cas de System.currentTimeMillis(), qui sous Windows repose sur un compteurs standard de l'OS, ce qui permet à cette méthode d'être extrèmement rapide ... au prix d'une imprécision de 10 à 15ms ! Ennuyeux pour évaluer le temps de traitement des méthodes Java, qui sont régulièrement de l'ordre de quelques ms...

Sur le même Windows, System.nanoTime() est environ 100x plus lent, mais fournit une précisionde l'ordre de la microseconde (selon le hardware, la version Windows, le service pack et la conf système !) .

En résumé, System.nanoTime() fournit ce qu'il y a de plus précis sur le système hôte, et System.currentTimeMillis() un timestamp qui peut parfois être imprécis de 15ms.

"Write once, run anywhere" qu'ils disaient ! Si vous cherchez un compteur en secondes ça devrait aller. Pour faire plus fin, ... ça dépend. Donc dans le doute, on prend les nanosecondes et on ajoute un joli warning dans la doc :

Je peste a longueur de journée contre ce #%£@!! PC qui n'avance à rien, qui se fige dés que je supprime un répertoire dans un interminable "10 secondes restantes".

La cause ? Pour pouvoir utiliser Windows "raisonnablement" (installer quelques softs de base) on a besoin des droits d'administration, et on s'expose donc aux trop nombreux problèmes de sécurité, d'où la panoplie habituelle d'antivirus, scripts de sécurité, filtres en tout genre et firewalls réseau. Et comme la "politique de sécurité" est gérée au niveau "groupe", impossible de juste dire à l'antivirus de ne pas scanner mes .jar à tour de bras.

Il faut dire que la suite McAffee est particulièrement consommatrice en performances (en tout cas, telle qu'elle est configurée sur nos PC de bureau).

Je tente donc un passage sous Linux, en dual-boot. Non pas que je sois un défenseur du libre absolu, ou un extremiste du pinguoin, mais il faut reconnaitre que la très bonne sécurité et la (relative) confidentialité de linux sur les postes bureautique élimine de fait les risques de virus et Compagnie.

1er essai avec Ubuntu 7.10 :

• tout mon matériel est reconnu
• je peux accéder aux disques samba de mon domaine Windows
• l'imprimante réseau est supportée

cool !

J'installe java6 et je lance un "java -version". La réponse est tellement immédiate que je ne la vois pas au premier coup, habitué à une certaine latence au lancement de java sous Windows...

J'installe Eclipse "de base", le démarrage est incroyablement rapide (en fait, le démarrage sous Windows est incroyablement lent).

C'est plus qu'encourageant !

Il me reste à installer tous mes plugins Eclipse habituels, importer les projets Java et faire un test "d'égal à égal".

Il faudra encore régler l'installation d'Office 2003 (via l'émulateur Wine) et la configuration d'evolution ou thinderbird pour Exchange... mais ça semble valoir le coup de quelques efforts.

Au pire, je demanderais un vieux PIII 500 pour consulter outlook et la doc projet, et je mettrais un petit KVM pour partager le clavier/souris.

J'ai aussi tenté le "ubuntu sous VirtualBox" mais ce n'est pas super concluant pour l'instant. Les perfs sont sensiblement aussi mauvaise que sous Windows, soit que l'émulation coute trop cher, soit que les "ralentissement" dus à Windows ne soient pas éliminés par l'émulateur.


NB : Mon Windows @Home est tout à fait performant, protégé par Avast, et Eclipse y est stable et rapide. Il ne s'agit donc pas de casser du sucre sur Bill, mais plutôt sur mon Responsable Informatique qui met en place une super-sécurité, mais pourrit notre productivité !

Update 24/01

Tout fonctionne sous Linux, ... sauf la bureautique.

1. Je suis "emprisonné" dans les réflexes MS Office et j'ai bien du mal à me faire à OpenOffice
2. L'émulation avec Wine permet de lancer Office mais je ne peux pas me permettre le risque de véroller la documentation projet
3. Les "macros" et autres modèles nécessitent des montages Samba, pas super simples à mettre en oeuvre sous Linux.
4. L'édition d'un fichier .pwt sous OpenOffice une fois ré-enregistrer en format "office" n'est plus utilisable ... compatbilité pas tout à fait au rendez-vous.

Je vais peut-être tenter le KVM avec un petit P800 pour conserver mon environnement de dev sous Linux et l'édition bureautique sous Windows ...

J'ai utilisé depuis X années Axis1 comme pile Soap, parfois avec douleur quand il a fallu rentrer dans le code pour identifier un problème de sérialisation... le code n'étant pas vraiment limpide !

Avec la norme Jax-WS et les "nouvelles" piles SOAP, d'autres solutions sont possibles. J'ai eu l'occasion sur un projet qui démare de faire une rapide évaluation :

• Metro (implémentation de référence de Jax-WS, faisant partir du projet Glassfish)

A priori attractif, en raison de l'aspect "respect des standard". L'essai n'a pas été très concluant :

1. la gestion des dépendances Maven est délicate, car on fait référence à un grand nombre de jars javax.* et com.sun.* qui sont dans le repository maven1 de dev.java.net. On doit donc jongler avec les repositories
2. le plugin wsdl -> service, basé sur jaxb2.1 ne fonctionne pas sous Java6. Merci à Sun d'avoir pensé son API de manière si évolutive !
3. le plugin plante sur mon WSDL, qui utilise des imports.
4. le support pour Spring utilise un repository TRES surprenant : http://ndeloof.free.fr, mon site perso à moi que j'ai ! Celui sur lequel j'ai placé les -sources des jars Spring à tritre temporaire...

• Axis2

Après le succes de fait de Axis 1 (faute d'alternative ?), axis2 semble la solution à suivre.

1. D'après ce que j'ai pu lire, les premières versions ont été une calamité en terme de bugs
2. Le plugin wsdl2java plante sur mon WSDL avec un joli NullPointerException
3. Le POM.xml du projet fait référence à repo1.maven.org/maven1 + repo1.maven.org/maven2. Non seulement ce sont les repository par défaut, mais le premier est une redirection vers le second. Détail, mais qui montre le niveau de support pour maven2
4. Le principe de packages un "aar" pour le déployer dans la webapp est hyper lourd. Je n'ai JAMAIS eu besoin de déployer à chaud un service web, sans avoir à relivrer toute l'application qui va avec. Je suppose qu'il y en a à qui ça sert, mais ça devrait n'être qu'une option.

• Apache CXF (ex apache Cletix + codehaus Xfire fusionnés)

J'ai déjà entendu pas mal de bien de XFire, qu'en est-il de sa fusion avec Celtix ?

1. La génération Wsdl -> service fonctionne. C'est déjà bien
2. Les méta données Maven2 sont bonnes, via le repository de l'incubateur apache
3. L'intégration avec Spring est triviale, via un namespace dédié et trois lignes de XML
4. Un transport "local" permet de tester le service web (sérialisation SOAP incluse) sans déployer de serveur HTTP. Super pratique pour écrire des tests unitaires.
5. Possibilité de tracer facilement les messages SOAP dans les logs : pratique

Pour ce qui me concerne, CXF est donc vainqueur par KO. J'ai pu développer et écrire un test unitaire pour mon service en quelques heures, en ne connaissant rien à l'outil à priori. La doc est claire et correspond à ce qu'on obtient réellement (ce qui est rare ;-p). L'intégration avec maven2 et Spring est très bonne, critère qui n'est pas forcément celui de tout le monde mais qui a son importance pour moi.

Mon second choix irait à Metro si les "petits problèmes" sont corrigés

Quand à Axis2 - "pourquoi faire simple ..." - moi qui cherche un moyen de faire du service web via juste quelques fichiers de conf, voila qu'il faut faire un projet dédié, packager un "aar", le déployer, créer des modules et je ne sais quoi... tout ça pour un "hello world" ?

J'ai voulu essayer la pile jax-WS Metro...

Si on met de côté le manque de support pour maven2 lorsqu'il s'agit de diffuser les Jars des API Java (il faut jongler avec les repository de dev.java.net), je suis tombé sur une de ces boulettes auquel Java nous a habitué :

Lancé sur Java6, la génération JaxB plante ... car l'API jaxb2 fait partie de java6 et metro utilise Jaxb2.1 - incompatible bien entendu.

Cette sale habitude de fourrer toutes les API dans le JRE sans possibilité de modularisation est pénible (qui n'a pas galèré avec les API XML ?). A croire que le terme "compatibilité ascendante" n'existe pas chez les membres du JCP ?

Pourquoi ne pas laisser au soft le soin de définir ses dépendances ?
J'ai besoin de JAXB ? Je précise dans mon MANIFEST ce dont j'ai besoin, et la JVM me fournit le classpath "qui va bien".
La JSR-277 apportera t-elle une solution de ce type ? A quand une généralisation d'OSGi ? Pourquoi aura t-il fallu attendre Java 7 pour que ce problème soit enfin pris en considération ?

update :

d'après ce lien, le dernier "update" de la JVM 6 de SUN intègre JAXB 2.1 en remplacement de 2.0. Comme quoi un petit update n'est pas forcément anodin !

Je trouve très domageable qu'une version mineure intègre une mise à jour d'API, avec le risque que deux applications "java6" ne fonctionnent pas pour cause d'update insuffisant.
J'ented déjà les problèmes arriver :
"
- je n'arrive pas à compiler le projet : j'ai une erreur xxx
- quelle version du JDK tu utilises ?
- la 6 !
- quel update ?
- quel quoi ?
"

En passant de maven 1 à maven 2, on corrige (entre autre) un défaut de maven 1 : on peut faire un "clean" sur un projet qui n'a encore jamais été compilé. Quel intérêt ? sur un serveur d'intégration continue, le tout premier build ne pouvait pas être du type "maven clean jar:install" !


Un autre bug gênant : pour configurer son IDE préféré (Eclipse dans mon cas, tout simplement parce que je n'ai pas pris le temps de tester Idea ni Netbeans !), on lance "mvn eclipse:eclipse". Et la, crac, la simple présence d'un projet EAR fait planter le build. La faute aux plugin eclipse qui exécute la phase generate-sources, seul moyen d'identifier tous les répertoires de code généré. On doit donc faire un "mvn install" avant de pouvoir bosser sous Eclipse. Mais alors, si le code sous SVN est buggé et ne compile pas ?... reste le bloc note pour corriger !

Je cherche un moyen de fixer ce problème. Deux options :

• trouver une astuce pour que la résolution des dépendances n'échoue pas. Par exemple, enregistrer chaque module comme "artifact virtuel" pour qu'il ne soit pas recherché sur le repository. Seulement les composants interne de Maven sont un peu obscurs et pas trop ouverts à ce genre de "hack".
• faire évouler l'API des plugins maven ("mojo") pour que le plugin eclipse puisse identifier les plugins générateur et le répertoire qu'ils créent. Pourquoi pas profiter du passage à maven 2.1, mais encore faut-il convaincre la communauté :-/

J'aurais peut-être du commencer par quelque chose de plus simple...

J'ai effectué mes premiers commits sur Archiva, afin d'intégrer un meilleur support de Maven1.

Comme toute première fois qui se respecte, j'ai généreusement merdé :

• commit "mis à l'index" faute de commentaire @since dans le code
• build Continuum planté, suite à un cafouillage sur archiva-configuration

Heureusement mes petits camarades sont tolérants et m'ont gentiment remis dans le droit chemin, avec quelques indications sur les bonnes pratiques @Apache.org.

Brett Porter (développeur de maven) me fait l'honneur de me proposer comme committer sur son projet, suite à mes efforts pour faire d'Archiva un repository qui supporte maven1 de manière transparent.

Le vote est en cours, et reste ouvert à un ennemi inconnu qui viendrait mettre son véto...


Si vous êtes abonné à la liste "dev@maven.apache.org", n'hésitez pas à ajouter votre petit "+1" d'encouragement. Même s'il n'est pas décisif, ça fait toujours plaisir !

Si je suis accepté, il me sera difficile de crier au loup quand Maven ne fait pas ce que je lui demande (même si je peux toujours dire que c'est la faute des autres...), ce qui ne me place pas dans une position très peu objective dans le choix "Maven vs Ant".


Roulement de tambours...

Update

Ca y est, Je suis (L')élu ! ... enfin, presque : je n'ai pas les lunettes de soleil de la mort qui tuent.


Me voici donc committer Apache Maven, avec le soutien de (par ordre d'apparition)

• Brett Porter
  
• Emmanuel Venisse
  
• Arnaud Heritier
  
• Maria Odea Ching
  
• Olivier Lamy
  
• Fabrice Bellingard
  
• Stephane Nicoll
  
• Vincent Siveton
  
• Jeff Jensen
  
• Ralph Goers
  
• Jess McConnell
  
• Wendy Smoak
  
• John Cassey
  
• Dennis Lundberg
  
• Joakim Erdfelt
  
• Raphaël Piéroni
  
• Lukas Theussl
  
• Rahul Takhur
  
• Brian E. Fox
• Mauro Talevi
• John Tolentino
• Hervé Boutemy
  

Merci à tous ! 100% des suffrages exprimés, c'est digne d'une république bananière !

Il me reste à assumer et à donner à Maven les qualités que je lui réclamait hier en tant qu'utilisateur frustré.

Après plusieurs années à trainer sur les listes de diffusion autour de Maven, quelques contributions isolées et de nombreux échanges, j'ai été accepté comme committer sur le projet Mojo.

Ce projet permet de développer en marge de la fondation apache des plugins pour maven. Je vais y contribuer en y déposant un plugin pour JavaScript que j'ai ébauché, suite à une discussion riche de bonnes idées sur la liste maven. Reste donc à "assumer" et à mener ce plugin jusqu'au bout, c'est à dire quelque chose de vraiment utile et fonctionnel.

Un grand merci à Raphaël, Arnaud, Emmanuel, Carlos et John qui m'ont apporté leur soutien pour les rejoindre sur ce projet.

A mon retour de Spring'one 07 je me suis clairement demandé s'il était vraiment pertinent de passer sous maven2, étant donné le temps que j'ai pu perdre (comme tant d'autres) à mettre mes builds au point, avec le bon plugin dans la version qui va bien, et dont la correction indispensable n'est disponible qu'en SNAPSHOT...

Cet été j'ai tenté de migrer un projet maven1 existant sous maven2 et

1. les plugins maven2 n'étaient pas dispo ou n'utilisaient pas une version compatible des outils
2. le build étant assez touffu dans ses maven.xml, la conversion n'était pas du tout triviale
3. le packaging propre à mon client adoré se plie assez mal à l'utilisation de maven.

Cette migration a donc été un très bon exercice, mais également un échec (temporaire ?).

D'un autre côté, un argument massue de maven continue de me séduire : les archetypes ! Le plugin archetypeNG permet de créer un archettype à partir d'un projet type, c'est donc un super moyen pour proposer démarrer un projet en quelques minutes sur un socle pré-configuré.

J'ai donc du mal a prendre position, et justement, on me demande de participer à une évaluation pour la généralisation de maven2 sur les projets de ma boite... peut-être un bon moyen pour que je sois un peu plus impartial que d'habitude ? (je suis un peu trop "geek" et pas assez "pro" quand on parle technos...).

A mon retour de Spring'one 07 je me suis clairement demandé s'il était vraiment pertinent de passer sous maven2, étant donné le temps que j'ai pu perdre (comme tant d'autres) à mettre mes builds au point, avec le bon plugin dans la version qui va bien, et dont la correction indispensable n'est disponible qu'en SNAPSHOT...


Cet été j'ai tenté de migrer un projet maven1 existant sous maven2 et

1. les plugins maven2 n'étaient pas dispo ou n'utilisaient pas une version compatible des outils
2. le build étant assez touffu dans ses maven.xml, la conversion n'était pas du tout triviale
3. le packaging propre à mon client adoré se plie assez mal à l'utilisation de maven.

Cette migration a donc été un très bon exercice, mais également un échec (temporaire ?).

D'un autre côté, un argument massue de maven continue de me séduire : les archetypes ! Le plugin archetypeNG permet de créer un archettype à partir d'un projet de référence, c'est donc un super moyen pour démarrer un projet en quelques minutes sur un socle pré-configuré.

Autre argument choc : les profils (ou comment rendre une partie du build optionnel) et l'héritage d'un POM parent (comment mutualiser la conf répétitive et éviter aux autres les pièges à c..)

J'ai donc du mal a prendre position, et justement, on me demande de participer à une évaluation pour la généralisation de maven2 sur les projets de ma boite... peut-être un bon moyen pour que je sois un peu plus impartial que d'habitude ? (je suis un peu trop "geek" et pas assez "pro" quand on parle technos...).

Alors, ant ? / maven ?