Bug 576175 - Allow .classpath file to not be at project root via linked resource apporach
Summary: Allow .classpath file to not be at project root via linked resource apporach
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.22   Edit
Hardware: PC All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-21 22:37 EDT by Sheng Chen CLA
Modified: 2021-09-22 01:58 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sheng Chen CLA 2021-09-21 22:37:03 EDT 
#0. TL;DR

This is to ask if we can use the linked resource approach to persist the .classpath file out of the project root. (i.e. into the workspace metadata folder)

#1. Background

A lot of VS Code Java (back-ended by Eclipse JDT.LS) complains that after importing Java projects, a lot of files generated in the root of each project, including:
   -  .project
   -  .settings/
   -  .classpath (this is generated by JDT)

They hope these files not be generated at the project root since it will mess up their SCM.

Here is the original issue, which is the most top one in the repo: https://github.com/redhat-developer/vscode-java/issues/618

We have a discussion at the Resources plugin https://bugs.eclipse.org/bugs/show_bug.cgi?id=576013, where Mickael suggested to use linked resource to 'redirect' the .classpath file out of the project root.
Comment 1 Andrey Loskutov CLA 2021-09-22 01:58:08 EDT 
If you have POC, please try ro run all JDT tests with it, that would be the best answer if the POC works or not with JDT. I assume lot of code expects .classpath to be in the project root. So if you manage to keep IResource API to return .classpath as a member of the project and also find it via project/.classpath path - the rest would be probably just effort to cleanup code that uses java.util.File etc to access it (if there is such code).