new Blog( perso );

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 ?

J'ai utilisé jusqu'ici CruiseControl comme serveur d'intégration continue. Son support des projets maven2 est perfectible et son interface de configuration inexistante.

J'ai donc testé Continuum qui est a priori l'outil le mieux adapté pour maven. En pratique, il me manque une fonctionnalité clé : l'envoi du log aux personnes qui ont "cassé" le build (c'est dans la roadmap, mai pour quand ?).

Sur ce semi-échec, j'ai donc essayé Hudson. Le support de maven2 est en "beta" mais est déjà très correct. L'interface graphique est conviviale, et de nombreux plugins permettent de compléter le processus : vérifier que les violations checkstyle/PMD/findbugs ne dépassent pas un certain seuil, compter les "TODO" dans le code source... Il me manque tout de même une fonctionnalité : Hudson n'envoie le log d'erreur qu'au derniers auteurs de commits, pas à tout ceux qui sont intervenus depuis le dernier build stable. Les releases de Hudson étant très fréquentes, j'ai bon espoir...

Lors de la présentation d'ouverture de SpringOne, l'organisateur à fait un peu de promo pour son nouveau site www.parleys.com, qui diffuse les vidéos des sessions de javapolis et de springone, en alternative à une diffusion de DVD.

Jettez y un oeil, c'est très bien fait et plein de ressources intéressantes

Et voila, fin de SpringOne'07. Reste a faire du tri dans mes notes !

Prochain évènements du même ordre,

• TheSpringExperience en floride, mais je ne pense pas que mon patron me paye le billet !
• JavaPolis organisé comme SpringOne par le très actif "Belgium Java User Grup".

Ca me laisse tout juste le temps de prendre quelques cours d'anglais...

Petite discution entre quelques "core-developers" de Spring ce matin, sur ... l'art de modifier le mapping des touches du clavier QWERTY pour rendre la frappe plus rapide ! L'un d'entre eux met par exemple le "." à la place du Q et le ";" à la place du "A", remplace [CapsLock] par par "{", etc.
Après quoi ils enchaînent sur une comparaison du modèle mémoire de Java et d'Erlang pour la synchronisation des threads...

Et après, on vient me dire que je suis un "geek" ?

La présentation d'OSGi était plus qu'aléchante : plus de problèmes de classloaders (voir commons-logging ou xerces sous WebSphere 5...), possibilité de mise à jour a chaud, de reconfiguration, séparation explicite de la partie "publique" d'un module et de son implémentation...

La plateforme OSGi est disponible depuis longtemps puisqu'Eclipse est basé dessus, aussi ça fait un peu mal au coeur de penser qu'on galère avec les déploiements JEE. L'équipe de Spring a fait un travail impressionnant pour mettre en place un modèle "POJO" sur OSGi :

• Codage totalement indépendant de l'API OSGi -> test unitaires simples
• Support complet pour les tests d'intégration (déploiement d'un vrai conteneur OSGi)
• Toute une série de à utiliser dans le contexte Spring pour accéder aux autres modules, comme à n'importe quel autre bean, sans aucun changement dans le code.

Ca donne vraiment envie... il y a cet AM une présentation "pratique" sur l'écriture d'une appli OSGi s'exécutant sur un serveur d'application.

Les développeurs de Spring n'aiment définitivement pas maven. Il faut dire que leur code doit être compilé à la fois pour Java 1.4, Java5 et Java6, avec de multiples rafinements. Ce n'est tout simplement pas possible actuellement avec maven !

Leur argument principal : sur un petit projet, maven peut proposer des conventions bien pratiques, mais dés que les choses se compliquent, le volume du fichier XML explose.

Par ailleurs, il préfèrent largement ivy pour la gestion des dépendances, car ses méta-données sont d'une bien meilleure qualité, et évitent bien des déboires.

