new Blog( perso );

Developping gwt-maven-plugin was a pain. GWT was clearly not designed with Maven conventions in mind and we had to find many hacks and workarounds. Google Eclipse Plugin didn't made things simplier as it came with some hard-coded path and we had then to satisfy 3 conflicting points of view...

But things change

With 2.1 release, GWT Team is looking to nicelly integrate with Maven. We are in contact to see what changes could occur on GWT side to better fit into Maven. The first visible effort is a new "-maven" option in webAppCreator script to generate a maven compliant project structure and the adequate POM.

The maven plugin allready includes an archetype for same purpose. I'll upgrade it to match the webAppCreator one, with some improvements (including Google Eclipse configuration). I've sent the GWT / Google Eclipse Team a list of feature requests to make Maven / Eclipse / GWT work better together.

As a result, I expect to release a 2.1.0 preview releases of gwt-maven plugin for next GWT Milestones, so that the plugin could benefict from changes made on Google side, and the POM generated by webAppCreator could also use those new features.

I also called for a vote on Mojo Dev List to change the development process so that new release of he plugin match a GWT release, and don't support anymore all SDK history. This will make things technically simplier and will drop a large set of obsolete parameters.

Good days Maven users, GWT will become your favorite toolkit in near future !

Update :
You can test a first preview early-adopter draft SNAPSHOT.
Doc is deployed at http://people.apache.org/~nicolas/gwt-maven-plugin-2.1/ (much cleanup needed)
same URL is a maven repo to get the plugin. Test it using (as a single line) :

mvn archetype:generate -DarchetypeRepository=http://people.apache.org/~nicolas/gwt-maven-plugin-2.1 \
 -DarchetypeGroupId=org.codehaus.mojo \
 -DarchetypeArtifactId=gwt-maven-plugin _\
 -DarchetypeVersion=2.1-SNAPSHOT  

Vous le savez forcément déjà, mais j'en remet une couche : le 10 septembre aura lieu à La Rochelle le JugSummerCamp, un concentré de JUG dans une journée de conférence, gratuit et indispensable, avec un week-end à la plage à embrayer pour ceux qui veulent bien finir l'été.

Pour ce qui me concerne, j'y vais avec la bénédiction de mon chef, pour défendre les couleurs d'Orange Business Services IT&Labs, youkaïdi. Pour l'occasion je pourrais mettre un T-Shirt orange, ça me changera...

Et comme mon chef est aussi un artiste passionné (et oui, on peut faire autre chose de sa vie que de l'informatique !), en guise de réponse à la question "est-ce que tu me sponsorise pour le JugSummerCamp ?", il m'a peint une toile !

Vous en avez, vous, un chef comme ça ?

Pas facile de suivre l'évolution de GWT, dont la version 2.1 poursuit son chemin de Milestone en Milestone...

En 2009, lors de la conférence Google I/O, la session Best Practices for GWT nous présentait les patterns MVP et Event Bus, et leur application en GWT. S'en est suivi une poignée d'implémentations opensource sur googlecode (ici, là ou là) pour mettre en pratique ces bons conseils.

Pour 2010, la roadmap GWT nous annonçait un MVP "officiel", d'où de nombreuses interrogations de la part de ces communautés et une grosse attente du côté du forum des utilisateurs. Vient alors la wave de "design collaboratif" de Ray Rayan, qui sème un sérieux trouble. On y parle de data-binding, d'une nouvelle mécanique client serveur, et pas tellement de MVP ... en tout cas pas dans les termes de 2009 !

Voici qu'arrive bikeshed et sa démo Expense. L'analyse du code de l'exemple montre une véritable usine à gaz dont on comprend mal les rouages, avec pléthore de classes techniques. On comprend rapidement que cette infrastructure doit in fine être générée par l'outillage. Tiens, justement, Google annonce son rapprochement avec Spring Roo sur ce sujet !

Et hier, poum, la nouvelle tombe : bikeshed est mis au placard et retiré du trunk - ce nom étrange était-il prémonitoire ? Il n'en reste que le mécanisme d'échange avec le serveur RequestFactory (basé sur JSON) permettant de faire le lien entre un backend JPA et des DTO utilisés dans l'IHM GWT, et la génération de squelette est déportée dans Spring Roo.

bikeshed était très - trop - ambitieux et complexe. Si un socle MVP fait bien sont apparition dans GWT 2.1 (com.google.gwt.app) il ne reprend pas le vocabulaire de la session Google I/O 2009 et manque cruellement de documentation, en étant de plus marqué "Expérimental". Je regrette que l'équipe GWT se soit embarquée sur un terrain aussi glissant, plutôt que d'inclure un développement externe qui a déjà fait ses preuves et porté par une communauté, comme ils l'ont fait au préalable avec l'incubateur. Les diverses approches MVP proposées en opensource ont fait leur preuves et ne vont même pas souffrir de la concurrence d'un framework mal documenté et expérimental, même intégré au SDK.

Je ne pense pas que cela empêche l'innovation : de très bonnes extensions comme gwt-fx ou gwt-dnd proposent des fonctionnalités qui étendent le scope de GWT vers plus d'interactivité. Flex comme Java/Fx proposent un mécanisme de data-binding pour lier le modèle à la vue en une ligne de code, ce que nous devons faire à grand coup de Handlers et d'événements sur l'Event-Bus en GWT. Des solutions de binding GWT existent pourtant de longue date en opensource : le support des ProperyChangeListeners JavaBean - élément clé du DataBinding - a été proposé dès GWT 1.4, mais le sujet reste non-prioritaire

Wait & See comme on dit ...