Yan Zhang

CI failed for unrelated cases, tracked in https://github.com/eclipse/eclipse.jdt.ls/issues/1869#issuecomment-918959582

https://ci.eclipse.org/ls/job/jdt-ls-pr/2839/console > Took 40 min on basic-mls1s This time, no failed case, but the same "SIGKILL" error as mentioned in https://github.com/eclipse/eclipse.jdt.ls/issues/1869#issuecomment-914880110

test this please

Currently completion related to package name is broken when testing on vscode, as described in https://github.com/eclipse/eclipse.jdt.ls/issues/1864#issuecomment-913426507 Before this PR:   After this PR,returns correct response, but vscode wrongly infer...

AFAIK vscode-spring-tools will [append some vmArgs](https://github.com/spring-projects/sts4/blob/24117a4cc01a46d5681440e6b6693e8bcef68410/vscode-extensions/vscode-spring-boot/lib/debug-config-provider.ts#L15-L28) when this setting is on. Not sure whether that's related or conflict with test runner. //also cc @martinlippert @BoykoAlex for awareness.

The most likely reason I can think of is that live connection occupies some ports which are required for testing. So, another idea is, if the debug session is a...

I myself would perfer the main class check for two reasons. - Class name for test frameworks are relatively stable and won't change very often. We can maintain a whitelist...

you can do it via setting `maven.excludedFolders`, which is workspace folder lever. Let me know if it works for you.

Before " installing Maven manually ", if you don't have a `mvnw.cmd` on the project root, or any `mvn`/`mvn.cmd` on your `%PATH%`, then the behavior is as expected. I agree...

> then we need reinstall Maven manually? No you don't have to **re**install Maven if you already have one configured in your PATH. > Is this java world? So please...