Ils préfèrent InteliJ IDEA à Eclipse, car sa gestion des fichiers source de tout type est bien mieux intégrée : le renommage d'une classe met à jour tous les fichiers XML ou properties. On peut faire du refactoring dans les JSP, pages HTML, CSS... quelque chose qui n'a aucun équivalent sous Eclipse.

Enfin, ils préfèrent JIRA et BAMBOO comme infrastructure qualité. Jira est quasi-universellement utilisé sur les projets opensource (license offerte!) et particulièrement efficace. Bamboo semble beaucoup plus souple et sympa que CruiseControl ou Continuum...

Ca vaudrait peut être le coup de revoir ma "stratégie" outils, car je me casse souvent les dents sur la conf de maven, sans parler de sa non-intégration sous Eclipse !

Une citation qui résume asse bien les choses (traduction approximative) : "maven, c'est comme acheter un écran plasma HD, et une fois à la maison, on à une image en noir et blanc". Un peu dur, mais pas totalement faux...

Après les sessions de Springone, un "BOF" (table ronde) était organisé entre les "core developers" de Spring et les utilisateurs. Plein de questions sur les bons usages, les annotations, l'avenir de Spring, de JEE, la place d'Osgi face à JEE...

Pas facile à suivre avec mon piètre niveau d'anglais, mais j'ai tout de même apris plein de choses sur ce que pourrait (?) devenir le développement Java côté serveur ... enfin dès que mon client favori aura accépté de larger son vieux WebSphere 5.0 et sa JRE Java 1.3 ! Alors quand on m'annonce le support de Java 6 ou des JSP 2.1, je ne me sens pas tellement concerné.

Lors de la conférence sur l'utilisation avancée de l'AOP avec AspectJ, Chris Richardon (Mr POJO) s'est permi une question provocatrive : "un POJO avec des annotations est-il toujours un POJO ?". C'est vrai qu'un objet métier "POJO" avec des annotations Hibernate, Acegy-security et Spring n'a plus vraiment l'air "Plain Old Java" !

La réponse courte : Un POJO annoté "@Entity" signale juste ce qu'il est, pas ce qu'on doit faire avec, c'est donc tout à fait acceptable (comme @Sensible pour la classe Document par exemple).

Par contre, une annotation du type @Tracable montre ce que la classe attend, à savoir d'être logguée par un framework externe, même s'il n'est pas explicitement défini. Cela crée donc un couplage indirect qui est contraire à l'esprit POJO.

J'en ai profité pour lui poser quelques questions sur son mini-framework "arid". Celui-ci permet de définir les méthodes de recherche hibernate du genre "findByNameOrderByAge" dans une interface Dao, l'implémentation étant produite à la volée par analyse du nom de la méthode, comme c'est le cas avec Ruby-on-rails ou Grails.
D'après mes mesures sur un projet réel, 90% des "finders" Hibernate sont de type findById ou findBy. Cela pourrait donc être un réel gain de productivité.

Spring 2.0 introduisait le support d'AspectJ, spring 2.1 pousse le bouchon encore un peu plus loin. L'AOP semble arriver à complète maturité après 10 ans (!) de développement. Quelque exemples montrent que l'AOP ne se limite pas à la démarcation transactionnelle :

• Contrôle de règles d'architecture (Design Level Assertion), du genre "la couche web ne fait pas d'appel direct à hibernate ou JDBC" (ça c'est vu)
• Ajout des fonctionnalités transverses (log détaillé sur exception, monitoring, ...)
• Gestion de l'architecture (reprise sur échec, basculement à chaud...)
• Intégration au modèle...
  

Il y a probablement plein de bonnes choses à tirer de l'AOP, en particulier pour simplifier le code et éliminer les copier/coller. Il faut jute l'ajouter à la trousse à outil et y penser à chaque fois qu'un problème "transverse" est identifié.

