The extension[-pack] creates bloatware-like files in root of project directory

[martinandersson]

The following files are randomly created in the root of my Gradle project dir:

• bin/*
• .settings
• .classpath
• .project

The three latter I think are specific for the Eclipse IDE or a derivative thereof.

Don't get me started why I think this behavior is totally unprofessional and unacceptable lol.

[andxu]

@martinanderssondotcom what's are you ideas representing a java project which contains the source output folder, the java version, the referenced libs? Other java products have their project specific files, how to avoid the project configuration file?

[martinandersson]

Andxu,

Why are these files there to begin with? Why is the plugin stateful? I think we should try our utmost hardest to keep VSCode being a simple, light and effective text editor. If one wanna have an IDE which automagically integrate a few command line args into "run configurations", has built-in terminals and live football, then there's other options for that. And believe me - as Trump would have said - these tools will soon be bygones. I hope.

Either way.. you could throw that stuff into any random VSCode-specific directory. The point is that I am not as the end user using VSCode to have it throw stuff in my project dir which often is in version control. And quite frankly, I couldn't care less however many breadcrumbs he dump in his app-specific folders. I simply hope the app can manage that space on his own and survive a few versions until my next hard drive crash.

Just my five cents, of course =)

[DiabolusExMachina]

I also dislike all the generated files.

It looks really messy. How about placing them in an own folder into the .vscode folder. For example .vscode/.java/...

[andxu]

We have other users reporting the same issue: redhat-developer/vscode-java#478, see reply from fbricon:

It's going to be tricky. We depend on the eclipse platform for the Java support. We currently have no way to set project metadata to a custom location. Eclipse Che managed to do it by forking key eclipse plugins, but we probably won't do that. Best case scenario, we get Eclipse upstream to open up project metadata configuration, but even then, we'll most likely end up with one .vscode (or whatever) folder per project/module.
One advantage of keeping the eclipse metadata files as-is, is it allows you to open the same folders in Eclipse, Atom, VIM (with ycm), without adding more IDE/Editor specific stuff.

[andxu]

Personally I think we should generate it at .vscode because the editor is vscode, need to discuss with redhat guys about the project settings

[akaroml]

@DiabolusExMachina we are working on a fix in the Java Language Support extension. redhat-developer/vscode-java#618

[akaroml]

We understand that people just hate this but there is not much progress made.

@testforstephen could you take a further look at the new comments in the redhat-developer/vscode-java#618

[testforstephen]

Close it since it has been fixed by redhat.java extension. See more information here redhat-developer/vscode-java#618 (comment)