eclipse-glsp / glsp-server

Java-based server framework of the graphical language server platform

Eclipse GLSP Server

Contains the code for the Java-based framework to create GLSP server components.

Building

The GLSP server bundles are built with Java 17 or higher and maven. Execute mvn clean verify -Pm2 (for maven) or mvn clean verify -Pp2 (for p2). The nightly builds are available as maven repository or p2 update site.

Maven Repositories

• Snapshots: https://oss.sonatype.org/content/repositories/snapshots/org/eclipse/glsp/
• Releases/Release Candiates: https://oss.sonatype.org/content/groups/public/org/eclipse/glsp/ (also mirrored to the maven central repository)

P2 Update Sites

• Snapshots: https://download.eclipse.org/glsp/server/p2/nightly/
• Release Candidates: https://download.eclipse.org/glsp/server/p2/staging/
• Releases: https://download.eclipse.org/glsp/server/p2/releases/

All changes on the master branch are deployed automatically to the corresponding snapshot repositories.

Structure of this repository

• org.eclipse.glsp.graph: EMF-based implementation of graphical model that's used for client-server communication

• org.eclipse.glsp.layout: Server-based layout using the Eclipse Layout Kernel framework (adapted from Eclipse Sprotty Server)

• org.eclipse.glsp.server: Generic base implementation for standalone GLSP servers (based on JSON-RPC)

• org.eclipse.glsp.server.emf: Reusable implementations if an EMF-based source model is used

• org.eclipse.glsp.server.websocket: Extension of the base server implementation for communication over websockets

• org.eclipse.glsp.example.workflow: GLSP server for the Workflow Diagram example

Workflow Diagram Example

The workflow diagram is a consistent example provided by all GLSP components. The example implements a simple flow chart diagram editor with different types of nodes and edges (see screenshot below). The example can be used to try out different GLSP features, as well as several available integrations with IDE platforms (Theia, VS Code, Eclipse, Standalone). As the example is fully open source, you can also use it as a blueprint for a custom implementation of a GLSP diagram editor. See our project website for an overview of the workflow example and all components implementing it.

diagramanimated.mp4

How to start the Workflow Diagram example?

To see the diagram in action, you need to choose and launch one diagram client, see here for an overview of available clients.

• glsp-theia-integration: Diagrams clients integrated into Theia.
• glsp-vscode-integration: Diagram clients integrated into VS Code.
• glsp-eclipse-integration: Diagram clients integrated into Eclipse IDE.

Please look at the workflow example guides in the repository linked above to get more information on building and running the respecitive GLSP clients.

Building the Workflow Diagram example server

In the root of this repository, run

mvn clean verify -Pm2 -Pfatjar

Execute from IDE

To run the Workflow Diagram example server within an IDE, run the main method of WorkflowServerLauncher.java as a Java Application, located in the module glsp-server/examples/org.eclipse.glsp.example.workflow.launch.

Execute Standalone JAR

In the folder examples/org.eclipse.glsp.example.workflow/target, you should have a jar file org.eclipse.glsp.example.workflow-X.X.X-SNAPSHOT-glsp.jar whereas X.X.X is the current version.

To run the Workflow Diagram example server standalone JAR, run this command in your terminal:

    cd examples/org.eclipse.glsp.example.workflow/target
    java -jar org.eclipse.glsp.example.workflow-X.X.X-SNAPSHOT-glsp.jar

Usage

    usage: java -jar org.eclipse.glsp.example.workflow-X.X.X-glsp.jar [-c <arg>] [-d <arg>]
        [-f <arg>] [-h] [-j <arg>] [-l <arg>] [-p <arg>] [-w]

    options:
    -c,--consoleLog <arg>      Enable/Disable console logging. [default='true']
    -d,--logDir <arg>          Set the directory for log files (File logging has to be
                                enabled)
    -f,--fileLog <arg>         Enable/Disable file logging. [default='false']
    -h,--help                  Display usage information about GLSPServerLauncher
    -j,--jettyLogLevel <arg>   Set the log level for the Jetty websocket server.
                                [default='INFO']
    -l,--logLevel <arg>        Set the log level. [default='INFO']
    -p,--port <arg>            Set server port. [default='0']
    -w,--websocket             Use websocket launcher instead of default launcher.