Adrian Coyler (développeur d'ApectJ) a fait une présentation "technique", présentant les langages dynamiques (jRuby, ...) et le fameux "DuckTyping" ... sauf qu'il a une vision très originale et animée du duck-typing, à grand renfort de volailles et de clavier waterproof. Heureusement qu'ils sont plus sérieux lorsqu'ils codent chez Interface21 !

Lors de la conférence de ce matin, le staff dirigeant d'Interface21 était assis sur la rangée de sièges juste devant moi : 5 portables ouverts sur les genoux pour préparer l'annonce officielle de certification de Spring par IBM sur toutes les versions de Websphere (Mainframes compris).

Amusant de voir les responsables de la société qui devient incontournable animer un blog et bosser sur une chaise pliante, portable sur les genoux, au mileu d'une foule dense, et préparer une annonce stratégique. J'imagine assez mal Serge Kampf et consors dans la même posture ! Qui a parlé de culture start-up ?

Eric Evans (le papa du "Domain Driven Desing") faisait ce matin une présentation sur les stratégie de modélisation du domaine métier, et en particulier sur la reprise d'application existantes mal strucutrées.

• Option 1 : On jette et on reconstruit un code propre. Il n'a jamais vu cela fonctionner, c'est extrèmement couteux, et on a au final un code qui marche a peine aussi bien que le précédent en ayant couté le double et en étant pas plus simple à maintenir
• Option 2 : refactoring intensif. Intéressant car il ne gèle pas les évolutions de l'existant, mais potentiellement très imparfait, et surtout pas visible en terme de retour sur investissement (le fameux "qui paye pour ça ?".
  
• Option 3 : le "hack" du code existant pour venir piocher le "core model". Pas vraiment très satisfaisant
• Option 4 : dédier un modèle à chaque contexte, et créer des couches de médiation. Ca rejoint un peu la problématique SOA (transformation des données XML d'un système à l'autre).
  

D'après lui c'est LA solution fiable, à condition d'accepter deux points :

1. Une application ne peut pas être totalement propre
2. Il n'y a pas un modèle, mais N modèles associés à N contextes

Je reste convaincu par le refactoring, mais il faut bien reconnaître qu'il a ses limites sur du code vraiment très volumineux ou totalement monolithique.

La première soirée de Springone est consacrée à une rencontre informelle avec l'équipe de développement de Spring au complet. BEA fournit la tireuse pour la biere (belge), Oracle les petits fours, et l'ambiance chauffe assez vite.
Mon niveau d'anglais montre vite ses limites dans le bruit ambiant et l'allégresse générale, mais j'ai tout de même eu quelques discutions intéressantes sur les méthode de travail préconisées par Interface21 et sur les moyens d'améliorer la productivité.

Après une bonne nuit de repos, on remet ça ce soir, mais de manière plus formelle cette fois lors des Birds Of a Feather (table ronde), et probablement plus facile à suivre.

Après le fichier XML en pagaille, on voit fleurir le annotation à tout faire. ApectJ, Hibernate, JPA, Spring, EJB3, ... n'en jettez plus !

Le code source risque de devenir rapidement un foutoir d'annotations. Pourtant il est vrai qu'il est plus naturel de déclaré qu'une référence à la datasource est @Autowired (injectée automatiquement par Spring) que d'aller chercher le bon fichier XML pour l'éditer...

Il faudra apprendre a trouver le juste équilibre. Lors de la conférence sur JPA (persistence des données) le présentateur à clairement différencié les méta-données modèle (tel attribut est la clé primaire, tel autre une FK) qu'il aime déclarer comme annotations et les méta-données de persistance (tel attribut correspond à telle colonne en base) qu'il préfère laisser dans le XML, ne serait-ce que pour se laisser la liberté d'avoir plusieurs bases pour un même modèle.

"Plain Old Java Object", soit "à mort les EJB!" et retour à la programmation orientée objet.
Un coup d'oeil à notre code : des classes "métier" vides et des "services" de milliers de lignes.

Une démo de refactoring complet migrant d'un vilain "transactional script" vers un tout beau modèle OO démontre que ce n'est pas une fatalité et qu'il y a toujours moyen d'améliorer le code. Quand au coût de cette pratique

1. L'appoche étant incrémentale (refactoring sans aucun impact fonctionnel) on peut investir dessus par petites touches
2. Un code léger et lisible est évolutif, donc moins couteux a maintenir, mais surtout plus lisible. Combien coute de devoir maintenir un "expert" historique du projet juste parce qu'on ne comprend rien au code en place ?

Ca fait partie des choses "à mettre en place dés lundi matin"...

Spring a démontré la force de son modèle POJO dans la simplification des developpements, ainsi que ses qualités techniques. les éditeurs suivent en force:

• Bea Welogic 10 est basé sur spring 2.0 en interne
• IBM certifie Spring sur Websphere, et en particulier sur ces mainframes zOs
  
• Oracle propose une intégration avancée dans son serveur OC4J
• etc...

Interface21 (qui développe Spring) a reçu un investissement de 10 Mon $ pour assurer son développement. La conférence d'introduction de Springone a porté sur l'utilisation de cette somme, et pour rassurer sur le maintien de l'orientation opensource + simplification des devs java. L'équipe support se renforce (ils proposent même un contrat de support avec pénalités !), une équipe commerciale dédiée est montée pour ne pas gèner les "core developers", et 9 personnes sont maintenant dédiées à plein temps sur le développement de Spring (dont 5 sur la partie web).

Et ce ne sont pas les idées qui leur manque. Au dernières nouvelles :

• L'utilisation des annotations à la place des fichiers XML (on peut utiliser les deux) pour simplifier la conf
• Le pojet spring-batch (en collaboration avec Accenture) pour l'écriture de batchs Java de qualité, facilement reconfigurables (exécution en parallèle, ...)
  

J'ai pu discuter avec un "core developer" de spring sur un sujet qui lui a chatouillé les neurones : comment effectue des tests fonctionnels (tests d'interface web) reproductibles sur une application qui dépend au niveau métier d'un serveur distante (MQ, Tuxedo, ...) ?

