How to bundle a GLSP Eclipse Plugin?

[rsoika]

I have successful setup my GLSP Eclipse Integration project for Open-BPMN. (also following this discussion)
I can run and test the plugin using the .launch configuration within my Eclipse IDE.

My problem is now how to package this into a feature/site to provide a public download. I have added a lot of dependencies into my feature list to fulfill all the requirements for glsp. It is more the 70MB which seems very huge. But anyway it is still not working as expected. When I install the plugin in a blank eclipse and start it I got the following error exception:

org.eclipse.core.runtime.CoreException: Plug-in org.openbpmn.eclipse.integration.editor 
was unable to load class org.eclipse.glsp.ide.editor.ui.GLSPDiagramEditor.

I have of course added the corresponding plugin into my feature set

   <plugin
         id="org.eclipse.glsp.ide.editor"
         version="0.0.0"/>

But the error message makes somehow sense as the jar file org.eclipse.glsp.ide.editor_2.1.0.jar bundled with my plugin is an empty plugin file only containing the files plugin.xml and META-INF.MF . This is surprising. For example other GLSP plugins like org.eclipse.glsp.layout_2.0.0.jar contain the corresponding class files.

Now I have already tried to add the library org.eclipse.glsp.ide.editor-2.1.0.jar directly from the target folder of the org.eclipse.glsp.ide.editor project into my own /lib/ directory of my plugin. But this did not work at all.

I wonder if there is something missing? Is the plugin org.eclipse.glsp.ide.editor 2.1.0 at least not available yet?

This is how my project looks: https://github.com/imixs/open-bpmn-eclipse-integration

Thanks for any hints

[rsoika]

Hi @tortmayr , do you have any hints for my problem described here?

[martin-fleck-at]

@rsoika Hi Ralph, Tobias is currently on vacation so I'll try my best to help you. The 2.1.0 plugins should definitely be available on this update site: https://download.eclipse.org/glsp/ide/p2/releases/2.1.0/. Given the size of the jars, I don't think they are actually empty so there could be a caching issue. How exactly are you trying to package this into your feature? Is there maybe a branch or something which I could try out?

[rsoika]

@martin-fleck-at Hi Martin, the link to your update site shows to me that this is the plugin of the Workflow Example.
Is the update-site project for this workflow-exampl-plugin open source on github? Then I could look into this configuration which may help me to find out the correct setup....

[martin-fleck-at]

We do publish the workflow plugin as an example but the org.eclipse.glsp.ide.feature (feature.xml, pom.xml) itself only contains the org.eclipse.glsp.ide.editor without the workflow example. In your target platform you should rely on this feature. Our own developer target platform can be found in the releng.target project and the GLSP update site is build using ant in the repository project. Hopefully this will help you out.

[rsoika]

...hm I am still missing how to config my public plugin project.
I have already created a working Eclipse Plugin for Open-BPMN that I can start with a launch configuration. This I think is all fine.
Now I want to publish the result as a separate Plugin similar to the Workflow Example Editor Plugin

For this I need two additional artifacts: a eclipse-feature project and a eclipse-site project. The interesting part for me is the feature-project. This has simply only two files - the feature.xml and the build.properties.
The feature.xml is the part that is not clear to me. In my current version this file has to many dependencies that lead to the extreme size of my plugin project at the end of 70MB.

The difference to your workflow example is that your feature folder holds the org.eclipse.glsp.ide.feature_2.1.0.jar only and the plugin folder holds the org.eclipse.glsp.ide.editor_2.1.0.jar and the org.eclipse.glsp.ide.workflow.editor_2.1.0.jar.

And that means to me that a user have to install both plugins - ??

Otherwise I guess the workflow plugin will not work and will show the same error message I have in my test IDEs.

So if you can point me to your feature.xml file that is used in your demo site-project, I can try a similar setup.

But I fear that this means that I need always bundle my plugin with the GLSP Eclipse Integration feature and the user need to install both plugins. That's not very nice, but in the end it's probably acceptable.

[rsoika]

