La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Du BI en SaaS gratuit pendant un an avec Tibco
• Sortie de la version 6 du portail open-source Liferay
• Spring facilite l’adoption d’AMQP

SOA

• Sortie d’Apache Camel 2.4

Le coin de la technique

• Scala 2.8 enfin finale !
• BigPipe : L’optimisation du temps de chargement selon FaceBook
• Twitter abandonne le stockage sur Cassandra

Actualité éditeurs / SSII

Du BI en SaaS gratuit pendant un an avec Tibco

Tibco vient de mettre à disposition sa suite Spotfire Business Intelligence en mode SaaS gratuitement pendant une année. Cette nouvelle solution permet d’importer des données depuis diverses sources, telles que les feuilles excel, les bases de données Access, Oracle, … et de les présenter dans des rapports interactifs, facilitant ainsi leur analyse.

Spotfire présente deux principaux avantages :

• Le mode SaaS de la solution accélère la construction des rapports BI et par conséquence leur mise à disposition au business, en éliminant tout le temps de mise en place des infrastructures habituellement nécessaires pour ce genre de projet.

• L’autre grande nouveauté mise en avant par l’éditeur est le côté social de sa solution. L’utilisateur de Spotfire, pourra partager ses rapports avec ses collaborateurs situés n’importe où dans le monde pour une plus grande interactivité.

Plus de détails sur le site de l’éditeur.

Sortie de la version 6 du portail open-source Liferay

Brian Chan, fondateur du projet Liferay, vient d’annoncer sur le blog de l’entreprise la sortie de la 6ème version du portail open-source.

Cette nouvelle version apporte son lot de nouveautés :

Gestion de contenu :

• Possibilité de partager du contenu entre différentes communautés grâce à l’ajout d’un scope Global, et d’un nouveau portlet d’administration (Asset Publisher Portlet).
• Utilisation de tags et de catégories pour une meilleure organisation et une recherche plus précise des informations.
• Gestion de la validation et de la parution des articles à l’aide d’un Workflow pouvant s’appuyer sur jBPM 3.0, puis prochainement sur la solution BPMS d’Intalio.

Administration du portail :

• Mise en place d’indicateur JMX pour le monitoring des performances des différents portlets déployés sur le portail.
• Ajout d’un système d’audit permettant d’enregistrer un certain nombre de mesures, pouvant être traitées ultérieurement (Audit Framework).
• Intégration avec les systèmes de reporting Jasper Reports et BIRT à travers le nouveau module Report Engine Framework.
• Simplification de l’administration du portail grâce à l’ajout d’une nouvelle console basée sur l’exécution de scripts.

Interfaces utilisateur :

• Ajout d’un nouveau composant appelé Dockbar qui améliore la navigation au sein des différentes communautés du portail.
• Possibilité de créer en un clic une nouvelle communauté ou une nouvelle page, en indiquant simplement le Template de page à utiliser.
• Réorganisation du portlet Document Library afin de simplifier la gestion des documents au sein du portail.

Extension et intégration :

• Ajout du module Generic Asset Framework, permettant d’interagir simplement avec les Workflows internes du portail ainsi que sur les options de sécurité.
• Intégration avec le framework Web Alloy UI, permettant de créer simplement des interfaces en HTML 5 s’appuyant sur les standards du W3C.
• Mise en place d’un framework de script permettant d’étendre les applications créées en dehors du portail.
• Nouvelle intégration native du portlet Document Library avec les solutions de gestion de documents et notamment Documentum, ainsi que l’amélioration de l’intégration avec Sharepoint.

Avec cette nouvelle version de Liferay Portal, Liferay continu d’étoffer son offre Portail et montre qu’il reste parmi les leaders du domaine. L’intégration avec les outils de BPM, de reporting et de gestion de documents du marché montre la volonté de la société de se diriger de plus en plus vers une solution ouverte et inter-connectée.

Pour plus d’information sur les nouveautés :

Toutes les nouvelles fonctionnalités de la version 6.0
La liste des changements sur le JIRA du projet

Spring facilite l’adoption d’AMQP

Comme on pouvait s’y attendre avec le rachat de RabbitMQ par VMWare, Spring intégre petit à petit des fonctionnalités facilitant l’adoption d’AMQP.

