[Hinweis] Eine Geschichte über das Ändern von Java-Build-Tools mit VS-Code

Einführung

Ich habe Java mit VS-Code codiert und mich wirklich mit dem Lösen von Abhängigkeiten beschäftigt.

Selbst nach Anhörung der öffentlichen Meinung (* Stack Overflow) wird bei der Aktualisierung von pom.xml ein Bestätigungsdialogfeld wie "Möchten Sie das Update wiedergeben?" Angezeigt, das ordnungsgemäß wiedergegeben wird.

Die einzige Möglichkeit bestand darin, dass ein Problem mit dem Java Language Server-Cache aufgetreten ist und dass dieser gelöscht werden sollte.

Machen wir das.

Aktion 1 (Fehler)

Die betreffende VS-Code-Umgebung wird unter Ubuntu mit WLS2 unter Verwendung von Remote-WLS ausgeführt. VS-Code-Cache-Daten befinden sich am folgenden Speicherort.

~/.vscode-server/data/User/workspaceStorage/

Beenden Sie VS Code einmal, greifen Sie über das Windows-Terminal auf das Ubuntu-Terminal zu und löschen Sie die zwischengespeicherten Daten. Starten Sie dann VS Code neu. Wenn es sich um ein Cache-Problem handelt, ist dies die Lösung. Um ehrlich zu sein, dachte ich, ich hätte gewonnen. Wenn das funktioniert, sind wir nicht süchtig nach dem Verhalten des Tools, und ich würde keinen Artikel wie diesen schreiben, also war dieser Gedanke nur eine Illusion.

Es überrascht nicht, dass die Abhängigkeiten des neu gestarteten VS-Codes nicht aktualisiert wurden. Ich habe mvn compile vergeblich versucht, aber es hat überhaupt nicht reagiert. Als ich dachte, es sei eine Pattsituation, fiel mir plötzlich etwas ein. Ja, ich kann mich nicht erinnern, den Beispieldialog gesehen zu haben, der angezeigt werden sollte, wenn ich pom.xml bearbeitet habe.

Der Gedanke, mich zu wundern, geht mir durch den Kopf. Dieser Beispielcode kann nicht nur mit maven, sondern auch mit gradle erstellt werden. Ich bin keine Gradle-Sekte, daher ist bundle.gradle, von dem ich vorgab, dass es völlig unsichtbar ist, auch in diesem Beispielcode enthalten ... in derselben Hierarchie wie 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>

