I. SpringSource France

Quels sont les services que SpringSource France va proposer ?

Nous proposons trois types de services :

  • Des formations, que nous proposons déjà très régulièrement à Paris. Ces formations donnent accès gratuitement à la certification SpringSource.
  • Du support, à la fois pour le développement et la production. A noter que pour nos clients, nous fournissons également un certain nombre de produits supplémentaires tels que SpringSource Tool Suite, SpringSource Application Management Suite et SpringSource Advanced Pack for Oracle.
  • Du conseil, sous la forme d'interventions courtes : par exemple pour un audit, un POC ou une expertise dans un domaine particulier.

Quand et dans quelles circonstances avez vous été contacté par SpringSource ?

Je connais Rod Johnson depuis plusieurs années, depuis qu'il a accepté de rédiger la préface du livre que j'ai co-écrit Spring par la pratique" (publié chez Eyrolles en 2006). J'ai donc eu tout simplement un coup de téléphone de l'"executive vice président" de SpringSource, qui m'a proposé de monter la filiale française.

Est-ce que toutes les formations officielles de SpringSource vont pouvoir être suivies en français ?

Oui pour les formations "standard", en particulier pour "Spring Core" qui est de loin notre formation la plus populaire. Par contre, pour des formations plus pointues, nous seront obligés de faire appel à des consultants étrangers : je pense par exemple à la formation "Spring.NET" que nous faisons le 18 juin prochain. J'en profite pour préciser qu'il y a bien une version de Spring pour .NET, et qu'elle est également développée par SpringSource.

Comment SpringSource France va mettre en avant Spring sur la scène francophone ?

Nous allons participer activement aux forums et blogs traitant de Java et de Spring, tels que developpez.com. Nous allons également participer à un certain nombre d'événements, comme le Paris Java User Group, où nous serons présents à la soirée Spring qui aura lieu le 10 juin (plus d'informations sur ParisJUG ). Nous serons également présents à SpringOne (lien) les 11 et 12 juin, en collaboration cette fois-ci avec le Belgian Java User Group.

Est-ce que SpringSource France sera limité à la France ou bien s'occupera t'elle des autres pays francophone limitrophes ( Belgique, Luxembourg ) ?

Nous ne sommes effectivement pas limités à France, nous avons d'ailleurs déjà travaillé en Belgique, au Luxembourg et en Suisse! C'est donc déjà une réalité.

Est-ce que SpringSource France va rentrer dans une période d'embauche, afin de monter une équipe ?

Oui nous allons certainement avoir une phase d'embauche d'ici quelques mois, cependant l'équipe actuelle est déjà suffisante pour le démarrage de la société.

II. Spring Framework

Après les nouveautés de Spring 2.5 qui a mis la barre très haut, qu'est-ce que Spring 3.0 va apporter de nouveau ?

Aujourd'hui l'innovation provient plutôt de tout ce qui tourne autour d'OSGi, comme Spring Dynamic Modules for OSGi et SpringSource Application Platform. Il devrait y avoir là beaucoup de nouveautés très intéressantes.

Nous allons également proposer beaucoup de choses au niveau de nos framework Web, avec l'arrivée de Spring Faces et Spring JavaScript en particulier.

Enfin, il y aura de nouvelles annotations et un support de REST nettement plus poussé.

Avec Covalent, SpringSource à effectué un rachat stratégique. Etait-ce un évènement unique, ou bien d'autres acquisitions du même genre sont prévues ?

Aucune idée! Je peux juste dire que la société est très solide financièrement, et que si nous voulions réitérer ce genre d'acquisition ce serait tout à fait possible.

III. SpringSource Application Platform

Pour ceux qui seraient passés à coté de LA grande nouvelle de SpringSource, qu'est-ce que SpringSource Application Platform ?

SpringSource Application Platform (S2AP) est une nouvelle plateforme applicative Open Source que SpringSource vient de dévoiler. S2AP permet de développer et de déployer des applications Java sous forme de modules : cela les rend incroyablement plus simples à réaliser, et démocratise une technologie (OSGi) qui jusqu'à présent n'était réservée qu'à quelques experts.

Au niveau de la production, cela signifie que vous pouvez ajouter ou changer des modules à chaud, donc sans redémarrer toute l'application, et également avoir plusieurs versions du même module en parallèle. Des choses qui sont impossible à réaliser dans un serveur d'application JEE traditionnel monolithique.

C'est réellement révolutionnaire, et c'est le fruit d'un travail très important réalisé par nos équipes de développement.

Ce n'est pas la première fois que Spring "s'attaque" au standards Java EE, du fait que Spring Framework à été développé pour combler les manques et la complexité de Java EE, spécialement des EJB. Est-ce que la sortie de ce nouveau type de serveur à pour but de remplacer le Java EE tels que l'on le connaît ?

Nous ne sommes pas contre les standards, juste contre les mauvais standards :-)

S2AP suit donc les standards utilisés couramment tels que les servlets, JPA, JDBC, JMS, etc... mais ne reprend pas les EJB 1.x et 2.x, par exemple.

D'autre part, nous sommes convaincus que les serveurs d'applications sont trop lourds, trop compliqués, trop monolithiques. S2AP se veut petit, souple, agile, modulaire en fonction des besoins de l'utilisateur. Et il fournit également ces mêmes qualités aux applications qui sont déployées dessus.

Pourquoi aujourd'hui doit-on encore tolérer des serveurs d'applications qui mettent un temps infini à démarrer, sur lesquels il faut déployer des WAR ou des EAR monoblocs? Ce n'est pas pour rien qu'aujourd'hui Java est challengé par un certain nombre de nouvelles technologies qui sont plus souples, plus agiles, et qui proposent de faire gagner un temps important en développement et en production.

