Buildship is not using Eclipse APIs to persist the .prefs files

[jdneo]

Currently the Buildship uses an own implementation to read/write preferences. But not using Eclipse API to do such jobs. Is it intended for some reasons? (See the Context section for more explanation about this request)

Expected Behavior

Use APIs provided by Eclipse to read and write preferences to the .settings/ folder

Current Behavior

The current implementation hard-code the .prefs file's location and read/write it directly via Java IO APIs

Context

In VS Code Java, there is an issue complained mostly about stop generating .project, .classpath, .settings files at the project root: redhat-developer/vscode-java#618. After some investigation, we found that we can use the Eclipse File System Provider extension point to customize the file location for some specific files. But that requires other plugins use Eclipse standard APIs to read and write files.

We found that In Buildship, there is a customized implementation to deal with the preferences, and the file is persisted directly via Java IO APIs.

This makes the extension point not working, so we'd like to know if this is done by some reasons? Or this is can be fixed to use the standard Eclipse API.

Steps to Reproduce

Your Environment

[donat]

The preference modification was implemented this way to avoid problems when the preference file cannot be written: the FS is not in sync, the project is closed, etc. The default implementation uses the Eclipse API, and falls back to the native file operation upon failure. IIRC JDT uses the same technique when importing Java projects.

[jdneo]

Thanks for sharing the background.

I did some search to JDT and m2e projects but did not find use case for that? I might be wrong because I'm not familiar with those repos.

Seems that in buildship there are some cases that the passing parameter is a folder path not IProject. Do you think it's acceptable to do following changes when we read/write the prefs file, just like the implementation buildship already have in DefaultConfigurationManager#loadBuildConfiguration()

public String readPreferences(File projectDir) {
    Preconditions.checkNotNull(projectDir);
    Optional<IProject> projectCandidate = CorePlugin.workspaceOperations().findProjectByLocation(rootDir);
    if (projectCandidate.isPresent() && projectCandidate.get().isAccessible()) {
        IProject project = projectCandidate.get();
        try {
    	    return readPreferences(project);
        } catch (Exception e) {
             /** Fallback to the file IO based function here */
        }
    }
    /** Fallback to the file IO based function here */
}