The M2E module is responsible for the import of the Maven project in the Java Language Service. Therefore, we conducted some experiments on the M2E module. The same principle can be applied to the import process of Maven project and Gradle project to solve this problem. project file we define the target path of Linked Resources, which is the folder opened by the user in VS Code Location, as a part of the project, it will participate in the construction process like other projects, and its development experience is similar. You can see that the actual path of the project is placed in the Language Server workspace storage, the user usually does not know this path and in the. Principles of Unmanaged Folder Implementation Its implementation principle is shown in the following figure: In VS Code Java extensions, for the Unmanaged Folder (project without a build system), these metadata files are hidden through the Linked Resources mechanism. It can be used as part of the project, but it is allowed to be stored in other locations outside the project path. ![]() This is the official definition of 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. ![]() Option 2: Use Eclipse Linked Resources (Unsuccessful)Īnd Symbolic Link ideas Similarly, we can also choose to use the Eclipse Linked Resources : But soon this solution ran into problems – creating Symbolic Link under certain operating systems requires specific permissions, otherwise FileSystemException will be thrown, which is obviously not the effect we want, so this solution was immediately abandoned. When importing a project, you can link the imported project to a place invisible to the user through Symbolic Link, so that the metadata file is generated under the linked path. ![]() The first method we thought of was to use Symbolic Link. Option 1: Use Symbolic Link (Unsuccessful) In order to completely solve this issue that has been bothering users for more than three years, we decided to take another attempt in 2021 and see if we can find a “cure”. But based from user feedback, these methods did not satisfy users. Over the years, this problem has become in a “historical technical debt”.Ĭonsidering that changing the behavior of upstream modules may introduce many uncertainties, in the past we tried to provide users with some workarounds, such as hiding these metadata files in the file browser of VS Code, and guiding users to add them to. Since the path of these metadata files has been hard-coded in the code as constants during implementation, these constants have been referenced by various Eclipse modules and even plug-ins. The creation of this post can even be traced back to 2004. The official project name of the Java language service used behind the VS Code Java project is Eclipse JDT Language Server™ , which was jointly developed by Microsoft and Red Hat. As you can see in the project architecture diagram above, we reused some Eclipse modules in our implementation , and these automatically generated metadata files are also generated by some of the upstream modules. A related discussion thread can be found in the Eclipse discussion area. JDT Java Language Server architecture diagram The root cause starts with the architecture of Java Language Services: In fact, this is not because our product team does not want to completely fix this problem. As the user base increases, this problem will also likely to cause negative impact for more users. However, due to the problem that the Java extension generates metadata files in the project directory when importing the project, we have received a lot of frustration from the users. With more features introduced into Java extension on Visual Studio Code, the number of our users is also steadily increasing. This blog post shares our journey of solving this problem and the final solution. This issue was reported more than three years ago and it has been there since 2018. classpath, settings, etc.) will no longer be generated in the project path by default. Recent 1.1.0 release of Language Support for Java ™ contains an important update: now when the extension imports a new Java project, the project metadata files (.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |