Stop generating metadata files at project's root by jdneo · Pull Request #1900 · eclipse-jdtls/eclipse.jdt.ls

jdneo · 2021-10-09T05:19:48Z

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/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

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

Signed-off-by: sheche <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 · 2021-11-20T16:26:45Z

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 · 2021-11-21T09:32:33Z

@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:

If the system property is not set, those metadata files will be generated at the project root.
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:

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.
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()

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

testforstephen

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

rgrunber · 2021-11-23T21:09:32Z

Feel free to combine the commits and merge when ready.

lsp-java used to treat this as a configuration property of jdtls. However it is not a standard lsp configuration property. Instead it must be passed as a Java System Property on the command line invoking jdtls. See [JLFsUtils.java](https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/master/org.eclipse.jdt.ls.filesystem/src/org/eclipse/jdt/ls/core/internal/filesystem/JLSFsUtils.java#L192-L197) for how this property is read. Also see [eclipse-jdtls/eclipse.jdt.ls#1900](eclipse-jdtls/eclipse.jdt.ls#1900 (comment)) for an explanation of why this is a system property and not a regular LSP configuration property. Use a regular `defcustom` instead of using `lsp-defcustom` for declaring lsp-java-import-generates-metadata-files-at-project-root. Use this defcustom variable lsp-java--ls-command to pass an appropriate value for `java.import.generatesMetadataFilesAtProjectRoot`. With this change importing a Gradle-based java project into LSP will nolonger create `.classpath`, `.settings`, and `.project` entries at the root of the project.

lsp-java used to treat this as a configuration property of jdtls. However it is not a standard lsp configuration property. Instead it must be passed as a Java System Property on the command line invoking jdtls. See [JLFsUtils.java](https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/master/org.eclipse.jdt.ls.filesystem/src/org/eclipse/jdt/ls/core/internal/filesystem/JLSFsUtils.java#L192-L197) for how this property is read. Also see [eclipse-jdtls/eclipse.jdt.ls#1900](eclipse-jdtls/eclipse.jdt.ls#1900 (comment)) for an explanation of why this is a system property and not a regular LSP configuration property. Use a regular `defcustom` instead of using `lsp-defcustom` for declaring lsp-java-import-generates-metadata-files-at-project-root. Use this defcustom variable in `lsp-java--ls-command` to pass an appropriate value for `java.import.generatesMetadataFilesAtProjectRoot`. With this change importing a Gradle-based java project into LSP will nolonger create `.classpath`, `.settings`, and `.project` entries at the root of the project.

jdneo mentioned this pull request Oct 9, 2021

Stop generating metadata files at project's root redhat-developer/vscode-java#2153

Merged

This comment has been minimized.

Sign in to view

jdneo mentioned this pull request Oct 19, 2021

Any way to get rid of .project .classpath .settings/ files? redhat-developer/vscode-java#618

Closed

jdneo force-pushed the cs/metadata branch from fd41909 to cdf9614 Compare October 19, 2021 06:39

This comment has been minimized.

Sign in to view

jdneo force-pushed the cs/metadata branch from cdf9614 to 192b072 Compare October 20, 2021 07:27

Eskibear mentioned this pull request Oct 20, 2021

Automatically import pom.xml if .java source code is opened in editor microsoft/vscode-maven#753

Open

jdneo force-pushed the cs/metadata branch from 192b072 to 03ef9b8 Compare November 8, 2021 06:06

Stop generating metadata files at project's root

48f3d12

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

jdneo force-pushed the cs/metadata branch from 03ef9b8 to 48f3d12 Compare November 9, 2021 04:37

jdneo marked this pull request as ready for review November 9, 2021 05:07

jdneo requested review from CsCherrYY, Eskibear, akaroml, fbricon, rgrunber, snjeza and testforstephen November 9, 2021 05:08

jdneo changed the title ~~[WIP] Stop generating metadata files at project's root~~ Stop generating metadata files at project's root Nov 9, 2021

Hide the .factorypath file

29611f4

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

testforstephen requested changes Nov 17, 2021

View reviewed changes

Address comments

a805173

Signed-off-by: sheche <sheche@microsoft.com>

testforstephen reviewed Nov 18, 2021

View reviewed changes

Comment thread org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/filesystem/JLSFsUtils.java Outdated

testforstephen reviewed Nov 18, 2021

View reviewed changes

Comment thread org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/filesystem/JLSFileSystem.java

jdneo added 2 commits November 18, 2021 13:30

Address comments

c435f48

Signed-off-by: sheche <sheche@microsoft.com>

Generate metadata file at project root when client not set the property

136f2bf

Signed-off-by: sheche <sheche@microsoft.com>

rgrunber reviewed Nov 19, 2021

View reviewed changes

Comment thread org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/filesystem/JLSFile.java Outdated

Comment thread org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/filesystem/JLSFsUtils.java

Remove public modifiers and unused import statement

9d19a41

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

testforstephen approved these changes Nov 22, 2021

View reviewed changes

jdneo merged commit ecb29b4 into eclipse-jdtls:master Nov 24, 2021

jdneo deleted the cs/metadata branch November 24, 2021 04:33

testforstephen added this to the Mid November milestone Nov 24, 2021

rgrunber mentioned this pull request Mar 17, 2022

jdt.ls 1.9.0 breaks workspace loading #2024

Closed

ghost mentioned this pull request Mar 29, 2022

Stop generating .project .classpath .settings/ files neoclide/coc-java#196

Closed

Frank-D mentioned this pull request Sep 13, 2022

Add buildship auto sync preference redhat-developer/vscode-java#2673

Closed

crabbkw mentioned this pull request Jul 31, 2024

Fix usage of java.import.generatesMetadataFilesAtProjectRoot emacs-lsp/lsp-java#482

Merged

zaiqiang-dong mentioned this pull request Jan 23, 2025

generatesMetadataFilesAtProjectRoot do not work neovim/nvim-lspconfig#3582

Closed

tartarughina mentioned this pull request Jan 22, 2026

Prevent JDTLS from generating metadata files at project root zed-extensions/java#179

Merged

kilo-code-bot Bot mentioned this pull request Apr 8, 2026

fix(cli): prevent JDTLS from creating Eclipse metadata files in project root Kilo-Org/kilocode#8622

Merged

Uh oh!

Conversation

jdneo commented Oct 9, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rgrunber left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

guw commented Nov 20, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jdneo commented Nov 21, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

testforstephen left a comment

Choose a reason for hiding this comment

Uh oh!

rgrunber commented Nov 23, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jdneo commented Oct 9, 2021 •

edited

Loading

guw commented Nov 20, 2021 •

edited

Loading

jdneo commented Nov 21, 2021 •

edited

Loading