Le problème : comment contrôller

1. que l'infrastructure est en place (queues MQ, simulateurs configurés...)
2. que le simulateur effectue le traitement exact prévu par le test

le tout sans se prendre la tête avec 2 tones de conf et de frameworks...

Une idée : l'application est lancée en utilisant la classe de test elle-même comme objet "mock" à la place de l'invocation du serveur distant. Le code de test est alors à la fois dans la JVM de l'application web (comme simulateur du service) et dans la JVM qui pilote le test. L'écriture du test est donc très simple et à la portée d'un "junior developer".

Il suffit alors de prévoir dans le "setup" du test de contrôler le serveur pour le faire utiliser la classe de test comme simulateur du service, chose qui n'est pas très compliquée par JMX interposé. Reste a package cette partie pour que n'apparaisse que le strict minimum aux développeurs et pas tous les rafinements techniques que nous aimons tous...

Bref, ça commence dur cette édition 2007 de Springone ! J'espère qu'ils auront encore tout plein de bonnes idées à me passer.

Après ma visite l'année dernière che nos voisins belges pour la première de Spring'one, je récidive avec l'édition 2007. Le programme est chargé (3 jours de conférences en 3 sessions parallèles). Je vais particulièrement m'attarder sur les points suivants :

• utilisation de la programmation orientée aspect (AOP). Nous l'utilisons de manière triviale pour le transactionnel, mais on peut faire bien plus de choses...
• intégration avec les "nouveaux" outils web - google web toolkit en tête
• programmation d'un modèle objet riche, dans l'esprit "Domain Driven Design". Tous les projets sur lesquels j'ai travaillé restent enracinés dans une appoche "services" avec des gros pavés de code, et un modèle qui sert juste de boi-boites à données. Du coup, ou est la structuration objet ?
• et probablement, plen de surprises que je n'anticipe pas...