[Note] A story about changing Java build tools with VS Code
Introduction
I was coding Java in VS Code, and I was really into solving Dependency. As a memorandum (probably I'm addicted to it again), I will describe the process of the investigation.
It happened after I tried to modify the Spring Boot sample code that I cloned from GitHub, and rewrote pom.xml in good condition.
"The added dependency is not reflected in VS Code ...?"
From there, the investigation began.
Investigation
Java Extension Pack is the only Java-related extension installed in VS Code, so if you have a problem with Java Extension Pack, you should be able to find out by asking the public (* Google).
However, even when I hear the opinions of the public (* Stack Overflow), when I update pom.xml, a confirmation dialog like "Do you want to reflect the update?" Appears and it is reflected properly.
The only possibility was that there was a problem with the Java Language Server cache and that it should be cleared.
let's do it.
Action 1 (failure)
The VS Code environment in question is running on Ubuntu with WLS2 using Remote-WLS. VS Code cached data is located in the following location:
~/.vscode-server/data/User/workspaceStorage/
Exit VS Code once, access the Ubuntu terminal from Windows Terminal, and delete the cached data. Then restart VS Code. If it's a cache problem, this is the solution. To be honest, I thought I won. Well, if that works, we're not addicted to the behavior of the tool, and I wouldn't write an article like this, so that thought was just an illusion.
Not surprisingly, the dependencies haven't been updated on the restarted VS Code. I tried mvn compile in vain, but it didn't respond at all. When I thought it was a stalemate, I suddenly remembered something. Yes, I don't remember seeing the example dialog that should be displayed when I edited pom.xml.
The thought of wondering runs through my head. This sample code can be built not only with maven but also with gradle. I'm not usually a gradle sect, so bundle.gradle, which I pretended to be completely unseen, is also included in this sample code ... in the same hierarchy as pom.xml.
.classpath
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" output="bin/main" path="src/main/java">
<attributes>
<attribute name="gradle_scope" value="main"/>
<attribute name="gradle_used_by_scope" value="main,test"/>
</attributes>
</classpathentry>
<classpathentry kind="src" output="bin/test" path="src/test/java">
<attributes>
<attribute name="gradle_scope" value="test"/>
<attribute name="gradle_used_by_scope" value="test"/>
<attribute name="test" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="src" output="bin/main" path="src/main/resources">
<attributes>
<attribute name="gradle_scope" value="main"/>
<attribute name="gradle_used_by_scope" value="main,test"/>
</attributes>
</classpathentry>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8/"/>
<classpathentry kind="con" path="org.eclipse.buildship.core.gradleclasspathcontainer"/>
<classpathentry kind="output" path="bin/default"/>
</classpath>
Unintentionally, I became half laughed. Actually, I've been addicted to this problem for less than two hours. It's a painful blow. There is no place to hit this unfocused feeling. This .classpath is a file that specifies the directories and libraries to be included in the target for dependency resolution on the VS Code side, and is automatically generated. Well, no matter how much you rewrite maven's pom.xml, the dependency will not be reflected. It wasn't referenced from the beginning ... haha (´ ･ ω ･ `)
There are two options for solving this phenomenon. ・ Switch the build tool to gradle obediently. -Forcibly regenerate .classpath so that the dependency is referenced by maven.
Action 2 (Failure again)
It was a tantrum that fell on gradle's army gate, so I chose the latter without hesitation. I quit VS Code and mved .classpath and build.gradle from the terminal. Now when you reboot, a .classpath will not be created based on maven ... right? Hmm?
I was a little worried, but the culprit was .project.
.project
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>spring-boot</name>
<comment>Project complete created by Buildship.</comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.buildship.core.gradleprojectbuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.eclipse.jdt.core.javanature</nature>
<nature>org.eclipse.buildship.core.gradleprojectnature</nature>
</natures>
</projectDescription>
It says gradle to the fullest. Let's mv this too. Restart VS Code. This time, the dependencies are properly reflected based on maven. However, .project and .classpath are not generated ... It's okay to code, but it's very unpleasant. It can also be a cause of addiction.
Also, I'm wondering when .project and .classpath are generated. Let's verify.
Verification
Create another directory and clone it again from the original GitHub repository. When I opened it with VS Code ... it was generated.
This is the state of the target directory that has just been cloned
This is the state after starting VS Code. At this point a .project was already generated and the inside was written to use gradle. There is also a .classpath. As a matter of course, I started to use gradle. Apparently, gradle has priority over maven.
The following files and directories have been added. ・ .Classpath ・ .Gradle ・ .Project ・ .Settings ・ Bin In other words, when VS Code opens the directory, (probably) chooses to use build.gradle as a build tool, generates a .project file, and the project environment is automatic based on gradle. I think that it is set as a target. Now, let's clone this project again and check the behavior when build.gradle is deleted. The directory before opening VS Code looks like this.
When I opened it in VS Code, both .project and .classpath were generated.
.project
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>spring-boot</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.m2e.core.maven2Builder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.eclipse.jdt.core.javanature</nature>
<nature>org.eclipse.m2e.core.maven2Nature</nature>
</natures>
</projectDescription>
.classpath
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" output="target/classes" path="src/main/java">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="src" output="target/test-classes" path="src/test/java">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
<attribute name="test" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8">
<attributes>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
<attributes>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="src" path="target/generated-sources/annotations">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
<attribute name="ignore_optional_problems" value="true"/>
<attribute name="m2e-apt" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="src" output="target/test-classes" path="target/generated-test-sources/test-annotations">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
<attribute name="ignore_optional_problems" value="true"/>
<attribute name="m2e-apt" value="true"/>
<attribute name="test" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="output" path="target/classes"/>
</classpath>
Both have been replaced by maven base. This is my goal.
Action 3 (success)
So what wasn't enough to re-recognize what was once recognized as a gradle project in VS Code as a maven project? I mved build.gradle, .classpath, and .project from the gradle project earlier, but it also contains auto-generated directories and gradle related resources. But what is suspicious is the automatically generated resource. Therefore, let's mv them all. ... that won't change, right?
So I came with a pin. The cause was that I mved .project and .classpath to a directory called backup under the project root. Apparently, there is a specification that even if .project is not under the root directory, it will be read if it exists in a subdirectory. By deleting the .project and .classpath, a new .project and .classpath was generated and the project build tool was switched to maven.
Summary
--In VS Code's Java Extension Pack, the first time you open the directory where pom.xml or build.gradle exists, a .project will be generated and recognized as a Java project. --If both build.gradle and pom.xml are present, gradle takes precedence. --Once the build tool has been decided, there is no way to change it on the VS Code side. (Therefore, I'm addicted to doing stupid things such as modifying only pom.xml) --If you want to migrate the build tool, you need to delete .project and .classpath and open the directory again with VS Code in addition to build.gradle. --mv and remove are different.
It is that. I made a detour a lot, but I was able to successfully switch the build tool to maven.
Congratulations, congratulations.
Toppin Parari no Puu.
Recommended Posts