Le premier milestone de Spring AMQP 1.0.0 matérialise cet effort. Un gros point de satisfaction, Spring ne s’est pas contenté de fournir la partie cliente Java de RabbitMQ mais propose une réelle abstraction du protocole AMQ. Par contre la gestion des versions de la spécification reste un peu flou. Elle semble caler sur la version 0.8 tout en étant compatible avec la 0.9.1.

La distribution vient avec 4 modules : spring-amqp, spring-rabbit,spring-rabbit-admin et spring-erlang. Ce dernier est le plus inattendu et la documentation semble indiquer que le projet est expérimental. Pour rappel le serveur de RabbitMQ est implémenté en Erlang, un langage très perfomant sur les aspects concurrentiels.

La documentation, bien qu’incomplète, a la bonne idée de proposer plusieurs cas d’utilisation et laisse entrevoir un bon support pour Spring Integration. Cette nouvelle est quoiqu’il en soit une très bonne nouvelle pour l’adoption d’AMQP dans le monde Java. Par ailleurs Spring propose également une version .Net.

SOA

Sortie d’Apache Camel 2.4

La version 2.4.0 du projet Apache Camel est mise à disposition moins de 2 mois seulement après la sortie de la version 2.3.0. Elle vient compléter un changelog déjà très fourni sur la version précédente et apporte un certain nombre de corrections, d’améliorations et de nouveautés:

• Le support d’OSGI Blueprint via la création d’un namespace XML adapté permettant de définir des routes Camel. Ce namespace est pour le moment uniquement exploitable via l’implémentation Blueprint ‘Apache Aries’ utilisée par le projet ‘Apache Karaf’. A noter que la définition d’errorHandler n’est pas possible pour le moment.

• Un moteur de routage asynchrone non bloquant complet: tous les patterns d’intégration sont supportés ainsi que différents composants: JBI, NMR, CXF, Jetty et Netty.
• La version de Spring utilisée par Camel passe à la 3.0.3 marquant ainsi la fin du support de la branche 2.0 (La version 2.5 étant encore supportée). Le support de Spring Security pour sa part change également de version et passe à la 3.0.3.RELEASE.

La version 2.3.0 proposait déjà de nombreuses améliorations majeures telles que le support des Property placeholders qui manquaient cruellement, ainsi que le support d’un nombre conséquent de nouveaux composants (camel-exec, camel-nagios, camel-netty, camel-spring-spring-security, camel-crypto, …). Le projet Camel devrait à coup sûr continuer à faire parler de lui dans les prochains mois, tout en s’imposant un peu plus comme un acteur majeur dans le milieu des frameworks d’intégration.

Le coin de la technique

Scala 2.8 enfin finale !

Après plusieurs mois de bêtas et de release candidates, voici enfin venir la toute dernière version de Scala en finale à savoir la 2.8.0 ! Cette version quasi majeure est considérée par beaucoup comme une 3.0 tellement les nouveautés sont nombreuses.

Au menu : la nouvelle API collection, la spécialisation de type, une nouvelle implémentation des Array, les arguments nommés et par défaut, les Package Objects, le support des continuations ou bien encore le REPL amélioré. Les nouveautés étant nombreuses, je pense que cette nouvelle version mériterait bien son petit article, n’est-il pas ?

La mise à jour de Scala par votre IDE est possible, pour les autres le téléchargement de la distribution se passe par ici.

BigPipe : L’optimisation du temps de chargement selon FaceBook

Après les outils Yahoo (YSlow) et Google (Google Speed), c’est au tour de facebook de sortir de son chapeau une arme secrète pour réduire le temps de chargement des pages. Cette fois la solution est tout autre, ni Sprite CSS, ni JavaScript compacté, il faut paralléliser le chargement des pages par blocs. Avec BigPipe, le serveur envoi un bloc d’en-tête HTML qui s’occupe de charger la librairie BigPipe et fournit un template pour positionner les blocs appelés ‘pagelet’. Le serveur va ensuite envoyer toujours dans la même réponse, un bloc JavaScript par pagelet invoquant une méthode de chargement. L’objet Json fournit en paramètre contient le contenu HTML, l’URL de la CSS et celle du JavaScript nécessaire. Pendant que le navigateur charge une CSS et affiche un nouveau bloc HTML, le serveur est encore en train d’injecter ses pagelets.
Avec ce système, facebook a réussi à réduire le temps de chargement perçu par les utilisateurs. Ils précisent diviser par deux le temps de chargement pour la plupart des navigateurs. A l’exception de Firefox 3.6 qui n’a gagné que 22% de temps de chargement.

