java vscode extension is not published to vsx registry properly

[lmcbout]

Description

Propose to set the redhat JAVA version 0.54.2 in open-vsx registry

Testing Theia and JAVA available in vsx-registry (https://open-vsx.org/?)
The redhat JAVA version is 0.58.0 and is incompatible with version of Theia. When you install it, you get a popup dialog saying: " Activating extension Language Support for Java(TM) by Red Hat failed: Cannot read property 'join' of null.
bash: syntax error near unexpected token `(' "

refer to the issue #6791

Side effect:
1- You don't get the "RUN | Debug" button from gitlens
2- Install MAVEN and try to expand the plugions folder from the mavens view, it loops
3- Install the JAVA dependency view , you get a popup saying: "Cannot activate extension 'Java Dependency Viewer' because it depends on extension 'Language Support for Java(TM) by Red Hat', which failed to activate."

Reproduction Steps

Open THeia latest version
Expand the extension view, search for JAVA plugins
1- Install "Language <support for JAva" version 0.58.0
--> observe the dialog popup
2- Install MAven, open a maven project
Expand the Mavens view until the plugins tree folder and try to open it
--> it loops and does not get display
3- Install the Java dependency view
--> get a dialog saying: "Cannot activate extension 'Java Dependency Viewer' because it depends on extension 'Language Support for Java(TM) by Red Hat', which failed to activate."

OS and Theia version:
Ubuntu 18.04
Chrome
Theia : latest commit 743836e

Diagnostics:

[marcdumais-work]

@spoenemann @jankeromnes This issue is about consuming the "Java by Red Hat" extension, from open-vsx.org, in Theia applications.

It happens that the latest version of that extension, built/deployed nightly in open-vsx,org, does not work well in Theia. In an ideal world, when I access the registry from the my Theia-based IDE app, I would be offered a version of an extension that's known to work in my application, but it sounds to be easier said than done.

Any thoughts about how to handle this type of situation?

[jankeromnes]

I would say short-term, we can publish the older version to Open VSX, and remove the newer version for now.

Longer term, I think there should be a way to upload multiple versions to Open VSX, and for clients to download a specific version depending on their needs.

[jankeromnes]

@spoenemann Please remove redhat.java version 0.58.0 from https://open-vsx.org for the short-term fix outlined above (this will allow the publish-extensions CI to publish version 0.54.2).

Also, do you have any thoughts or suggestions on the proposed longer term solution?

[akosyakov]

@lmcbout @marcdumais-work Which project did you use to reproduce the issue?

[lmcbout]

@akosyakov I use a small application to test JAVA with different version of REDHAT JAVA and maven. Rename the file...tar.txt to ...tar, Just untar the following in a workspace, install from the open registry MAVEN with JAVA 058.0, no RUN | Debug
with JAVA 054.2 , open the file App.java, you will see the RUN | JAVA.

my-app.tar.txt

[marcdumais-work]

Also, do you have any thoughts or suggestions on the proposed longer term solution?

Though it would not cover all possible cases of incompatibility, could the registry use the client's reported version of supported vscode engine, proposing by default e.g. the latest version of an extension that does not exceed this value?

In the specific case of redhat.java, we have the following mapping:

redhat.java version -> vscode engine
v0.54.2 ->  "^1.40.0"
v0.55.0 -> "^1.41.0"
...
v0.58.0 ("next") ->  "^1.41.0"

Anecdotally, this extension stops working well in Theia from v0.55.0, which is the first version where they stepped vs code engine from "^1.40.0" to "^1.41.0".

[akosyakov]

@marcdumais-work I think it is a feature request for Theia, right now we only pull latest version, we don't verify whether its confirm to vscode api engine version. Could you file an issue please? We also don't support detecting outdated extensions and upgrading them.

[spoenemann]

Longer term, I think there should be a way to upload multiple versions to Open VSX, and for clients to download a specific version depending on their needs.

The first part is already possible. Downloading a specific version is also possible, but so far our UI only displays the latest version. We could change that.

Can'we just fix the problems in Theia instead of deleting published extensions from the registry?

[akosyakov]

I agree with Miro that we cannot keep outdated versions in the registry, but should work on bug fixing in the plugin system.

[akosyakov]

@lmcbout It works for me, code lens are disabled by default, you should enabled them in settings with "java.referencesCodeLens.enabled": true.

How did you manage to get:

Activating extension Language Support for Java(TM) by Red Hat failed: Cannot read property 'join' of null.
bash: syntax error near unexpected token `(' 

I cannot reproduce it. If you can provide a GitHub repo it would help.

[akosyakov]

Ok, i was able to reproduce it. The issue is not with Theia or VS Code java extension, but apparently with the publishing script:

(1) - is from VS Code Marketplace, this extension works
(2) - is from Open VSX Registry, this extension does not work and it is very tine compare to (1)

cc @spoenemann @jankeromnes

[akosyakov]

moved to open-vsx/publish-extensions#18

[spoenemann]

I would like to avoid doing this in general, but in this case we're going to delete the already published version from open-vsx.org

[marcdumais-work]

@marcdumais-work I think it is a feature request for Theia. Could you file an issue please?

Ok, will do. So IIUC the client can deal with this, with no additional support from Open VSX? Do we know if VS Code and their registry have a similar mechanism?

[marcdumais-work]

Ok, will do.

#7464

[marcdumais-work]

Can'we just fix the problems in Theia instead of deleting published extensions from the registry?

Yes, I agree.

Even more so if, as looks probable, Open VSX eventually adds supports clients other than Theia, like VSCodium.

[jankeromnes]

@lmcbout A fixed redhat.java extension was recently pushed to Open VSX by RedHat: https://open-vsx.org/extension/redhat/java

Could you please try again with 0.59.0?

[marcdumais-work]

Hi @jankeromnes ,

I just tried using the Theia electron example app from the main repo, using latest master. I installed the Java extension from the extensions view, pulling it from open-vsx.org:

Upon opening a .java file I get error:

Backend exception:

root ERROR [hosted-plugin: 9271] Error on activation of java TypeError: s.workspace.onDidCreateFiles is not a function
    at Object.t.registerFileEventHandlers (/home/lmcmcds/.theia/extensions/redhat.java-0.59.0/extension/dist/extension.js:7:96930)
    at Promise (/home/lmcmcds/.theia/extensions/redhat.java-0.59.0/extension/dist/extension.js:1:197103)
    at new Promise (<anonymous>)
    at /home/lmcmcds/.theia/extensions/redhat.java-0.59.0/extension/dist/extension.js:1:188413
    at Generator.next (<anonymous>)
    at o (/home/lmcmcds/.theia/extensions/redhat.java-0.59.0/extension/dist/extension.js:1:180965)
    at process._tickCallback (internal/process/next_tick.js:68:7)

[akosyakov]

@marcdumais-work it is missing workspace APIs we should work on it: #7171

I don't think there is an issue in the registry or in the extension.

[marcdumais-work]

I don't think there is an issue in the registry or in the extension.

I do not think this was implied in the original title of this issue that the problem was with the registry or the extension. Rather that for a user naively trying a Theia app and installing the java extension will not have a good outcome, hence the suggestion to publish a version that works with the current theia.

[akosyakov]

@marcdumais RedHat is going to claim own namespace: EclipseFdn/open-vsx.org#6 I think it would be too much to ask them to change their release process to publish another version for Theia. It should not be hard to fix missing APIs, we have them in Theia already.

[marcdumais-work]

ok, seems reasonable in this case. But I expect this will be a recurring type of problem whenever new APIs will appear in the wild that we do not support yet. Until we have something like #7464