Grâce à ce guide, vous pourrez installer le nouveau (futur) mode de développement et de débogage de Gwt. Il est bien plus rapide que le classiqueDev Mode et tout aussi puissant !
Qu'est-ce que le Super Dev Mode ?
Le SuperDevMode est le remplaçant du DevMode, permettant de lancer une application en cours de développement, et même de la déboguer depuis Eclipse.
Pour la petite histoire, c'est le troisième workflow de débogage pour GWT. Avant la version 2.0, GWT proposait un navigateur embarqué (et non standard, ce qui rendait l'expérience souvent douloureuse). GWT 2.0 apporta le "DevMode" (ou OOPHM, pour Out Of Process Hosted Mode) qui permit par un système de plugin navigateur de déboguer une application directement dans les grands navigateurs du marché (IE, Chrome, Firefox). Avec le DevMode, l'application tourne directement dans la JVM (la compilation Java vers Javascript n'ayant pas encore eu lieu) mais c'est le navigateur qui se charge de l'affichage. Pour déboguer, l'IDE est paramétrée pour s'accrocher à la JVM, comme une application Java standard.
Alors pourquoi un troisième mode de développement ?
A cette question, plusieurs réponses :
- L'architecture JVM + Plugin + Navigateur a le désavantage d'être très lente. En effet à chaque fois que l'application interagit avec le navigateur (positionner un texte dans le DOM, ajouter un handler d'événement, réagir à ceux-ci), un échange a lieu entre la JVM et le navigateur par l'intermédiaire du plugin. Comme une application Web passe la majeure partie de son temps à interagir avec le navigateur, il s'en suit que la lenteur du DevMode devient rapidement problématique pour développer une application conséquente.
- Au bout de quelques rechargements, le DevMode consomme toute la mémoire allouée. Le runtime Java de Gwt ne sait en effet pas quand le navigateur libère des resources (éléments DOM, objets JavaScript). Le DevMode ne sait donc pas quand libérer les objets Java correspondants et ils s'accumulent indéfiniment. Ce problème est malheureusement insoluble.
- Le dernier argument, qui assène le coup de grâce au DevMode, vient de l'API native utilisée par le DevMode : la NPAPI. Cette API qui permet d'exécuter du code natif dans le navigateur a été créée dans les années 90 pour Netscape 2 (préhistoire !). Et elle est aujourd'hui dépréciée par les fournisseurs de navigateurs (Google et Mozilla - Microsoft ne l'ayant jamais réellement supportée) pour plusieurs raisons, principalement de sécurité. Chrome et Firefox arrêtent son support dans l'année 2014. Il existe d'autres API pour interfacer le navigateur avec du code natif. En effet, mais selon Ray Cromwell, celles-ci ne permettent pas faire d'appels ré-entrants et ne sont donc pas de bons candidates pour supporter le DevMode.
Nouvelle architecture de débogage avec GWT
Le nouveau mode de développement s'appelle le Super Dev Mode. Il est supporté par le CodeServer et le standard Source Maps. L'idée est d'avoir un compilateur en mode super rapide et incrémental embarqué dans un serveur Web produisant non seulement le javascript à partir du code Java mais aussi les informations Source Maps de façon à alimenter le navigateur avec les sources Java à l'origine de la compilation. Ainsi, on ne fera plus tourner l'application dans la JVM mais celle-ci sera compilée à la volée en Javascript et exécutée sous cette forme dans le navigateur. L'application en développement s'exécutera donc à sa vitesse (presque) nominale (pour la production, on ajoute en général toutes les optimisations possibles, alors qu'en développement on s'intéresse surtout à la vitesse de compilation).
Source Maps est un standard permettant aux nombreux outils de compilation ciblant du Javascript de générer les informations nécessaires pour associer les lignes des fichiers source aux lignes des fichiers Javascript générés par la compilation. Un navigateur compatible peut alors afficher le code source dans ses outils de développement directement, au lieu d'un code Javascript incompréhensible (car souvent "minifié").
Jusqu'à là, tous les outils présentés sont compatibles avec tous les navigateurs modernes :
Ainsi nous pouvons avec n'importe quel navigateur déboguer le code Java directement dans le navigateur.
SDBG - Le plugin de débogage pour Eclipse
Ce plugin est adapté du plugin de développement des outils Dart (comme quoi contrairement à certaines rumeurs Dart ne tue pas Gwt mais le sauve !). Il permet de déboguer une application Source Maps et plus particulièrement Gwt avec (presque) la même aisance que celle donnée par l'ancien Dev Mode.
Il permet de créer un launcher Eclipse qui va lancer Chrome. Grâce à son interface de débogage distant, le plugin SDBG va "piloter" Chrome, et donner à l'utilisateur des possibilités presque identiques au débug Java. Le panneau d'inspection des variables d'Eclipse affiche seulement les noms Javascript. Dans la plupart des cas, ceux-ci sont bien lisibles et vous pouvez faire la transcription mentalement.
Voici un petit guide d'installation de ces outils :
Installation
Création du projet de démonstration de Gwt en ligne de commande avec l'option maven :
webAppCreator -out c:\tmp\TestGwtSdbg -maven fr.lteconsulting.testsdbg
Editons ensuite le pom.xml :
On utilise Java 7 :
< maven .compiler.source="">1.7
< maven .compiler.target="">1.7
Ajouter dans la zone des dépendances
< dependency>
< groupid>com.google.gwt
< artifactid>gwt-codeserver
< version>${gwtVersion}
Et retirez le scope test de l'artefact gwt-dev :
< dependency>
< groupid>com.google.gwt
< artifactid>gwt-dev
< version>${gwtVersion} < !-- < scope>test< /scope> -->
Changer la version de Gwt pour le build de nuit : 2.7-SNAPSHOT. Tout ceci ne fonctionne bien qu'avec la 2.7-SNAPSHOT. La 2.6.1 a des bug source maps ! Et surtout elle n'a pas la dernière amélioration, l'option "-XcompilePerFile".
< gwtversion>2.7-SNAPSHOT< /gwtversion>
Pour obtenir ce snapshot, il faut ajouter le repository
Dans la zone des plugin de build, changez la version du gwt-maven-plugin :
Faire ensuite un mvn install pour télécharger le sdk. Ceci peut prendre pas mal de temps...
Importation du projet dans Eclipse
Importez le projet maven ainsi créé dans Eclipse
Activation du Super Dev Mode
Assurez-vous que le fichier du module gwt de pl'application contient bien < add-linker name="xsiframe" /> (plus tard ceci sera surement activé par défaut).
Création du launcher CodeServer
C'est le compilateur Gwt en mode ultra-rapide intégré dans un mini serveur web. Il va recompiler l'application à la demande.
Créer le launcher de type Java Application dans Eclipse.
Spécifier le projet courant et la classe main : com.google.gwt.dev.codeserver.CodeServer.
Dans les parametres de ce launcher, indiquez le nom complet du module à servir ainsi que l'option pour activer l'option de compilation par fichier : "fr.lteconsulting.testsdbg -XcompilePerFile"
Dans la section Classpath, sélectionnez User Entries, cliquez sur le bouton "Advanced...", choisissez "Add folders", un Folder (advanced...->Folder) pointant vers les sources java du projet (${projet}/src/main/java).
Lancez le launcher que l'on vient de créer, aller à la page "http://localhost:9876/" et glisser les deux boutons "DevMode on" et "DevMode off" sur la barre des préférés du navigateur.
Arrêter le launcher, votre navigateur est configuré.
Installer le plugin SDBG
Il ne reste maintenant plus qu'à installer le plugin SDBG, celui qui va nous permettre de déboguer l'application GWT directement depuis Eclipse (alors que rappelons le, l'application tourne sous forme de Javascript dans le navigateur).
Télécharger l'archive la plus récente sur la page https://github.com/sdbg/sdbg/releases (celle-ci par exemple).
Dans Eclipse, ouvrez le menu Help, choisissez Install new software..., puis Add..., et enfin "Archive...". Sélectionnez l'archive tout juste téléchargée et procéder à l'installation. Il faudra même redémarrer Eclipse.
Création du launcher SDBG
Nous allons maintenant créer le launcher pour SDBG.
Ouvrir la dialogue "Run configurations", et créer un launcher du type "Launch Chrome". Dans celui-ci, sélectionner "URL", renseigner l'url d'accès à l'application et le projet associé.
Enregistrer ce launcher.
Lancer et déboguer une application
Voilà, nous avons fini la partie configuration, il ne nous reste plus qu'à lancer tout cela !
Avant de continuer, je vous conseille de lancer une compilation complète de votre application. Nous allons en effet souvent recharger la page et si vous n'avez jamais compilé, vous aurez la fenêtre "Your module may need to be recompiled", ce qui va être rapidement désagréable.
Lancement du serveur
Premièrement, lancez le serveur. Il peut s'agir de JBoss ou autre, ou bien simplement du Jetty embarqué dans DevMode classique (il n'y aura qu'à ne pas utiliser la partie ?gwt.codesvr=localhost:9997 de l'url).
Lancement du SuperDevMode
Une fois l'application servie, il faut lancer le launcher Code Server. Celui-ci une fois lancé doit indiquer qu'il sert bien les requêtes à l'adresse http://localhost:9876.
Pour vérifier que tout fonctionne bien, avec Chrome ou Firefox, ouvrez la page de votre application , cliquez sur le bouton "DevMode on" que vous avez glissé dans votre barre des favoris auparavant, puis sur le bouton "Compile". Le module doit se compiler et la parge doit se recharger.
Normalement, avec les outils de développement de Chrome, vous devriez retrouver les sources Java :
Vous pouvez fermer cet onglet, le plugin SDBG nous ouvrira le nôtre automatiquement.
Lancement du launcher SDBG
Maintenant, placez un breakpoint dans le code Java, et lancer le launcher SDBG en mode débug. Chrome s'ouvre (si ce n'est pas le cas, ajouter -Dchrome.location="chemin vers Chrome" dans votre eclipse.ini et redémarrer). Cliquez sur le bouton "DevMode on", puis sur le bouton "Compile" qui s'affiche. Normalement la page se recharge et le breakpoint est déclenché. La première fois de chaque session, un premier rechargement semble nécessaire...Vous pouvez maintenant modifier le code Java, enregistrer et rappuyer sur "DevMode on" dans le navigateur. Vos changements sont recompilés et actualisés !
Voilà ! Vous avez découvert le nouveau workflow du nouveau mode de développement GWT.
Avantages / Inconvénients
- il y a moins de chance d'avoir une différence de fonctionnement entre la phase de développement et la production.- debug sans plugin navigateur, donc toujours à la page
- debug des navigateurs mobiles
Futur
- l'équipe de développement de SDBG prévoit le remplacement de code à chaud (pas de F5 nécessaire pour bénéficier du nouveau code !).- pour l'instant, Source Maps ne supporte pas l'inspection des variables. Ceci est en cours (de réflexion...).
- bientot RemoteDebug, une api de debug unifiée pour tous les navigateurs permettra d'utiliser SDBG avec tous les navigateurs.
Test : kjhq jh< k jhg>jhgkJhgk jHgk> jh g> >