路径|和 .project 文件说“再见”—— VS Code Java 1.1.0 背后的故事( 三 )_项目|问题|https|Code|Lin

因此，这一次我们直接从 Eclipse 底层文件系统入手分析，并最终发现了一枚解决问题的“银弹”：File System Provider 和 FileStore（注：虽然在软件工程领域，人们的共识是没有银弹，不过对于这一特定的问题，我们确实找到了一种比较“奇巧”的解决办法）。

银弹: https://0x9.me/EGhKL
软件工程： https://0x9.me/x8cAy

Eclipse 工作空间结构与 FileStore
Eclipse 在运行过程中会为整个工作空间维护一颗树形结构，树的节点代表了文件系统中的文件或目录，同时还保存了文件的一些重要信息，如修改时间等。
Eclipse 底层通过 FileStore 类将这些节点和文件系统中的文件进行关联。 FileStore 类还有一个重要特性：如果映射的对象是单个文件，那么 FileStore 还会负责提供这一文件的输入输出流。
这一特性为问题的解决带来了非常重要的思路：只要能够将元数据文件的输入输出流重定向到项目目录之外的位置，问题也许就能得以解决。带着这个假设，我们又发现了另一个关键线索：File System Provider 。

工作空间结构: https://0x9.me/0o8nL

树形结构: https://0x9.me/sw4Ga

方案三
File System Provider
File System Provider 是 Eclipse 平台对外开放的一个扩展点，它允许开发人员实现一个 Eclipse 文件系统接口（org.eclipse.core.filesystem.IFileSystem），并将其注册到扩展点上，用以处理具有特定 URI scheme 的文件请求。
于是我们从 File System Provider 这一拓展点入手，继承并覆盖了 Eclipse 默认处理 URI scheme 为 file 的文件系统，通过覆写其中的一些方法，让文件系统在处理元数据文件时，将文件路径重定向到项目路径之外的地方进行读写。相比于方案二，这一套方案的优点在于：

对其他模块完全透明，基本不需要进行修改就能正常工作，这同时还意味着较好的拓展性。
代码量很小，最终的实现，算上 JavaDoc 和注释，一共只有 300 行左右。

当然这个方案也并非完美，因为它要求其他模块通过 Eclipse 提供的 API 进行对元数据文件的读写操作。我们在实现过程中就发现上游 Buildship 在处理元数据文件时直接通过 JDK 中的文件 I/O API 进行读写，为此我们提交了一份变更请求将相关操作迁移到了 Eclipse API 上。