• L’article sur facebook engineering
• L’article sur InfoQ

Twitter abandonne le stockage sur Cassandra

L’affaire avait fait grand bruit en février : Twitter abandonne MySql pour stocker ses tweets sous Cassandra. Cet abandon donnait à Cassandra une légitimé hors des murs de Facebook. Malheureusement, le soufflet vient de brutalement retomber. Twitter fait machine arrière (ou plutot clarifie son propos, car il y a eu incompréhension (sic)) : les tweets sont stockés et continueront à l’être sous MySql. Cassandra est utilisé au sein de l’entreprise, mais pour d’autres besoins (via TechCrunch). Il se murmure que Cassandra serait au cœur de la prochaine étape de la monétisation de Twitter, un moteur d’analyse public en temps réel. Cette utilisation de Cassandra en interne est confirmée sur le blog de Twitter.

Alors, pourquoi ce changement de stratégie ? Nous n’allons certainement pas hurler avec la meute qui, dès cette annonce a fait fleurir des analyses plus ou moins fantaisistes sur la tenue à la charge de Cassandra, son exploitabilité, et sur tous les défauts que l’on peut prêter à un tel produit. Nous nous rangeons plutôt du coté de ceux qui pense que le timing est mauvais. Tout d’abord parce que Twitter subit actuellement de fréquents pic de charge qui entrainent des coupures de service. Cet effet Coupe du monde de football devrait néanmoins commencer à retomber. La continuité de service semble être la priorité actuellement en terme d’évolutions techniques et architecturales. Ensuite, nous l’avons déjà évoqué, Twitter entre dans une phase où l’entreprise tente de monétiser son service. C’est là aussi, n’en doutons pas, un poste de développement important, avec de nombreux services à créer et à roder.

Pour conclure, nous conservons notre confiance à Cassandra. Son abandon par Twitter (sur une fonctionnalité identifiée, celle du stockage des tweets) est une information stratégique d’importance (MySql garde la confiance d’un des plus grand stockeur du monde web), mais reste un choix stratégique et pas forcément technique. Nous continuerons donc à suivre avec attention les développements de Cassandra, et du NoSql en général.

Et, comme la dernière fois, cela se passera chez Xebia dans nos locaux d’Haussmann.

Voici le menu de la soirée avec une présentation d’Alexis Agahi et une autre de François Armand (annonce disponible ici) :

—

La seconde session aura lieu chez Xebia à 19h30 le mercredi 30 juin (et non plus le 17 ou le 24 comme prévu initialement, désolé pour la confusion).

Nous avons prévu deux présentations:

• La 1ère présentation sera « De Java à Scala : premier retour d’expérience » présentée par Alexis Agahi. La présentation (entre 40min et 1h) sera orientée developpeur Java et sera donc abordable pour tous.
• La seconde présentation, par François Armand, abordera les collections de Scala 2.8. Ce sera une présentation assez générale, avec les différentes classes et tout le bonheur qu’elles apportent.

Notez bien l’adresse :
Xebia
156 boulevard haussmann à Paris
Immeuble A
7e étage

Les places étant limitées, veuillez vous inscrire à l’adresse suivante : http://doodle.com/zds5ka5qqa3ndnp5.

—

—

Il s’agit d’une présentation que j’ai déjà faite au Boston Area User Group il y a quelques temps (et amélioré depuis). Pour le PSUG, j’aurai deux heures au lieu d’une. Je prévois donc de rendre cette présentation accessible à des purs java-istes ou des débutants Scala. J’utiliserai tout de même à la fin des fonctionnalités avancées de Scala, mais que je prétends faciles à l’utilisation.

Je ne ferai que du live-coding et je n’utiliserai aucun slide. Ce sera l’occasion de revenir sur des outils qui n’ont pas été vraiment explorés pendant la soirée Scala au ParisJUG (en particulier sbt).

Voici le plan de la présentation :

