1. Bonjour Jérémie, peux-tu te présenter ?
Volontiers. Jérémie, j'habite en Suisse du côté de Zurich. Je travaille pour une entreprise Suisse qui s'appelle BSI, principalement active en Suisse et en Allemagne, et qui fait des applications métier plutôt à destination des banques, des assurances, gestion de clientèle, de call centers.
C'est çà, on est là principalement pour présenter ce framework. C'est un projet qu'on a lancé dans la Fondation Eclipse il y a 3 ou 4 ans. Depuis ce temps-là, on participe aux différents release train Eclipse. En ce moment on est en train de préparer la version prochaine, 2014. Puis, on est là pour rencontrer la communauté, parler du projet, le présenter.
En fait, ça va un peu au-delà. La principale particularité d'Eclipse Scout, c'est qu'au lieu de programmer contre une librairie graphique, on va plutôt définir nos formulaires - puisqu'on fait principalement des formulaires qui transportent des données qui viennent du serveur et qu'on va afficher pour notre utilisateur. Et au lieu de programmer par exemple en SWT, on va définir un modèle d'application, en disant "j'ai tel formulaire avec tel champ, telle table, qui contient cette colonne", et ce modèle va être interprété et rendu au runtime par différentes librairies. Donc si on fait du Eclipse RCP, on a un rendu pour SWT. Mais en fait, on a aussi historiquement toujours travaillé avec Swing, donc on a un moteur de rendu pour Swing. Dans ces cas-là, on embarque le runtime Eclipse mais sans la partie workbench. Et puis il y a quelques années, des clients nous ont demandé si on pouvait faire du web. Donc on s'est tourné vers Eclipse RAP, un autre projet de la Fondation qui permet de facilement importer des apllications vers le web, qu'on a utilisé pour avoir notre troisième moteur de rendu.
4. Est-ce qu'il a d'autres moteurs de rendu de prévus ?
Evidemment on y réfléchit. Là, Oracle est en train de montrer JavaFX. Nous on observe, on regarde, on a lancé des petites études en partenariat avec des universités, mais on va dire qu'on attend qu'il y aie une plus grosse adoption pour s'y mettre un peu plus à fond. On réfléchit aussi peut-être à d'autres possibilités, notamment au niveau du web, mais tout ça, ce sont des projets. Quand la pression et les besoins des clients seront là, on mettra le paquet pour développer un nouveau moteur de rendu. Ce qui est important - un collègue en parlera demain pendant un talk - ce sont les applications qu'on programme. Ces applications, on a regardé, en gros sont là pour 10-15 ans, et dans le domaine de l'interface utilisateur, il y a plutôt un nouveau truc tous les 4-5 ans. Eclipse Scout permet de dissocier la logique métier. Du coup cela permet de se dire que s'il y a un nouveau truc, si demain Swing c'est vraiment foutu et qu'il faut faire du JavaFX, et bien on réécrira alors notre moteur rendu. Tous les projets Eclipse Scout mutualisent cet effort et du coup, tout le monde en profite.
5. On a parlé plutôt côté client; côté serveur, comment cela fonctionne ?
On est sur une architecture OSGi des deux côtés, donc on va travailler de manière orientée service. On déclare nos services dans les registrees OSGI. Côté serveur, on se retrouve avec un environnement OSGi et le framework prend toute la partie communication entre les deux. C'est-à-dire que côté client, il va faire un dependency lookup en disant "je veux tel service". Si le service est implémenté côté serveur, il ne va pas le voir, mais ce qu'il se passe en interne, c'est qu'on se retrouve avec un proxy qui ouvre la transaction, la communication. Puis on exécute le code qui est prévu côté serveur et on revient côté client comme si de rien n'était. Pour le développeur, pour qu'il se concentre sur sa logique métier, c'est résolu de manière transparente.
Oui. En fait, une des forces d'Eclipse Scout, c'est de dire qu'il faut que les gens soient productifs. Par rapport à ça, on a développé un certain nombre d'outils. Notamment dans notre IDE Eclipse, on a ajouté une nouvelle perspective. Ce sont des outils qui s'ajoutent à PDE ou le JDT, et qui vont venir générer le code Java, avec des assistants qui disent "je veux faire un nouveau formulaire", "je veux ajouter un champ à tel formulaire", et cela va générer le code Java correspondant. Au moment de créer un nouveau formulaire, il faut penser à enregistrer les différents services dont on a parlé. Là pareil, il va faire les éditions qui vont bien dans plugin.xml et finalement c'est assez transparent. L'avantage en faisant ça, c'est que tout notre code est dans le code Java. Si on veut se passer des outils et le faire à la main, il n'y a pas de problème, d'ailleurs c'est ce qui se passe pour nos développeurs les plus avancés, qui parfois sont plus rapides avec leurs raccourcis. Si une modification est faite directement dans le code Java, on reflète cette modification dans nos vues et si une autre personne utilise cette vue dans le même projet, elle se retrouve avec quelque chose de consistant et les deux peuvent travailler ensemble.
Comme je l'ai dit, c'est un projet qui a 3-4 ans, mais en fait c'est beaucoup plus vieux dans notre compagnie. Cela fait plus d'une dizaine d'années qu'on l'utilise, qu'on réfléchit à ses problèmes et qu'on développe des applications métiers avec. Quelques fois, en se retrouvant en co-développement avec nos clients sur certains projets, ceux-ci ont trouvé ça vraiment pas mal et du coup ont demandé s'ils pouvaient le réutiliser sur d'autres projets qui n'avaient plus rien à voir avec ce qu'on leur avait vendu. On réfléchit, on se dit pourquoi pas, on fait un petit deal, sauf que ça n'apporte aucune garantie, ni pour l'un, ni pour l'autre. Puis, on a senti que ça pouvait être quelque chose que l'on pouvait proposer à un public plus large, en créant un projet open source. On est allé voir la Fondation Eclipse en leur montrant ce qu'on faisait. Ils ont trouvé ça pas mal, nous ont donné le formulaire à remplir et les différentes étapes pour devenir un projet Eclipse. On y a répondu et cela fait 3 ans qu'on est dans le release train, cela se passe bien, nous sommes contents.
8. Pourquoi avoir choisi Eclipse en tant que Fondation plutôt qu'une autre ?
Pour faire un projet open source, la manière la plus simple c'est de dire "j'ai telle licence" - par exemple la licence Apache qui est très connue. Sauf qu'en fait, s'adosser à une fondation, cela permet de mener le processus de manière beaucoup plus poussée. La Fondation Eclipse va d'abord vérifier le code que l'on donne - par exemple sous licence EPL. Dans notre cas, ils ont commencé par regarder notre code, nous ont dit qu'il y avait des choses récupérées à droite à gauche, et nous ont demandé de le rendre plus propre. Cela ne suffit pas de mettre "licence open source" en haut du fichier Java, il faut que le code ne vienne pas d'une autre source. En l'occurence, il y avait quelques endroits où il a fallu que l'on fasse des corrections. Et en fait, cela apporte une vraie sécurité, à la fois pour nous et pour nos clients parce que la fondation garantit que le code qui est hosté sur Eclipse.org est vraiment open source. N'importe qui va pouvoir le réutiliser, faire du business avec, le rendre open source ou pas puisque la licence EPL ne force rien - si quelqu'un veut développer une application dont les sources sont privées, pas de problème, il crée une dépendance sur notre projet ou sur d'autres projets de la Fondation Eclipse, puis il peut vendre son application à qui il veut. Pourquoi la Fondation Eclipse? Ce sont des gens que l'on connaissait, on a toujours été proches du milieu Eclipse, on utilisait les outils et on avait ce type d'architecture chez nos clients. En discutant lors d'une EclipseCon, on s'est rendu compte que l'on pouvait faire quelque chose.
Oui sur eclipse.org/scout. Je me rends compte en discutant à notre stand à la conférence, que pour un grand nombre de gens ce n'est pas clair que, être un projet Eclipse cela veut dire qu'ils peuvent tout réutiliser par eux-mêmes. Nous ce qu'on vend, c'est du support, de la formation, du conseil, mais s'ils veulent s'en passer, ils peuvent. On commence à avoir de belles histoires de gens qu'on ne connaissait pas du tout. Ils arrivent avec un truc fini, qu'ils ont fait tout seuls en utilisant les ressources qu'on a mis en ligne (wiki, livre sous forme PDF). Nous, on développe en interne bien sûr aussi des applications. On compare un peu les deux et on dit aux gens en interne "regardez, là y'en a un avec Eclipse Scout qui a réussi à faire un truc vraiment joli et peut-être qu'il y a 2-3 idées d'ergonomie à récupérer". Cela fait 3 ans qu'on a vraiment sécurisé le code et on est à un point où on commence à s'ouvrir. La mécanique de "tout le monde joue le jeu, on reçoit des contributions en retour" commence à prendre. C'est super et on ne demande qu'à ce que cela continue. Jusqu'à présent, une très bonne expérience pour nous.