Ce que nous proposons, c'est une plateforme qui ajoute aux qualités intrinsèques de Java (robustesse, stabilité) et de Spring (simplicité, performance, testabilité) les notions de souplesse et de modularité. En ce sens, oui nous proposons un nouveau type de serveur, et nous comptons bien le voir remplacer les serveurs d'applications traditionnels.

Quelles seront les différences entre la version gratuite et la version commerciale de Spring Application Platform ?

Pour l'instant il n'y a pas encore de version commerciale! Ce n'est pas encore décidé, mais il s'agira au minimum des fonctionnalités de monitoring proposées par SpringSource Application Management Suite (qui n'est d'ailleurs aujourd'hui disponible que pour nos clients, cela ne va donc pas changer l'existant). Sinon, cela concernera uniquement des fonctionnalités très avancées qui n'intéresseront que les grandes entreprises.

Auriez vous des plans pour standardiser au moins avec l'alliance OSGi les nouveautés introduits par Spring Application Platform (format PAR, format libd et les librairies, les nouvelles entêtes dans le manifest, etc.) ?

Pas à ma connaissance, mais j'en entends beaucoup parler.

Est-ce que la version finale apportera encore plus de fonctionnalités, voir une compatibilité JEE 6 ( vu que SpringSource contribue à la spécification de celle-ci ) ?

Je pense que ce sera plutôt pour la version 2 de la plateforme, mais là encore ce n'est pas encore décidé. Ce qui est certain, c'est que nous ferons tout notre possible pour être certifiés sur les profils A et B de JEE 6. La spécification n'étant pas encore finale nous ne pouvons pas encore le promettre, mais c'est très clairement notre objectif.

De par Rod Johnson, SpringSource est impliqué dans la JSR concernant JEE6. Est-ce que par la, vous allez tenter d'imposer les concepts de S2AP ? Est-ce que vous allez vous concentrer sur certains domaines de JEE 6 en particulier ? Par exemple, les profils Web qui seront disponible pour S2AP ?

Nous allons nous concentrer sur les profils A et B, mais pas du tout sur le profil C (non, nous n'allons pas supporter les EJB 1.x par exemple!!). Concernant nos concepts, je ne pense pas qu'IBM, Bea, Oracle ou JBoss soient prêts à nous suivre sur ce sujet. Il n'y aura donc pas de standardisation avant longtemps.

Suite à la polémique soulevée par la license de SpringSource Application Platform (GPL 3), Pourriez-vous, en termes simples, expliquer à la communauté ce qu'ils peuvent faire et ce qu'ils ne peuvent pas faire avec la plateforme ? Et par exemple, est ce qu'une société peut installer SSAP chez un client pour faire tourner un produit payant par exemple ?

S2AP est sous licence GPL 3, c'est à dire que c'est un produit Open Source. La polémique provient du fait que la license GPL 3 est dite "virale" : tout produit distribué dérivant d'un produit GPL 3 devient lui aussi sous licence Open Source.

Pour que votre produit devienne lui aussi sous licence GPL3, il faut 2 conditions : qu'il soit redistribué (la GPL 3 clarifie bien qu'une application Web ne représente pas une redistribution d'un logiciel) ET qu'il soit un travail dérivé. Une application déployée sur S2AP, de mon point de vue, ne représente normalement pas de travail dérivé.

Pour répondre à votre exemple, aucune de ces deux conditions n'est remplie en théorie. En tant que SSII ou client final, vous ne devriez donc pas avoir de problème à déployer une application propriétaire sur S2AP, et ce sans passer par SpringSource ou redonner quoique ce soit à la communauté Open Source.

Cependant, je ne suis pas avocat : ceci ne constitue donc pas une affirmation ou une recommandation de ma part ou de celle de SpringSource. Je vous encourage donc à aller sur notre site, où un FAQ spécifique a été mis en place ( Lien)

Je précise qu'il n'y a aucun changement de licence au niveau du framework Spring, qui reste sous licence Apache. Vous pouvez donc tout à fait le redistribuer ou lui apporter des évolutions, sans que votre code ne devienne Open Source. La plateforme et le framework sont deux produits totalement indépendants.

Au niveau du tooling, est-ce que SpringSource va s'investir encore plus dans Eclipse ( via Eclipse IDE / SpringSource Tool Suite ), ou bien s'ouvrir aux autres outils populaire ( NetBeans, Idea, .. ) ?

Nous sommes membres de la fondation Eclipse, et notre IDE (SpringSource Tool Suite) est basé sur Eclipse. Donc oui, nous allons très clairement continuer d'investir dans Eclipse. Je précise que notre IDE utilise entre autres le très bon plugin SpringIDE, développé par Christian Dupuis (SpringSource Allemagne).

Cela a forcément comme conséquence que nous n'allons pas beaucoup investir sur les autres IDEs, ce qui ne veut pas dire que l'on ne peut pas les utiliser pour développer des applications Spring. Certains, comme Intellij IDEA, ont d'ailleurs un support de Spring tout à fait satisfaisant.

En ce qui concerne la révolution OSGi, comment SpringSource voit le futur des outils actuels ? Maven, Ivy, Ant pourront-ils toujours être utilisé ? Les systèmes d'intégration continue sont-ils adaptés à ce nouveau type de développement ?

Nous proposons un support complet de Maven 2 et de Ant+Ivy. Notre repository peut d'ailleurs être utilisé avec ces deux outils : http://www.springsource.com/repository/. Donc oui, ils peuvent être utilisés sans problème, et les systèmes d'intégration continue fonctionnent toujours sans problème.

Nous proposons toujours un modèle de développement basé sur des POJOs, la plateforme ne vient absolument pas modifier cela.

Pour information, nous utilisons nous-mêmes Ant+Ivy pour construire la plateforme.