Any way to get rid of .project .classpath .settings/ files?

[Eskibear]

Every time I open a Java project, no matter Maven or Gradle, the extension always creates many .project .settings/ .classpath files in my project folder. And yes I know it's Eclipse's behavior to create files in project root folder as mentioned in #466 (comment) But it's really very annoying that the extension creates these files silently without any confirmation, especially with the SCM stuffs, I have to manually add them into .gitignore file. And I also have to add them into "files.exclude" in VSCode's settings to hide them from the explorer.

I've noticed some projects are also created in the "workspaceStorage" folder, so is it possible to create a corresponding project in the "workspaceStorage" folder and link my files to it? I followed this post in Eclipse, and find it adds <linkedResources> entries in .project. I suppose it might be somehow doable.

Moreover, it would be also nice for me if it notifies the changes and provides shortcuts to hide/ignore them, because I don't know and don't care about .settings/ stuffs. E.g. it might pop up a message box saying something like "Some files are created by the extension, do you want to add them into .gitignore?"

[fbricon]

The problem is we're delegating the import part to m2e and buildship, for Maven and Gradle projects, respectively, which do generate the project metadata files directly under the project folders, so changing that behaviour will be extremely hard, if not impossible.

Adding them to .gitignore is dependent on users using Git for their source control management, the Git integration on each client, so we'd need to be smart on how to send that sort of notification

[Eskibear]

The problem is we're delegating the import part to m2e ...... so changing that behaviour will be extremely hard, if not impossible.

@fbricon Thanks for the clarification, and I realize it might involve the whole project management part. In fact as a user I don't care that much about where you put the metadata files, just don't let me know the existence of these files. It does confuse me when I'm using VSCode to write Java and it generates a bunch of eclipse-looked files there. And one more point is, am I supposed to modify these files manually? I suppose that's not suggested, and usually some strange errors occur wrongly when I make some mistakes in modifying those files.

So I think if the extension manages these files and keep them invisible to me, it should help. It avoids confusion and potential errors caused by wrongly modifying/deleting metadata files. For me, a) hiding them from the explorer and b) add them into .gitignore both help a lot.

we'd need to be smart on how to send that sort of notification.

I'm not sure about the detailed implementation. Is it possible to detect whether there is a .gitignore file in workspace root foler, and if there is, append related rules to it? Then from git status, I see only one file changes instead of tons of new files added.

[fbricon]

I tried to add the following to the extension's package.json

   "configurationDefaults": {
        "files.exclude": {
          "**/.project": true,
          "**/.classpath": true,
          "**/.settings": true
      }
    },

but it seemed ignored by vscode. @aeschli is it expected?

[Eskibear]

While we cannot modify built-in configurations in "configurationDefaults", I think it would be helpful to provide a shortcut to add the "files.exclude" configuration into workspace settings. E.g. For the first time a project is built (these files are also created), a message box pops up saying "Ah we've created some important files, do you want to hide them from the explorer?". With the confirmation of the user, it automatically updates the workspace settings and hide these files immediately.

For me, every time I open different projects, I have to add the same "files.exclude" configurations to hide them, and also update the ".gitignore" file to exclude them from SCM. That is the pain point. So if there's any shortcut I can do that with one-click, the user experience will be largely improved. 😆

[akaroml]

We need to prioritize this one. Bad review again...

[fbricon]

We now partially address the problem by asking to hide those pesking files on startup:

You still need to manually add them to your SCM ignored list though.

[M-Jas]

@fbricon Does this ask you every time on Startup? I think I hit the close "x" the first time it came up(just like I do for everything), but I can't get this to popup again. Is there a way to Exclude this Globally with out the popup?

[yaohaizh]

@M-Jas If you doesn't want it pop up and without change anything, just click the "Never" selection.

[chuhsuanlee]

@M-Jas from File -> Preferences -> Settings -> User Settings -> Extensions -> Java configuration -> There's a section for "Check Project Settings Exclusions". It might popup again if the box is ticked (I didn't do experiment though)

@yaohaizh I thought the "Never" means "Never exclude", so it will show those files as default.

but my problem is actually, I remember I clicked "Exclude globally" before, but it still created bunch of these files, and show them all on the file explorer. Kinda weird.

