1. Bonjour Alain, peux-tu te présenter ?
Bonjour, Alain Le Guennec, je travaille dans une société qui s'appelle Esterel Technologies, basée en France - Toulouse, Paris et Nice. On est fournisseur d'ateliers de développement pour les logiciels et les systèmes embarqués critiques. Je suis ici à Ludwigsburg dans un cadre de veille technologique, autour des technologies Eclipse puisqu'un de nos derniers produits est basé fondamentalement sur la plate-forme Eclipse et certains de ses composants majeurs dans le monde de la modélisation tels que Papyrus.
2. Peux-tu nous parler de votre besoin sur SysML et justement du choix de Papyrus ?
En fait, Esterel, on fait des ateliers de développement qui sont basés modèle avec une partie modélisation graphique dans un atelier développement classique et ensuite des phases génération de code typiquement. On avait un nouveau produit qu'on voulait réaliser pour faire de la modélisation de système en entier, donc avec une vision style diagramme de bloc, comment le système est structuré. Il existe des normes comme SysML pour faire ça; pour nous être conforme aux normes c'était quelque chose d'important, et il se trouve que l'outil Papyrus qui est un outil de modélisation graphique UML avec un très bon support pour la norme SysML. Donc après étude, on a décidé de faire un partenariat avec le CEA, qui est un des principaux contributeurs de Papyrus, pour embarquer une version de Papyrus SysML en tant que partie pour la modélisation graphique dans notre nouvel outil.
3. Vous utilisez aussi d'autres projets Eclipse, notamment EMF Compare ?
Dans notre atelier, il y a la partie modélisation comme je disais, il y a des outils connexes autour pour typiquement transformer des modèles dans d'autres formats, venant d'autres outils, ou qu'on peut utiliser des composants de transformation de modèles au-dessus de EMF, comme QVTo. On a aussi la problématique du travail collaboratif où les gens utilisent nos outils en équipe, leurs modèles peuvent être amenés à diverger et donc avoir besoin de réconcilier des variations, des divergences à l'aide d'EMF Compare qui est aussi intégré pour faire du diff-merge de modèles.
Ce qui a bien marché, et ce pourquoi on a choisi Eclipse, c'est l'ouverture. Le code est très "business friendly", on peut l'utiliser dans des applis commerciales, il est bien structuré, il y a la Fondation Eclipse derrière qui gère tout ce qui est droit intellectuel - des points importants pour un vendeur d'outils, puis la qualité technique des composants que l'on a intégré aussi qui était bien. On a eu des difficultés par le passé pour gérer nos cycles de release par rapport à celles d'Eclipse, qui sont découplées. On modifiait certains composants pour des raisons d'intégration, on devait maintenir des branches privées, c'était compliqué en termes de gestion de conf. Un point important a été fait l'année dernière par la Fondation Eclipse, c'est la migration à Git de toute l'infrastructure, de tout le code, et clairement ça nous a enlevé une grosse épine du pied puisque maintenant on peut utiliser un système distribué de gestion de conf pour avoir nos propres variantes gérées en conf proprement, et non pas comme des diff gérés en conf. Maintenant on a nos propres branches. Grosse, grosse amélioration.
5. Et une facilité de reversement aussi ?
Oui, tout à fait, on contribue aussi. On est pas que consommateur de technologies Eclipse. On travaille avec le CEA pour contribuer à améliorer Papyrus. Les développeurs dans l'équipe contribuent de temps en temps des patchs aussi à Eclipse, à Papyrus plus spécifiquement. Quand on tombe sur des problèmes qu'on arrive à corriger nous mêmes, dans ce cas on reverse effectivement.
6. Concernant Eclipse 4, est-ce que vous avez déjà migré, sinon, à quelle échéance ?
Pour le moment, on ne l'a pas fait. Une des raisons principales, c'est que nous avons un framework applicatif qui est un peu une sorte d'hybridation entre la plate-forme Eclipse et une plate-forme propriétaire. Donc on touche un peu dans les couches basses de la plate-forme Eclipse pour venir se plugger, et refaire tout ça pour Eclipse 4, ça a un certain coût que l'on est en train d'étudier. On attendait que la nouvelle plate-forme soit suffisamment mature. Pour le moment, la couche que l'on utilise applicative de Eclipse fonctionne aussi bien en Eclipse 3 qu'en Eclipse 4 donc on était pas bloqués. Donc on est resté sur une plate-forme 3.8. Par contre, toutes les couches, tout ce qui est au-dessus d'EMF en gros (EMF inclus), on est passé à du Eclipse 4.3 puisqu'il n'y a pas d'adhérence avec la plate-forme, donc ça ne pose pas de problèmes techniques. On étudie la question, et on envisage d'y passer en 2014, ou l'année d'après.
7. Merci Alain pour cet entretien. Un dernier mot ?
Oui, j'en profite pour rajouter que le produit SCADE System sur lequel je travaille, qui met en oeuvre toutes ces technologies Eclipse, recrute. On a des postes ouverts. N'hésitez pas à me contacter si vous êtes intéressés pour rejoindre l'aventure.