Once the server is running, choose a diagram client integration (such as Eclipse Theia, VS Code, Eclipse, or Standalone) below.

Where to find the sources?

In addition to this repository, the related source code can be found here:

• https://github.com/eclipse-glsp/glsp-client
• https://github.com/eclipse-glsp/glsp-theia-integration
• https://github.com/eclipse-glsp/glsp-eclipse-integration
• https://github.com/eclipse-glsp/glsp-vscode-integration

See also

For more information, please visit the Eclipse GLSP Umbrella repository and the Eclipse GLSP Website. If you have questions, please raise them in the discussions and have a look at our communication and support options.

glsp-server's Issues

Add CI snapshot deployment

OperationActionHandler makes it hard to add custom operation action handlers

Currently, the OperationActionHandler handles operation actions in the following way:

@Override
public Optional<Action> execute(Action action, GraphicalModelState modelState) {
	switch (action.getKind()) {
	case Action.Kind.CREATE_NODE_OPERATION:
	case Action.Kind.CREATE_CONNECTION_OPERATION:
	case Action.Kind.RECONNECT_CONNECTION_OPERATION:
	case Action.Kind.REROUTE_CONNECTION_OPERATION:
	case Action.Kind.DELETE_ELEMENT_OPERATION:
	case Action.Kind.CHANGE_BOUNDS_OPERATION:
	case Action.Kind.APPLY_LABEL_EDIT_OPERATION:
		return doHandle((AbstractOperationAction) action, modelState);
	default:
		return Optional.empty();
	}
}

That means, if users would like to add custom operation actions, they'll have to overwrite the OperationActionHandler and add their new action kind in the check above. This is unexpected and also unnecessary. We could do the following instead:

@Override
public Optional<Action> execute(final Action action, final GraphicalModelState modelState)  {
  if (action instanceof AbstractOperationAction && operationHandlerProvider.isHandled((AbstractOperationAction)action)) {
      return doHandle((AbstractOperationAction)action, modelState);
  }
  return Optional.empty();
}

Find a better mechanism to define the dirty-state of the model

In the fix for #36 we mark a model as dirty as soon as an executeOperation_* is sent to the server. However, this is not a very reliable mechanism. Without having thought this through entirely, imho, the server needs to decide whether a model is dirty or not; eventually, the server decides which action is actually performed or not, isn't it?

[migrated from https://github.com/eclipsesource/graphical-lsp/issues/62]

Add GModelIdAdapter

Add a reusable Adapter implementation that attaches an generated (GModelId) to an EObject.
We already use a similar approach in a couple of projects so extracting a common reusable component should be easy

Revise ActionProcessor /ActionHandlerAPI

https://spectrum.chat/glsp/general/custom-actions-in-glsp~d87a08b3-c94b-467e-802a-601e2f6ae2ef?m=MTU3NDE2NTQ3Nzk3Nw==

Setup initial Jenkins CI Integration

Should build every PR and report back to Github.
Deploy step should only be initiated on master (can be mocked for now, actual deploy will be handled in a follow up issue)

Order of command palette entries can't be controlled from the server

Since we are using hash sets, the order of items in the command palette sent from the server to the client is random, which not only prevents the server from defining a certain order, but also lets the order be different everytime the client requests a new set of elements.

Improve registration of action provider

I'd find it more convenient to register actions as a collection of classes instead of injecting a provider class, similar to how we register action handlers. If an implementer wants to customize the available actions, it needs to copy the entire list of actions instead of being able to get the default ones and remove the ones it needs and adding the additional ones.

For handlers, we can do it as follows:

final Collection<Class<? extends ActionHandler>> defaultHandlers = super.bindActionHandlers();
// remove bindings that we are about to overwrite or don't need
defaultHandlers.remove(OperationActionHandler.class);
defaultHandlers.remove(SaveModelActionHandler.class);
defaultHandlers.remove(UndoRedoActionHandler.class);
// custom handlers
defaultHandlers.add(MyOperationActionHandler.class);

For actions, we need to create a class that returns a list instead.