[yaohaizh]

but my problem is actually, I remember I clicked "Exclude globally" before, but it still created bunch of these files, and show them all on the file explorer. Kinda weird.
@chuhsuanlee Does this issue still happen?

[ryanpagefico]

I am running into the same issue as @chuhsuanlee. I checked "Exclude globally" which worked once, but when I went to open another project it does not properly exclude. I also can't figure out a way to get the prompt to exclude the files to trigger again. I tried unchecking and rechecking to no avail.

[esr360]

This is so frustrating, why is my text editor creating random files for me?

[mkpaz]

Please, find a way to keep those files somewhere else. It's extremely annoying. I'd rather uninstall this extension completely then allow to keep them in project root. VSCode isn't IDE, so it's supposed to be lightweight, which also means no bloated project files and metadata as well.

[mrk-han]

This has been a huge pain for me -- it's even adding files to my android studio projects!

git clean -fd has been magic... :)

[davydden]

I am using VSCode only to edit (+intellisense) Java files in a very large project which has all the settings/project/config files. Asking Git to check them back every time is not really an option...

There should be an option not to create those files.

[friederbluemle]

Without knowing the details, is it possible to somehow fix the root cause (i.e. the part of the code that creates these files/folders in the first place)? I understand it might be an upstream package, or something that is not in direct control of this repository.
Again just asking, since this issue it the one reason I do not install this extension for my vscode.

[bgeihsgt]

Note I tried this plugin and am promptly uninstalling it because of this issue. I don't ever expect VSCode to generate files on my behalf unless it's the result of an explicit action I took (beyond just opening some folders VSCode).

[noahsark769]

Just throwing my hat into the ring to say that it's really annoying that VSCode generates these files. It's super annoying to have to git clean -df them every time, enough to make me not want to use VSCode for Android projects.

[akaroml]

We'll revisit this issue.

[fbricon]

@masbaehr change your settings.json:

    "files.exclude": {
        "**/.classpath": false,
        "**/.project": false,
        "**/.settings": false,
        "**/.factorypath": false
    },

[james-lawrence]

this behavior breaks projects from building properly its a little more problematic than just creating the files within a workspace.

as noted above this setting seems to fix the problem, but also seems to cripple autocomplete.

"java.server.launchMode": "LightWeight"

this setting seems to control the negative behavior directly, but also completely breaks code navigation and auto complete:

"java.import.maven.enabled": false

the fact this plugin adds the following to 'hide' the files is problematic by itself. these kind of changes to a users configuration shouldn't be made automatically.

    "files.exclude": {
        "**/.classpath": true,
        "**/.project": true,
        "**/.settings": true,
        "**/.factorypath": true
    },

unfortunately i'm not a maven build expert but seems to me that it should strive to mimic the maven commands behavior. which doesn't create such files (at least based on my mvn settings.xml).

[jdneo]

@james-lawrence there is a work going on to generate these file into other places. Please stay in tune.

[dsyer]

I appear to be in a minority here, but as an actual Java developer, not just browsing code but actually working on it, I need the language server and all that goodness. So I'm quite happy to add .project and .classpath to my .gitignore and have them generated by this extension. It's automatic with all the projects I work on anyway.

In fact as microsoft/vscode-maven#753 explains, I would actually rather like more of these files to be generated than are currently by default. I would also like more control over it, so in that way at least I am in agreement with the majority of comments here. If the others can switch them off entirely, I ought to be able to opt in easily (e.g. by a context menu, or a quick fix).

[james-lawrence]

@dsyer I'm actively developing java as well. the problem with not obeying the build tool's configuration is that generating those files can actively break an environment. which is exactly what it did to my environment. an tool such as this should never do things by default that can break environments. it needs to respect that other tools work within the same workspace.

[jdneo]

@dsyer Yes our plan is to make it configurable by a VS Code setting. User can decide whether to generate them at project root or not.

[jdneo]

Hi @james-lawrence, could you give more details about generating those files can actively break an environment?

[james-lawrence]

the classpath files conflicted with the classpath files created by maven, resulting in two different versions being loaded into generated war files leading to errors about already defined classes.

