Duration: 34:54

524 views

2

EclipseCon Europe 2018
Ludwigsburg, Germany · October 23 - 25, 2018
https://www.eclipsecon.org/europe2018

Speaker(s):
Aurélien Pupier (Red Hat)

https://www.eclipsecon.org/europe2018/sessions/adopting-language-server-apache-camel-feedback-javaeclipse-plugin-developer

Apache Camel is a well-known largely used integration framework which is providing different DSLs most notably inside Java and XML documents.

Dedicated tools are currently available only in 2 different IDEs, each with a very different set of features and no factorization between both. Most Apache Camel users don’t take into account existence of Camel Tooling in the choice of their IDE, as they focus on other criteria, so they miss to use the recommended tools. How to bring tooling to them?

The Language Server Protocol (LSP) is the most important concept in tooling space nowadays. The promise is to focus the development effort on one single tool-agnostic service that can be leveraged in a large set of mainstream and emerging IDEs and Text Editors.

I will provide feedback on my experience as a 10-years Java/Eclipse IDE developer about writing a Language Server for Apache Camel and trying to make it the main approach for tools integration in the Camel community.

Here are the challenges I faced, and for which I’ll propose some resolutions or discussions:

initial implementations and most examples are written in Typescript but hey, I'm a Java developer and don’t know a thing about TypeScript!
Easy client creation in a lot of IDEs: yes… in theory! But practical experience have shown this wasn’t always obvious to integrate our Language Server with Eclipse IDE, Eclipse Che, and VS Code.
Architectural concerns:
how to combine Camel and Java support?
how to combine Camel and XML support?
how to leverage the same Language Server on both Java and XML files?
Language Server Protocol is now well-know in Tooling world, but not yet famous in Software world in general:
How to convince hierarchy/Product managers of the return on investment?
How to convince the targeted community to embrace a language server instead of developing one or several specific IDE supports?

After this session, Java/Eclipse plugin developers will be able to successfully write their Language Server implementation in Java, and to estimate the cost of adding almost important IDEs and Text Editors to the portfolio of supported technologies.

For reference, here is the Github repository for the Language Server developed on which I will base my feedback: https://github.com/camel-tooling/camel-language-server

This talk has been given at EclipseCon France. it will be enriched from the feedback I received and with the serveral months of work experience added on the subject.