Stop generating metadata files at project's root

[jdneo]

resolve redhat-developer/vscode-java#618, requires redhat-developer/vscode-java#2153

There is a setting called java.import.generatesMetadataFilesAtProjectRoot to control whether the project metadata files will be generated at project root. By default it's false, meaning those files will be hidden.

Some known issues I found:
1. Buildship hard code the .settings/ folder location: eclipse/buildship#1111
2. When calling .getLocation() from the metadata file(i.e. project.getFile(".project").getLocation()), the file location always points to the project root. This is because the upstream implementation does not depend on FileStore to resolve the location, see FileSystemResourceManager#locationFor(). But getLocationURI() works fine.

Workaround: use FileUtil.toPath(xxx.getLocationURI()) in our implementation.

Signed-off-by: Sheng Chen sheche@microsoft.com

[rgrunber]

Change is working well for me. Played around with java.settings.url outside workspace, and within, and couldn't see any breakage.

[guw]

There is a setting called java.import.generatesMetadataFilesAtProjectRoot to control whether the project metadata files will be generated at project root. By default it's false, meaning those files will be hidden.

That's currently a system property. It should be more configurable. We have a large source code base which is modified by many different editors/IDEs. This change would break VS Code users unless the setting is detected somehow at startup/during import.

[jdneo]

@guw Because the file system contribution will take effect at very begin before the server and client start communication via LSP. So it is a system property instead of a preference.

I don't think the change will break the users because we considered the compatibility in implementation:

1. If the system property is not set, those metadata files will be generated at the project root.
2. If the metadata files exist both in project root and the workspace storage, the files at the project root win.

In the code base you mentioned:

1. If those metadata files are added to .gitignore, that's not a problem because the metadata files won't exist in the code base, no matter what tools are used by users and how the tools generates metadata files, that only happens locally and won't affect anything in the code base.
2. If those metadata files are committed into the code base. Then the VS Code Java will use them, which means the behavior is still the same as before.

If in your implementation, you want to deal with those metadata files. You can use the standard API to do it. For example if you want to update the project nature, use: project.getDescription().setNatureIds(xxx). Just don't hard code the path and directly update it via file IO.

If you do want to get the file instance of the metadata files, for example, for the .project, use: FileUtil.toPath(project.getFile(IProjectDescription.DESCRIPTION_FILE_NAME).getLocationURI()).toFile()

[testforstephen]

LGTM. Have a try, it works with Maven/Gradle/Invisible project.

[rgrunber]

Feel free to combine the commits and merge when ready.