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

Symbolic Link: https://link.zhihu.com/?target=https%3A//en.wikipedia.org/wiki/Symbolic_link

方案二
使用 Eclipse Linked Resources（放弃）
和 Symbolic Link 的思路类似地，我们还可以选择使用 Eclipse Linked Resources：
Linked Resources: Linked resources are files and folders that are stored in locations in the file system outside of the project's location.
上文是 Linked Resources 的一段官方定义，它可以作为项目的一部分，但又允许存储在项目路径之外的其他位置。在 VS Code Java 中，我们对于 Unmanaged Folder（无构建系统的项目），就是通过 Linked Resources 机制将这些元数据文件隐藏的，它的实现原理如下图所示：

路径|和 .project 文件说“再见”—— VS Code Java 1.1.0 背后的故事

文章图片

Unmanaged Folder 实现原理
可以看到项目的实际路径放在了 Language Server workspace storage 中，用户通常并不知晓这一路径，同时在 .project 文件里我们定义了 Linked Resources 的目标路径，也就是用户在 VS Code 打开的文件夹位置，它作为项目的一部分，会像其他项目一样参与到构建过程当中，其开发体验是类似的。
相同的原理可以应用到 Maven 项目和 Gradle 项目的导入过程当中来解决这一问题，因此，我们在 M2E 模块上进行了一些实验。 M2E 模块在 Java 语言服务中负责 Maven 项目的导入，通过改动模块中的相关代码，并利用 Linked Resources 机制就可以将元数据文件生成到项目路径之外的地方。
最终的实验结果是可行的，但是这套方案的缺点也非常明显：

改动较大：需要改动的代码散落在整个模块的不同文件中（大约十几处），同时因为代码规模较大，没有办法在短时间内确定这些改动是否是完备的。
对下游模块不透明：因为多了一层 Linked Folder ，这会让 Java 项目视图在展示项目结构时，多出一层代表了 Linked Folder 的目录结构。在 Java 项目视图的实现中需要增加一些额外的控制逻辑，让项目结构的展示和正常项目一样。
可行性未知：对于 Maven 和 Gradle 构建系统的支持模块 M2E 和 Buildship 都是上游项目，这一概念能否被采纳接受是个未知数。
扩展性差：如果要支持一套新的构建系统，需要将类似的逻辑再实现一遍。

考虑到上述原因，团队在经过讨论之后决定暂时放弃 Eclipse Linked Resources 方案，并继续寻找更优的解决办法。