Extension needs Eclipse project files upon initial import if lifecycle mapping is done for compile

From this blog entry it seems that the old Eclipse project files; .project and .classpath, would no longer be neccessary. However, this is not the case: The files are no longer auto-generated, but if they are not present, the project won't open correctly.

Environment

• Operating System: Ubuntu Linux 20.04
• JDK version: OpenJDK 17.0.5
• Visual Studio Code version: 1.74.3
• Java extension version: 1.14.0

Steps To Reproduce

1. Remove the ~/.vscode directory containing any other extensions
2. Remove the ~/.config/Code directory containing all non-default VS Code settings
3. Open VS Code; install the "redhat.java" extension, and close again
4. Repeat step 2 to clear all settings
5. Create the directory ~/.config/Code/User and unzip settings.json from the attached settings.zip into it
6. Unzip both the attached project.zip and eclfiles.zip into a new directory
7. Open the project in VSCode through the project file foo.code-workspace. Click that you trust the authors of the workspace.
8. Observe that after the "Project are imported into the workspace" popup has appeared, you can go into the Program.java file, right-click on the word "Program" after "class" on the first line, and select Find All References from the menu; three results will appear in the References panel.
9. Type Ctrl-Shift-P, Java: Open Java Extension Log File; this will be a file ~/.config/Code/User/workspaceStorage/xxx/redhat.java/client.log.yyy where xxx is a generated identifier and yyy is today's date. Similarly will Java: Open Language Server Log File give a file ~/.config/Code/User/workspaceStorage/xxx/redhat.java/jdt_ws/.metadata/.log
10. Quit VS Code, and repeat step 2 and 5 to clear any settings
11. Delete the .project and .classpath files in the project directory.
12. Open the project again in the same way as in step 7
13. Observe that the "Opening Java projects" popup appear, but "Projects are imported into the workspace" do not. If you open the Program.java file and right-click on the "Program" identifier after the "class" keyword and select Find All References you get no results.
14. Quit VSCode and restore the .project and .classpath files by unzipping eclfiles.zip again
15. Do not clear any settings this time, but repeat step 7
16. Observe that the project now works again after the files were restored.

The issue is also reproducible if the settings are not cleared, or if the full Extension Pack for Java is installed.

Current Result

In step 13 above the language server appears broken.

Expected Result

Step 13 above should be similar to step 8.

Additional Informations

In the case where the import is successful (step 8), the language server receives a workspace/executeCommand java.project.getSettings, which it does not if the Eclipse project files are missing (step 13).

If you have a multi-module Maven project which was imported in an old version of VSCode, and had .project and .classpath generated for the existing modules at the time, and you now add a new module for instance by pulling an update from a Git repository, the project files are not automatically generated for this new module and the project looks partially broken.

project.zip
eclfiles.zip
settings.zip
step8-client.log
step8-jdt_ws.log
step13-client.log
step13-jdt_ws.log

Commencez par les fichiers project.zip, eclfiles.zip et settings.zip fournis, ainsi que par les journaux du client et du language server des étapes 8 et 13. Comparez les chemins d’importation, en particulier pour déterminer si workspace/executeCommand java.project.getSettings est envoyé lorsque .project et .classpath sont absents. C’est terminé lorsqu’un projet sans ces fichiers est importé et fournit le même comportement de références du Java language server que le cas fonctionnel.