User behavior for setting up Java Debugger is not clear

[musienko-maxim]

Precondition:

• Launch Che with Theia next version on the OpenShift or Kubernetes infra with chectl
  Steps to reproduce:
• Create workspace with chectl using configuration from CHE project:
  chectl workspace:start --devfile=che/e2e/files/happy-path/happy-path-workspace.yaml
• Open the workspace, wait for finish of cloning the project
• After cloning try to set Debugger configuration Debug -> Open Configurations

The debugger configuration does not apply for the petclinic project. For correct applying of Debugger configuration we should open the project in the separate workspace:
File -> Open Workspace -> Select Petclinic project. But after that the project context form the previous browser tab will be lost. More over after that all plugins will be initialized again. It is not obviously for a user and can confuse. As for it like a bug.
Also it behavior influences on the current e2e test for che-theia, because we should implement extra steps for the opening project in the separated workspace
The related issues: #12728

[vparfonov]

@slemeur We need to here your thoughts, on my opinion this is very strange behavior and I would consider it as bug

[rhopp]

@tsmaeder Are we doing something wrong here?

[dmytro-ndp]

This issue is probably kind of blocker for #14248

[tsmaeder]

The debugger configuration does not apply for the petclinic project. For correct applying of Debugger configuration we should open the project in the separate workspace:

@musienko-maxim Could you explain what you mean by "the debugger configuration does not apply"?
Does it work if you refresh the browser in the first window?

[ibuziuk]

@musienko-maxim the issue is assigned, so please put a milestone based on the team priorities

[tsmaeder]

I assigned it because I'm waiting for feedback.

[amisevsk]

Caveat here: I'm not perfectly clear on how e2e tests currently work.

I've tried running the devfile in the issue and it seems to be quite different from the flow I'm used to on Che.

• I tried the "Open Workspace" option described above and see the included debug configuration, but it's not clear to me where it is even coming from -- it seems to be pulling debug config data from the .vscode directory in the upstream repo. If this is to be a supported flow, an issue should be opened, since AFAIK debug and launch configs are stored in the /projects/.theia folder.
  • Either way I'm not sure relying on parsing configs meant for a different program and having compatibility with Theia is the best approach here.
• For current devfiles such as the petclinic one, we provide a debug command which is processed by Theia. Is there a reason we don't do similar in the e2e test? I don't think we're testing "add a debug config" as part of the flow.
• The flow for adding a debug configuration in the "original" workspace works in the same way I'm used to; using autocomplete to fill a remote debug configuration seems to work.

As an aside, is there a reason the images in this devfile are non-standard? Why aren't we using the patched images we'd be using for the typical spring-petclinic devfile? The image used is still plagued by long-fixed problems like ? folder on maven builds, etc. Currently, our e2e tests seem to rely on

• mariolet/petclinic:d2831f9b
• bujhtr5555/maven-with-artifacts:latest

which seems quite strange to me.

[tsmaeder]

@musienko-maxim ping?

[musienko-maxim]

The root cause as was mentioned by @amisevsk it is which behavior should be if a cloned project already have .vscode folder. Lets see on this with more simple sample: a user has created a workspace based on maven stack without projects. He already had .theia folder with debug config (launch.json) file. After that he cloned the petclinic project: https://github.com/spring-projects/spring-petclinic, with .vscode folder which also has launch.json file. In this case not exacly clear which configuration should be applyed.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.