Clarify how the Server/Backend pieces should be wired together

[CamilleLetavernier]

Currently, we have different ways to trigger backend java applications:

• Ecore GLSP Server: Java Main class with socket-based communication
• Ecore File Creation: Java Main class triggered from the Theia Backend (Node)
• WIP GenModel & CodeGen (Add action to generate code [13] #33): Eclipse Applications triggered from either the Theia Backend directly, or via an intermediate Java Main class

#78 also suggests to wire the Ecore File creation via a socket connection, whereas #33 needs to introduce more Eclipse-based applications (To reuse the existing EMF Codegen Eclipse Applications)

#120 offers an entry point for an Eclipse Application/CLI oriented approach (Via a minimized Eclipse Product)

While each component has different requirements & dependencies, some Maven-based, some Eclipse-based (And probably some Hybrid), it would be nice to clarify how we want to proceed in the future. Having a consistent pattern would be nice :)

I'm personally in favor of Eclipsifying all the Java code, as it makes it easier to play with EMF, and should also give us some flexibility regarding how the plug-ins are actually started/deployed (All-in-one Eclipse Product, on-demand process, socket-based communication...), but it might not be straightforward, depending on how many plain-maven dependencies we get through GLSP.

[tortmayr]

+1 for Eclipsifying the Java Code.
All GLSP server components are available as Eclipse plugins as well and the related dependencies can be resolved via Orbit and some additional p2 update sites (no plain-maven dependencies at all).

The nightly update site can be found here: https://download.eclipse.org/glsp/server/p2/nightly/
The targetplatform definition can be found here: https://github.com/eclipse-glsp/glsp-server/blob/master/targetplatforms/r2019-12.tpd.

I'm curious about one thing: What's the current approach for debugging the Ecore File generation if no socket-based communication is used? If I understand you correctly it's not possible to debug client-server interaction directly in this case and you would have to create an Eclipse Launch config that simulates the client call?

[CamilleLetavernier]

I'm curious about one thing: What's the current approach for debugging the Ecore File generation if no socket-based communication is used? If I understand you correctly it's not possible to debug client-server interaction directly in this case and you would have to create an Eclipse Launch config that simulates the client call?

Exactly; it's a nightmare :) (Luckily, the Ecore File generation is simple enough, < 10 LoC; but that's already hard enough to debug. GenModel and Codegen are even worse)

[CamilleLetavernier]

I'm closing this task, as it was mostly a question :)