Java LS "Classpath is incomplete" warning when loading petclinic

[l0rd]

Description

After I have created a workspace using the following devfile

---
specVersion: 0.0.1
name: petclinic-dev-environment
projects:
  - name: petclinic
    source:
      type: git
      location: 'https://github.com/spring-projects/spring-petclinic.git'
components:
  - type: kubernetes
    alias: mvn-container
    reference: https://gist.githubusercontent.com/l0rd/52eda1d1b57878a218cba17c0c93a477/raw/9a2d56e777d22e77c25c45744caea35bb62d8688/petclinic.yaml
    selector:
      app.kubernetes.io/component: webapp
  - type: kubernetes
    reference: https://gist.githubusercontent.com/l0rd/52eda1d1b57878a218cba17c0c93a477/raw/9a2d56e777d22e77c25c45744caea35bb62d8688/petclinic.yaml
    selector:
      app.kubernetes.io/component: database
  - type: chePlugin
    id: redhat/java/0.45.0
  - type: chePlugin
    id: redhat/vscode-yaml/0.4.0
commands:
  - name: build
    actions:
      - type: exec
        component: mvn-container
        command: mvn package
        workdir: /projects/spring-petclinic

a classpath incomplete warning is shown every time a Java file is opened:

Reproduction Steps

Start a workspace using this devfile:

chectl workspace:start --devfile=https://gist.githubusercontent.com/l0rd/52eda1d1b57878a218cba17c0c93a477/raw/8ef7ff447a7164215395d6bc7d70b49363ebae86/devfile.yaml

OS and version:

macOS / minikube / nightly che-server / chectl / helm / jtd ls 0.45.0

[l0rd]

cc @tsmaeder @tolusha

[svor]

It looks like the project which was cloned after initializing jdt.ls workspace, isn't recognized as maven/gradel project. After reloading the browser tab or restarting jdt.ls (Clean the Java Language server workspace command), it works well.
It is also reproducible in local theia instance: just need to start Theia with empty workspace folder and clone some java project.

[l0rd]

So it looks like a concurrency problem: if the project takes time to be cloned, and JDT LS in the meantime get started, the project won't be indexed correctly. A possible solution would be to guarantee that a LS is started only once the cloning operation has completed: @evidolob @benoitf what's your opinion?

[tolusha]

From my point of view, JDT LS should assume that project might not be ready when it starts and try to initialize it later

[benoitf]

@l0rd I think the LS is receiving multiple events. I'm unsure that it's possible to wait clone before sending events. All is asynchronous so you could have multiple clones over the lifecycle and you may have finished to clone a project before cloning a new one so it's better to work totally asynchronously.

[tsmaeder]

@benoitf @l0rd this is really the expected behaviour: many language servers (jdt.ls being one) will not pick up on new projects being created in the workspace root (in our case: /projects). The user is expected to reopen the folder or "add folder to workspace". Expecting the language servers to pick this case up consistently is going to be a losing battle, IMO.
We currently have some kind of franken-UI: we still have the "Open Folder" menu, but we really expect projects to be in /projects and changes there to be picked up automatically.
I think there are a couple of things we could do:

1. When we start a workspace with projects, do the cloning before we start up the IDE. If we can't do this at the che container engine level, we might put a wait into the IDE for this condition. The code that clones the projects would have to notify that it's done.
2. We could detect folder creation in /projects in the IDE and offer the user the option to reload the window. This would restart all plugins and make them pick up the changes.

[tsmaeder]

Alternative would be to treat each folder in /projects as a workspace root. When detecting a new folder, we would notify the IDE that a new root has been added. But:

1. This would still be timing dependent: the LS needs metadat (pom.xml, etc.) to detect a project
2. We would have to analyse how multi-root is different from single-root for language servers. Is the beaviour the one we want for common language servers?