nested exception is org.springframework.context.annotation.ConflictingBeanDefinitionException
conflicts with existing, non-compatible bean definition of same name and class

I didn't dig much further than that I just turned off this plugin because it was getting in the way and causing problems.

so if this plugin is going to be using its own infrastructure to generate artifacts for implementing features they need to happen, by default, in their own self contained directory.

[james-lawrence]

personally I'd see if its possible to get maven to say where it outputs this data and then just look there. but afraid I'm still spinning up on java after a decade of not using it, so not sure if this is even possible.

but these might be of use:

• https://mkyong.com/maven/where-is-maven-local-repository/
• https://stackoverflow.com/questions/16655010/in-maven-how-output-the-classpath-being-used

[dsyer]

Maven does not emit or consume these files. It’s all for the language server. If there’s a conflict in your environment it’s probably because someone else was using Eclipse and (mistakenly IMO) checked these files into source control.

[james-lawrence]

they are not checked into source control. they are created by this tool and broken the generated war. why is immaterial. the problem is with this tool assuming it is allowed to modify a workspace. its not.

[jcsahnwaldt]

@james-lawrence I don't think the ConflictingBeanDefinitionException was caused by the issue discussed here. This issue is about the files .classpath and .project, and the folder .settings. The links you shared don't mention any of these.

[james-lawrence]

@jcsahnwaldt I'll retest I suppose but it absolutely started with this package and went away when disabled and I deleted the files.

[dsyer]

It's pretty normal for an IDE to create metadata for itself. We normally just exclude them from source control and move on. It's quite unlikely that they have an effect on the artifact built by the build tool, and they seem like a small price to pay (to me) to have all the language awareness in the editor. If your war build broke that's sad, but I don't think the explanation for that will directly be the metadata files. I have seen instances of VSCode (actually m2e in the language server probably) trying to modify the compilation when Maven on the command line was also trying to make the same change, and then one of them can fail. Usually that is a short-lived situation while VSCode figures out what is going on, and simply retrying will fix it. I suppose there might be a scenario where Maven manages to build a war file that contained the wrong stuff because m2e was busy trying to generate them, but I haven't seen that particular failure mode. Anyway, it seems orthogonal to the existence or not of the metadata files, so maybe it would be better to try and reproduce the problem and report it separately?

[james-lawrence]

@dsyer its normal for an IDE to create metadata files in its own space, not in the source tree itself. everyone claiming that it doesn't impact artifacts and builds are just wrong, because i'm literally seeing it happen. it may not happen in your setups, it happens in mine.

1. mvn clean install - works
2. enable this plugin and wait for files to be generated
3. mvn clean install - errors out.
4. disable plugin, restart vscode, cleanup generated files
5. mvn clean install - works

I see no need to report it separately when this issue is about the exact cause of my issue.

[jdneo]

@james-lawrence According to the description, I guess your second mvn clean action cause the problem.

Just as @dsyer said I have seen instances of VSCode (actually m2e in the language server probably) trying to modify the compilation when Maven on the command line was also trying to make the same change both mvn and VS Code try to update the output folder and cause a conflict condition. See: #1912 (comment)

[james-lawrence]

@jdneo I'll happily test that case, give me a bit. i'll leave the files and just shutdown vscode. regardless don't pollute the workspace. its simply not necessary.

[james-lawrence]

@jdneo looks like @dsyer is correct, just disabling vscode and leaving the files built correctly. ug. what a shit show. ;) well I stand corrected.

[jdneo]

For anyone who are watching this thread. In the next release we will have a new setting java.import.generatesMetadataFilesAtProjectRoot to set whether those metadata files will be generated in the project root or not.

By default it's false, means they will be hidden in the workspace storage.

More information about how to change it, check here: https://github.com/redhat-developer/vscode-java/blob/master/document/_java.metadataFilesGeneration.md#change-the-setting-value

[tarekahf]

@masbaehr change your settings.json:

    "files.exclude": {
        "**/.classpath": false,
        "**/.project": false,
        "**/.settings": false,
        "**/.factorypath": false
    },

This allowed be to show the .settings folder in my VS Code Explorer. Thanks!