• je reviendrai d’abord sur le concept d’injection de dépendances et comment on fait ça à l’ancienne (ou plutôt, comment on ferait en Java). Je parlerai rapidement d’immutabilité et de typage statique ici.
• ensuite, je montrerai que les frameworks classiques venant du monde Java fonctionnent très bien avec Scala. Je laisse aux participants le choix du framework sur ce lien [1]. Je reviendrai notamment sur leurs limites dans le contexte de Scala.
• enfin, retour à du Scala pur (et pas forcément dur). Nous reviendrons entre autres sur le Cake Pattern. Mais surtout, nous jouerons ensemble avec le cocktail détonnant suivant : traits, mixins, structural typing et closures.

—

A noter toutefois que nous n’avions pas couvert sbt lors de la soirée Scala du Paris JUG mais que cet oubli (volontaire ) a été rattrapé par 2 fois avec une présentation générale du produit ainsi qu’un exemple de configuration pour Eclipse et IDEA.

Malheureusement pour les retardataires, la soirée affiche complet depuis plusieurs jours… Donc, pour ne pas rester sur la touche la prochaine fois, n’oubliez pas de vous abonner à la mailing-list du PSUG !

(surtout les miens )

Nous allons ainsi entrevoir le mécanisme de plugin de sbt ainsi que l'application de plugins sur un projet sbt. Pour celles et ceux qui connaissent un minimum ces deux environnements de développement, rien de bien sorcier : ajouter une facet Scala au projet, définir certains répertoires en tant que répertoires sources, d'autres en tant que répertoires de tests, définir _lib_managed_ en tant que dossier de librairies... Il est donc tout à fait possible de faire tout ceci à la main en quelques minutes. L'idée ici est vraiment de jouer avec quelques plugins sbt et les intégrer à un projet existant.

Si vous êtes plutôt Emacs ou Vim, je vous renvoie sur le site de sbt pour la configuration à adopter.

Eclipse

Nous allons importer notre projet à l'aide du plugin SbtEclipsify. Ce plugin prend en charge la création de tous les fichiers nécessaires à Eclipse .project,.classpath...) afin que le projet soit importable et intégralement configuré. Il n'est actuellement disponible sur aucun repository, il va donc falloir soit télécharger le Jar et le déposer dans son repository local, soit récupérer le projet et utiliser sbt pour le compiler et le publier en local. Nous partirons sur ce deuxième choix (pour utiliser quelques petites commandes sbt).

Tout d'abord, nous allons récupérer le projet à l'aide de la commande git clone :

Ensuite, nous allons démarrer sbt et faire un update pour mettre à jour toutes les dépendances du projet :

Nos dépendances étant à jour, nous allons pouvoir compiler et publier le projet à l'aide de la commande publish-local (image tronquée) :

Maintenant que le Jar est disponible dans notre repository, nous allons pouvoir configurer notre projet avec cette nouvelle dépendance. Pour cela, créons le fichier project/plugins/Plugins.scala et ajoutons le plugin sbt-eclispsify :

Dernière étape avant de tout builder : modifier notre fichier projet, dans la classe project/build/MyProject.scala, pour marquer notre projet en tant que projet eclipsifiable à l'aide du trait Eclipsify :

