[Note] Une histoire sur la modification des outils de compilation Java avec VS Code

introduction

Je codais Java avec VS Code, et j'étais vraiment intéressé par la résolution de la dépendance. Pour rappel (j'y suis probablement à nouveau accro), je décrirai le déroulement de l'enquête.

Cela s'est produit après avoir essayé de modifier l'exemple de code Spring Boot que j'ai cloné à partir de GitHub et réécrit pom.xml en bon état.

"La dépendance ajoutée n'est pas reflétée dans VS Code ...?"

À partir de là, l'enquête a commencé.

Enquête

Java Extension Pack est la seule extension liée à Java installée dans VS Code, donc si vous rencontrez un problème avec Java Extension Pack, vous devez demander au public (* Google).

Cependant, même après avoir entendu les opinions du public (* Stack Overflow), lorsque pom.xml est mis à jour, une boîte de dialogue de confirmation comme "Voulez-vous refléter la mise à jour?" Apparaîtra et elle sera reflétée correctement.

La seule possibilité était qu'il y avait un problème avec le cache de Java Language Server et qu'il devrait être effacé.

Faisons le.

Action 1 (échec)

L'environnement VS Code en question fonctionne sur Ubuntu avec WLS2 en utilisant Remote-WLS. Les données du cache VS Code se trouvent à l'emplacement suivant.

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

Quittez VS Code une fois, accédez au terminal Ubuntu à partir du terminal Windows et supprimez les données mises en cache. Puis redémarrez VS Code. S'il s'agit d'un problème de cache, c'est la solution. Pour être honnête, je pensais avoir gagné. Eh bien, si cela fonctionne, nous ne sommes pas accros au comportement de l'outil, et je n'écrirais pas un article comme celui-ci, alors cette pensée n'était qu'une illusion.

Sans surprise, les dépendances n'ont pas été mises à jour sur le code VS redémarré. J'ai essayé mvn compile en vain, mais il n'a pas du tout répondu. Quand j'ai pensé que c'était une impasse, je me suis soudainement souvenu de quelque chose. Oui, je ne me souviens pas avoir vu la boîte de dialogue d'exemple, qui devrait s'afficher lorsque j'ai édité pom.xml.

La pensée de m'interroger me traverse la tête. Cet exemple de code peut être généré non seulement avec maven mais également avec gradle. Je ne suis pas une secte gradle, donc bundle.gradle, que je prétendais être complètement invisible, est également inclus dans cet exemple de code ... dans la même hiérarchie que 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>

Sans le vouloir, je suis devenu à moitié ri. En fait, je suis accro à ce problème depuis moins de deux heures. C'est un coup douloureux. Il n'y a pas de place pour toucher ce sentiment flou. Ce .classpath est un fichier qui spécifie les répertoires et les bibliothèques à inclure dans la cible pour la résolution des dépendances du côté VS Code, et est généré automatiquement. Eh bien, peu importe combien vous réécrivez le pom.xml de maven, les dépendances ne seront pas reflétées. Il n'a pas été référencé depuis le début ... haha (´ ･ ω ･ `)

Il existe deux options pour résoudre ce phénomène. ・ Basculez l'outil de construction pour graduer docilement. -Régénérer le .classpath pour que la dépendance soit référencée par maven.

Action 2 (échec à nouveau)

C'était une crise de colère qui est tombée sur la porte de l'armée de Gradle, j'ai donc choisi cette dernière sans hésitation. J'ai quitté VS Code et mved .classpath et build.gradle à partir du terminal. Maintenant, lorsque vous redémarrez, un .classpath ne sera pas créé sur la base de maven, non? Hmm?

J'étais un peu inquiet, mais le coupable était .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>

Il dit gradle au maximum. Mettons cela aussi. Redémarrez VS Code. Cette fois, la dépendance était correctement reflétée sur la base de maven. Cependant, .project et .classpath ne sont pas générés ... C'est bien de coder, mais c'est très désagréable. Cela peut également être une cause de dépendance.

Aussi, je me demande quand .project et .classpath sont générés. Vérifions.

Vérification

Créez un autre répertoire et clonez-le à nouveau à partir du référentiel GitHub d'origine. Quand je l'ai ouvert avec VS Code ... il a été généré.

C'est l'état du répertoire cible qui vient d'être cloné

C'est l'état après le démarrage de VS Code. À ce stade, un .project a déjà été généré et l'intérieur a été écrit pour utiliser gradle. Il existe également un .classpath. Bien entendu, j'ai commencé à utiliser gradle. Apparemment, gradle a la priorité sur maven.

Les fichiers et répertoires suivants ont été ajoutés. ・ .Classe ・ .Gradle ・ .Projet · .Réglages · Poubelle En d'autres termes, lorsque VS Code ouvre le répertoire, (probablement) choisit d'utiliser build.gradle comme outil de construction, génère un fichier .project et l'environnement du projet est automatique basé sur gradle. Je pense qu'il est fixé comme objectif. Maintenant, clonons à nouveau ce projet et vérifions le comportement lorsque build.gradle est supprimé. Le répertoire avant d'ouvrir VS Code ressemble à ceci.

Lors de l'ouverture avec VS Code, les fichiers .project et .classpath ont été générés.

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

Les deux ont été remplacés par la base maven. C'est mon objectif.

Action 3 (succès)

Alors, qu'est-ce qui n'a pas suffi pour re-reconnaître ce qui était autrefois reconnu comme un projet gradle par VS Code comme un projet maven? J'ai mved build.gradle, .classpath et .project du projet gradle plus tôt, mais il contient également des répertoires générés automatiquement et des ressources liées à gradle. Mais ce qui est suspect, c'est la ressource générée automatiquement. Par conséquent, passons à eux tous. ... cela ne changera pas, non?

Alors je suis venu avec une épingle. La cause était que j'ai mved .project et .classpath dans un répertoire appelé backup sous la racine du projet. Apparemment, il existe une spécification selon laquelle même si .project n'est pas sous le répertoire racine, il sera lu s'il existe dans un sous-répertoire. En supprimant le .project et le .classpath, un nouveau .project et .classpath ont été générés et l'outil de génération de projet a été basculé vers maven.

Résumé

--Dans le pack d'extension Java de VS Code, la première fois que vous ouvrez le répertoire contenant pom.xml ou build.gradle, un .project sera généré et reconnu comme un projet Java. --Si build.gradle et pom.xml existent, gradle a la priorité. --Une fois que l'outil de construction a été décidé, il n'y a aucun moyen de le changer du côté VS Code. (Par conséquent, je suis accro à faire des choses stupides telles que modifier uniquement pom.xml)

• Si vous souhaitez migrer l'outil de construction, vous devez supprimer .project et .classpath et rouvrir le répertoire avec VS Code en plus de build.gradle. --mv et remove sont différents.

C'est ça. J'ai beaucoup fait un détour, mais j'ai réussi à passer l'outil de construction à maven.

Félicitations, félicitations.

Toppin Parari no Puu.