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. This is all occurring with Buildship 1.0.15.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 (. gitignore one of the Eclipse files overwritten? I would prefer that this not be so.gitignore has more to do with version control than it does with Eclipse. One more question on this general score: when choosing overwrite, is. classpath file with the unwanted bin output directory every time. This would be less painful if the “keep/overwrite” option on Eclipse metadata, for which I’d like to make “overwrite” the best practice, didn’t “trash” my. Frequently I must do this two or three times, and I don’t mind it, it’s a relatively painless way to learn to get it right. What makes this even more annoying is that with the current state of buildship I find myself needing to delete the Eclipse project while leaving the local Git repository that backs it alone, making some change, and then reimporting. In gradle, they should be under build/classes, not just adopt the Eclipse default. I think that Gradle should take a cue from the Maven tooling here. The outlier here, the one that does not fit with gradle, is the default Eclipse assumption that the default place to put class files is /bin. If not for the fact that I build a lot of rpms and a bin folder is sometimes used for shell scripts and the like. **/.gradle/ these entries keep eclipse metadata out of source control:īut then there is that miserable bin directory. This almost works but for the bin directory We are close, very close, to being able to specify a repeatable gitignore syntax at the root project level. More irritating than this is the lack of a nice repeatable. It impacts me in the following ways:Īs the original topic says, it is confusing to have two folders for java class files in Eclipse, one for the automatic building, one for builds with the gradle tooling. The more I think about it, this is a bug. I raised this a couple of weeks ago and received no reply. Continuing the discussion from When buildship imports a java project it doesn't change the "Build Path" output folder:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |