文章图片
【和 .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 都是上游项目 ， 这一概念能否被采纳接受是个未知数 。
- 扩展性差 ：如果要支持一套新的构建系统 ， 需要将类似的逻辑再实现一遍 。
- 项目视图: https://0x9.me/sMYkz
放弃第二套方案还有另一个原因：Eclipse 自发布至今二十载 ， 在保证稳定运行的同时 ， 可以不断地增加新的功能且提供了出色的拓展能力 ， 在这背后一定蕴含了优秀的架构设计和可拓展性 。 直觉上让我们觉得应该还会有更优雅的解决办法 。
因此 ， 这一次我们直接从 Eclipse 底层文件系统入手分析 ， 并最终发现了一枚解决问题的“银弹”：File System Provider 和 FileStore（注：虽然在软件工程领域 ， 人们的共识是没有银弹 ， 不过对于这一特定的问题 ， 我们确实找到了一种比较“奇巧”的解决办法） 。
- 银弹: https://0x9.me/EGhKL
- 软件工程： https://0x9.me/x8cAy
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 的文件请求 。
特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。