Unbeabsichtigt wurde ich halb gelacht. Eigentlich bin ich seit weniger als zwei Stunden von diesem Problem abhängig. Es ist ein schmerzhafter Schlag. Es gibt keinen Ort, um dieses unkonzentrierte Gefühl zu treffen. Dieser .classpath ist eine Datei, die die Verzeichnisse und Bibliotheken angibt, die im Ziel für die Abhängigkeitsauflösung auf der VS-Codeseite enthalten sein sollen, und wird automatisch generiert. Unabhängig davon, wie oft Sie die pom.xml von maven neu schreiben, werden die Abhängigkeiten nicht berücksichtigt. Es wurde von Anfang an nicht referenziert ... haha (´ ･ ω ･ `)

Es gibt zwei Möglichkeiten, um dieses Phänomen zu lösen. ・ Schalten Sie das Build-Tool auf gehorsam um.

• Generieren Sie den .classpath zwangsweise neu, sodass die Abhängigkeit von maven referenziert wird.

Aktion 2 (erneuter Fehler)

Es war ein Wutanfall, der auf Gradles Armeetor fiel, also entschied ich mich ohne zu zögern für Letzteres. Ich habe VS Code beendet und .classpath und build.gradle vom Terminal entfernt. Wenn Sie jetzt neu starten, wird kein .classpath basierend auf maven erstellt, oder? Hmm?

Ich war ein wenig besorgt, aber der Schuldige war .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>

Es sagt Gradle in vollen Zügen. Lassen Sie uns das auch tun. Starten Sie VS Code neu. Dieses Mal wurde die Abhängigkeit basierend auf Maven richtig reflektiert. .Project und .classpath werden jedoch nicht generiert ... Code ist in Ordnung, aber sehr unangenehm. Es kann auch eine Suchtursache sein.

Außerdem frage ich mich, wann .project und .classpath generiert werden. Lassen Sie uns überprüfen.

Überprüfung

Erstellen Sie ein anderes Verzeichnis und klonen Sie es erneut aus dem ursprünglichen GitHub-Repository. Als ich es mit VS Code öffnete ... wurde es generiert.

Dies ist der Status des Zielverzeichnisses, das gerade geklont wurde

Dies ist der Status nach dem Starten von VS Code. Zu diesem Zeitpunkt wurde bereits ein .project generiert und das Innere wurde geschrieben, um gradle zu verwenden. Es gibt auch einen Klassenpfad. Selbstverständlich habe ich angefangen, Gradle zu verwenden. Anscheinend hat Gradle Vorrang vor Maven.

Die folgenden Dateien und Verzeichnisse wurden hinzugefügt. ・ .Klassenpfad Rad .Gradle ・ .Projekt · .Die Einstellungen · Behälter Dies bedeutet, dass VS Code beim Öffnen des Verzeichnisses (wahrscheinlich) build.gradle als Build-Tool verwendet, eine .project-Datei generiert und die gradle-basierte Projektumgebung automatisch ist. Ich denke, dass es als Ziel gesetzt ist. Jetzt klonen wir dieses Projekt erneut und überprüfen das Verhalten, wenn build.gradle gelöscht wird. Das Verzeichnis vor dem Öffnen von VS Code sieht folgendermaßen aus.

Beim Öffnen mit VS-Code wurden sowohl .project als auch .classpath generiert.

.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>

Beide wurden durch die Maven-Basis ersetzt. Das ist mein Ziel.

Aktion 3 (Erfolg)

Was reichte dann nicht aus, um das, was VS Code einst als Gradle-Projekt erkannte, als Maven-Projekt wiederzuerkennen? Ich habe build.gradle, .classpath und .project früher aus dem gradle-Projekt entfernt, aber es enthält auch automatisch generierte Verzeichnisse und gradle-bezogene Ressourcen. Verdächtig ist jedoch die automatisch generierte Ressource. Deshalb lasst uns sie alle mv. ... das wird sich nicht ändern, oder?

Also kam ich mit einer Stecknadel. Die Ursache war, dass ich .project und .classpath in ein Verzeichnis namens backup unter dem Projektstamm verschoben habe. Anscheinend gibt es eine Spezifikation, die besagt, dass .project, auch wenn es sich nicht im Stammverzeichnis befindet, gelesen wird, wenn es in einem Unterverzeichnis vorhanden ist. Durch Entfernen von .project und .classpath wurde ein neues .project und .classpath generiert und das Project Build Tool auf maven umgestellt.

Zusammenfassung

• Im Java Extension Pack von VS Code wird beim ersten Öffnen des Verzeichnisses, in dem pom.xml oder build.gradle vorhanden ist, ein .project generiert und als Java-Projekt erkannt. --Wenn sowohl build.gradle als auch pom.xml vorhanden sind, hat gradle Vorrang.
• Sobald das Build-Tool entschieden wurde, gibt es keine Möglichkeit, es auf der VS-Code-Seite zu ändern. (Deshalb bin ich süchtig danach, dumme Dinge zu tun, wie nur pom.xml zu ändern)
• Wenn Sie zusätzlich zu build.gradle das Build-Tool migrieren möchten, müssen Sie .project und .classpath löschen und das Verzeichnis dann erneut mit VS Code öffnen. --mv und remove sind unterschiedlich.

Es ist das. Ich habe viel Umweg gemacht, aber ich konnte das Build-Tool erfolgreich auf Maven umstellen.

Glückwunsch Glückwunsch.

Toppin Parari no Puu.