One additional note: Even if I try to install the Workflow Example plugin into a fresh Eclipse 2024-06 IDE I get the same problem. There are missing dependencies :-(

...this is very strange. Can you install the workflow example from the update site?

[martin-fleck-at]

I can definitely confirm that installing the Workflow Example plugin is not straight-forward and that it seems to require some particular versions of certain plugins. I will talk to Tobias once he is back to figure out a good strategy. I assume that setting better version ranges or producing different bundles for different versions might be the goal here. When you do the upgrade/downgrade and then try again to install the workflow example, does it work for you?

In general, it's been a while since I worked on the Eclipse Update Site stuff but I believe if you have your dependencies properly defined and Eclipse knows about all the update sites, it will figure out what to install from where. For instance, if you rely on GLSP stuff, the user needs to add the update site to their Eclipse installation as otherwise the required features/plugins will not found. I believe there is a way to produce composite update sites so that in your update site you also contain the required features from GLSP.

The feature that you see in the dialog is defined here: https://github.com/eclipse-glsp/glsp-server/blob/master/releng/org.eclipse.glsp.feature/feature.xml
The repository is defined here: https://github.com/eclipse-glsp/glsp-server/blob/master/releng/org.eclipse.glsp.repository/pom.xml with the concrete deployment here: https://github.com/eclipse-glsp/glsp-server/blob/master/releng/org.eclipse.glsp.repository/category.xml

Does this help you? If not, I can ask a colleague who may know more about the feature setup.

[rsoika]

Thanks for your answer. I think the workflow example plugin runs into the same problem as my own plugin. This is certainly a eclipse-bundling issue. Testing the plugin during development is never a problem as all needed classes typically are available in the current developer workspace. But the org.eclipse.glsp.ide.editor simply can't be found in a black workspace. Maybe just an additional repo source need to be defined in the feature.xml (but I do not know how do do this). Or the .jar files need to be bundled. But currently such a jar file can't be found even during the bundling phase....

[martin-fleck-at]

Hmm... that's really interesting and I'm a bit out of my depth here. I asked around but since it is vacation season, many people are currently not available. I'll see that someone (maybe Tobias) has a look at this once they are back.

[rsoika]

Thanks - no hurry.

[tortmayr]

Hi @rsoika,

I had a look at this and unfortunately it looks like integrating GLSP into recent Eclipse releases is currently not possible due
to dependency issues.
This is caused by the namespace change of javax to jarkarta.
Lots of the GLSP components still depend on older javax artifacts which are no longer available in recent Eclipse releases.
To fix this we have to fully migrate the GLSP server and IDE integration to jarkata which requires significant effort.
I will put this task on the top of our backlog but sadly it still might take some time until a compatible GLSP version will be availble.

[rsoika]

ok, I see - strange that this namechange also affects eclipse ide. I thought it affected only the Java Enterprise area. But the the lawyers from Oracle did in deed a very good job some years ago.....
We have had the same issue in Imixs-Workflow as we are fully depending on Jakarta EE.

[rsoika]

Hi @tortmayr, I thought again about the namespace issue you mentioned. Are you sure we are affected from it? In Jakarta EE Servers the issue is very well known. But all moderns Servers (e.g. Wildfly, OpenLiberty, Payara) have a dynamic class-loader module that automatically lifts the package names when loading old libraries. Otherwise no new App server would be able to load old Java EE apps.
And I think the same class loader concept is part of the Eclipse/OSGI Framework somewhere. So you should not be affected if you not actively start using the new package names in your code. And during development with the GLSP plugins all is fine. Maybe its only a minor issue somewhere else in the dependency setup? Which classes do you have in mind? The jax-b lib or a json lib?

[tortmayr]

I haven't had time yet to dig deeper into this, but when I did the initial investigation I at least identified two problematic dependencies

• Jetty (Websocket): Currently we are still using Jetty 10 which has old javax namespace dependencies. Those are no longer available in recent Eclipse releases so we have to update to Jetty 11 (which marks the switch to the jarkata namespace)
• LSP4j: We are depending on org.eclipse.lsp4j.websocket. This package is no longer part of recent Eclipse releases, instead there now is org.eclipse.lsp4j.websocket.jarkata

You are right, in an ideal scenario updating the packages in question an adapt our imports should be enough. However, previous updates have shown that is typically not that easy. Especially bumping the Jetty version can be tricky and cause side issues that need to be fixed.

I will start with a first migration attempt this week and let you know about the (intermediate) results.