Voilà, tout est prêt, démarrons sbt et lançons la commande eclipse après avoir mis à jour nos dépendances pour notre projet (à l'aide de la commande update) :

That's all ! Il n'y a plus qu'à faire un import dans Eclipse de votre projet. A partir de maintenant, la commande eclipse ne devrait plus vous servir. Il faudra dès lors passer par reload lors de modifications concernant vos plugins ou vos dépendances pour mettre à jour votre contexte sbt et bien sûr update pour la mise à jour de vos dépendances.

A noter que d'autres plugins existent :

• sbt-eclipse-plugin : ce plugin n'est ni plus ni moins qu'un container de type classpath qui pointe vers le dossier lib_managed. L'outil fonctionne très bien mais les manipulations sont à effectuer à la main et aucune opération en ligne de commande (pour automatisation) n'est disponible pour l'instant. A surveiller donc ;
• IvyIDE (avec la procédure d'installation ici).

IntelliJ IDEA

Plusieurs plugins existent et, pour ma part, j'ai choisi le plugin sbt-idea-plugin. A noter que celui-ci fournit son propre repository maven donc pas de git clone sur le projet avec un publish-local comme pour SbtEclipsify. Tout se fait cette fois-ci très simplement !

Comme pour SbtEclipsify, le plugin fournit un trait qu'il faudra ajouter à sa classe projet qui lui permettra d'avoir la commande idea disponible dans le shell.

Il faut donc tout d'abord se rendre dans la classe project/plugins/Plugins.scala et ajouter ces quelques lignes. Elles ajouteront un repository distant et la dépendance du plugin :

Maintenant que notre plugin est prêt à l'emploi, nous allons l'ajouter dans la configuration de notre projet (toujours au niveau de project/build/MyProject.scala). Cela nous donne :

Grosse différence avec Eclipse : le plugin fonctionne par défaut, même si l'on a qu'un seul project, comme une arborescence de projets. Ainsi, nous aurons un projet parent composé de sous-projet(s). Pour utiliser ce plugin, nous allons donc (cf. code ci-dessus) créer un projet MainProject en tant que conteneur de projet en étendant ParentProject. Ensuite, nous créerons dans ce projet sbt un projet de type DefaultProject qui contiendra notre code ({{src/main/scala}}...).
Notez que les deux projets utilisent le trait IdeaPlugin. En effet, IntelliJ IDEA gère parfaitement l'arborescence de projets. Nous aurons donc les deux projets importés dans l'IDE avec la vue projets qui nous affichera le projet parent et notre projet.

A ce niveau, comme pour Eclipse, tout est prêt ! Donc un update et cette fois-ci un idea pour lancer le plugin :

Et le résultat avec notre projet parent contenant notre sous-projet une fois importé dans IntelliJ IDEA (par le fichier .ipr) :

Les deux ?

Et si tout comme moi, cela vous arrive de switcher de l'un à l'autre selon votre humeur (tiens aujourd'hui j'ai envie de faire du Eclipse ), vous pourrez bien évidemment configurer votre projet pour qu'il accueille ces deux environnements de développement. La configuration finale sera un mix de ce que l'on a vu précédemment. En ne prenant pas le projet parent en tant que projet Eclipse (car il ne les gère pas très bien), cela nous donne tout simplement :

Cette configuration fonctionne out-of-the-box pour IntelliJ IDEA, par contre pour Eclipse un problème de build path subsiste. Il est directement lié à cette arborescence de projets (module / sous-module) qui n'est actuellement pas géré par le plugin :

Il faudra donc modifier à la main le build path de notre projet. Une fois celui-ci modifié, le projet sera opérationnel pour Eclipse et vous n'aurez plus qu'à faire des sbt update pour mettre à jour vos dépendances :

Dernière chose, entre la configuration pour avoir les deux plugins et celle d'IntelliJ IDEA standalone : notez la différence concernant le sous-projet MyProject avec non plus l'utilisation directe d'une nouvelle instance de DefaultProject mais la création et l'instanciation d'une nouvelle classe MyProject qui étend DefaultProject. Cela va nous permettre de définir des dépendances uniquement au niveau du sous-projet et ainsi ne pas tout mettre au niveau du projet parent. Il est dès lors possible d'ajouter plusieurs sous-projets à MainProject et ainsi se retrouver avec le même type d'arborescence de modules que l'on retrouve dans nos projets maven.

Vous pouvez toujours récupérer le petit projet scala-samples qui possède cette double configuration idea/eclipse.

Actualité éditeurs / SSII

• SpringSource se dote d'un cache distribué

Le coin de la technique

• Jarlsberg, la sécurité en s'amusant
• Multi-Catch confirmé dans le projet Coin

Evènements de notre communauté en France et à l'étranger

• C'est le printemps, les User Groups fleurissent

Actualité éditeurs / SSII

SpringSource se dote d'un cache distribué

VMware vient de faire l'acquisition de la société GemStone Systems, éditeur de la solution de cache distribué GemFire. Elle sera gérée désormais sous la houlette de SpringSource. Ce nouveau rapprochement s'inscrit dans la stratégie affichée de la firme de fournir une plateforme complète de cloud destinée aux applications Java.

Par ailleurs, dans une interview donnée à InfoQ, Rod Johnson affirme que le framework Spring développera les abstractions nécessaires à l'intégration de ce type de produit, comme c'est déjà le cas pour les RDBMS, les broker JMS, etc via les Templates Spring, et pourrait permettre l'intégration d'autres solutions de data-grid comme Oracle Coherence ou encore Terracotta.

Le coin de la technique

Jarlsberg, la sécurité en s'amusant

Xss, DoS, Xsrf... Des acronymes barbares qui désignent des failles de sécurité courantes dans nos applications Web. Si vous voulez mieux les connaitre, et ainsi vous en protéger, le nouveau projet de Google Labs, Jarlsberg (fromage norvégien), est pour vous.
Et comme le meilleur moyen d'apprendre est de faire, Google met à votre disposition un site truffé de failles de sécurité que vous pourrez hacker à loisir.
Les failles sont organisées en fonction de leur type :

• Cross-site Scripting (XSS)
• Cross-site Request Forgery (XSRF)
• Cross-site Script Inclusion (CSSI)
• Manipulation de l'état du client
• Traversée d'arborescence
• Déni de Service (DoS)
• Exécution de code
• Vulnérabilité de la configuration
• Vulnérabilités AJAX

Pour venir à bout de ces failles, il existe trois types de tests :

• Tests boite noire : l'utilisateur ne connait pas le fonctionnement interne du site, il tente de hacker le site en passant par les pages exposées
• Tests boite blanche : le code de l'application en python est connu par le hacker
• Tests boite grise : un panaché des deux précédentes méthodes

Ces tests sont servis pour une large variété d'outils de hacker :

• Snippets HTML
• Upload de fichier
• Administration du site
• création de nouveaux comptes utilisateur
• Language de templating Jarlsberg
• Injection AJAX

L'approche est très pédagogique, avec une succession de challenges à résoudre. Par exemple, le premier de ceux ci : pouvez vous uploader sur le site un fichier qui vous permettra d'exécuter un script sur le serveur d'application ? Chaque challenge propose des indices, une manière d'exploiter la faille et une correction.
Une plongée passionnante dans l'univers des hackers.

Avant de vous lancer dans ce Google Lab, nous vous conseillons la lecture de l'article de Christian Heilmann.

Bien sûr, ces trucs et astuces ne doivent pas être reproduits à la maison, vous pourriez tomber sous le coup de la loi.

Multi-Catch confirmé dans le projet Coin

Finalement, après plusieurs hésitations, Joe Darcy confirme la possibilité de rassembler plusieurs catch d'exceptions dans une même clause dans Java 7. Ainsi il sera possible d'écrire:

Les discussions portaient sur la deuxième partie de cette proposition, le renvoi ( rethrow ) des exceptions. En effet il peut arriver qu'une exception soit renvoyée après avoir été attrapée. Dans ce cas elle doit apparaître dans la signature si c'est une exception vérifiée ( checked ). Par exemple :

Ce que propose le projet Coin, c'est de vérifier les exceptions possibles dans le bloc try et de donner la possibilité dans la signature de la méthode de renvoyer le type précis des exceptions. Pour cela on utilise le modifier final. Ce qui donne :

Ceci permet d'avoir une signature plus précise et de pouvoir remonter une exception facilement. Les difficultés de cette proposition ont tourné autour du type d'exception qui se trouve dans la clause catch dans le cas où le type n'est connu qu'au Runtime.

Cette proposition en ravira plus d'un mais fera aussi sourire ceux qui prônent la suppression des exceptions vérifiées. Pour finir, un petit cas limite amusant de cette proposition, relevé par Stephen Colebourne :

Evènements de notre communauté en France et à l'étranger

C'est le printemps, les User Groups fleurissent

Avec notre plateforme de prédilection, Java, qui s'ouvre de plus en plus à de nouveaux langages, il fallait bien que la communauté suive. Nous assistons donc ces derniers temps à l'éclosion de nouveaux User Groups. Le premier à bourgeonner fut le Scala User Group (attention, pas "SUG" car le nom est déjà pris) qui a pris ses racines lors de la soirée Scala organisée par le Paris JUG. Cette semaine, c'est Guillaume Laforge, Groovy project lead et Cast Codeur émérite, qui a annoncé sur la mailing liste du Paris JUG la création du Groovy User Group. La première rencontre est d'ores et déjà prévue le 10 juin.
Ces nouveautés s'inscrivent dans la lignée de ce que nous avons déjà observé avec la multiplication des JUGs: la communauté s'organise pour partager, lier connaissance et évoluer. Après les différents JUGs centrés sur Java, il n'est pas étonnant de voir des User Groups se créer pour rassembler les personnes intéressées par les nouveaux langages de cette plateforme.
Par la suite, ces langages resteront-ils sous la coupe des divers JUGs ou allons nous assister à la création du "Marseille Groovy User Group" ou du "Lyon Scala User Group" ?