753 votes

Inspection d’IntelliJ donne « Ne peut pas résoudre le symbole » mais toujours compile le code

Plate-Forme: IntelliJ Community Edition Version 10.0.3
SDK: jdk1.6.0_21
Système d'exploitation: Windows 7

Donc, j'ai une drôle de situation avec IntelliJ qui m'a complètement perplexe. - Je créer un projet Maven et ajouter log4j comme une dépendance dans le pom.xml fichier. L'IDÉE des inspections exécution fine et mes tests d'unité tous les compiler et exécuter.

J'ai ensuite ajouté hunnysoft de jmime bibliothèque de mon référentiel maven local à l'aide de la mvn install:install-fichier comme suit.

mvn install:install-file -Dfile=jmime.jar -DgroupId=jmime \
-DartifactId=jmime -Dversion=3.1.1e -Dpackaging=jar

Maven installé le fichier jar de l'amende juste dans mon dépôt local.

Ensuite, je suis allé dans IntelliJ Paramètres => Maven => Services de Dépôt et de mise à Jour de mon dépôt local (de sorte que l'Ide serait de revisiter le contenu du référentiel).

Enfin, j'ai ajouté la suite de la dépendance à mon pom.xml fichier (juste au-dessus de la log4j de la dépendance).

<dependency>
    <groupId>jmime</groupId>
    <artifactId>jmime</artifactId>
    <version>3.1.1e</version>
</dependency>

Je vais maintenant créer une nouvelle classe comme suit:

package com.stackoverflow.question;

import org.apache.log4j.Logger;
import com.hunnysoft.jmime.ByteString;
import com.hunnysoft.jmime.Field;
import com.hunnysoft.jmime.FieldBody;

public class StackOverflowQuestion {
    public Field create(String name, String text) {
        Logger.getLogger(getClass()).debug("create entered");
        FieldBody body = new FieldBody();
        body.setText(new ByteString(text));
        Field field = new Field();
        field.setFieldName(name);
        field.setFieldBody(body);
        return field;
    }
}

Maintenant pour le "bizarre". IntelliJ intention du mécanisme de ramasse et reconnaît l'Enregistreur de l'importation dans le pom maven fichier de l'amende juste. Toutefois, pour l'ensemble de la hunnysoft les importations, il rapporte: "Impossible de résoudre le symbole " ByteString/Terrain/FieldBody'", MAIS "Build => Compiler 'StackOverflowQuestion.java' compile tout correctement et que l'appareil de test que j'ai créé pour cette classe fonctionne très bien (même si les intentions de la marque de l'appel à create() comme une zone à problème).

Donc quelque part, en quelque sorte, IntelliJ est ignorant la jmime.jar fichier à l'intention du sous-système. Je suis confus parce que la log4j dépendance fonctionne très bien et tout se compile et s'exécute correctement. F12 ("Aller À la Déclaration") travaille sur l'Enregistreur à l'importation, mais se brise sur tous les jmime importations.

Oh, une autre chose, si je vais à la 'Paquets' vue dans les "Projets" de la fenêtre de la "com".hunnysoft.jmime" package s'affiche et je peux voir TOUTES les classes que j'ai importé dans l'extrait de code ci-dessus dans "Bibliothèques". Retrait de la au-dessus de la dépendance de la pom.xml le fichier à l'origine de ce forfait à disparaître, et la compilation des pauses.

Il semble que l'inspection du classpath est cassé, mais il ne semble pas être un paramètre de n'importe où dans les Paramètres => Intentions | Compilateur zones (non pas que je m'attendais à tout ces paramètres, je crois que l'IDÉE devrait déjà connaître le bon chemin de classe basée sur la pom fichier et JDK).

Comme une dernière expérience, j'ai créé une nouvelle norme J2SE projet d'application (sans l'aide de maven) et ajout de la jmime.jar fichier directement au projet en tant que l'une de ses bibliothèques. Je rencontre exactement les mêmes problèmes que ceux décrits ci-dessus dans ce nouveau projet.

Voici le MANIFESTE.MF de la jmime fichier jar.

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.5.4
Created-By: 10.0-b23 (Sun Microsystems Inc.)

Name: com/hunnysoft/jmime/
Sealed: true
Specification-Title: Hunny JMIME
Specification-Version: 3.1.1
Specification-Vendor: Hunny Software, Inc.
Implementation-Title: com.hunnysoft.jmime
Implementation-Version: 3.1.1E
Implementation-Vendor: Hunny Software, Inc.

Je ne vois pas quelque chose d'inhabituel dans ce fichier jar.

Ma meilleure supposition est que peut-être le problème, peut-être un manque de problème de dépendance. Mais autant que je sache jmime est censé être autonome (JarAnalyzer ne pas trouver quelque chose, mais je ne suis pas sûr qu'il le ferait si une dépendance pot est manquant).

Donc, tous ceux qui ont des Idées?

1310voto

CrazyCoder Points 103123

D’abord, vous devriez essayer `` et si cela n’aide pas, supprimez le répertoire système idée. Puis ré-importer le projet Maven et voir si ça aide.

Dans certains cas bizarres classes compilées peuvent signaler info erronée et confondre l’idée. Vérifiez que les classes de ce pot signalent les noms exacts à l’aide de `` .

140voto

rshahriar Points 489

L’astuce suivante a résolu ce problème pour moi :

  • Faites un clic droit sur l’éditeur de code
  • Placez le curseur sur Maven et développez
  • Cliquez sur la réimportation

La version de mon idée est 12.0.4

22voto

Matthew Chen Points 331

Une étape supplémentaire, quand j’ai déposer-> Caches invalider et redémarré l’IDE, ouvrez un projet. Elle est apparue une toastbox sur le haut à droite pour me demander s’il faut activer l’importation automatique et qui a résolu le problème.

14voto

landon9720 Points 11241

Une autre chose à vérifier : Veillez à ce que les dépendances ne sont pas dupliqués. Dans mon cas, j’ai trouvé qu’un module présentant ce comportement a été mal configuré comme suit : il a une dépendance sur un autre module, et il avait une dépendance sur un pot produit par cet autre module. Cela signifiait pour chaque symbole référencé en double et était ambiguë.

3voto

mozboz Points 533

J'ai juste eu ce problème et il serait tout simplement pas aller loin. Finalement, j'ai effacé le IntelliJ le répertoire de configuration dans ~ et reconstruit mon Ide de projet à partir de zéro. (Il a seulement pris environ 15 minutes de la fin, comparativement à passer une heure à essayer de travailler sur les problèmes avec les fichiers mis en cache, etc.)

Edit: Notez que ma conjecture est que le problème initial a été causé par quelque chose comme: http://javathings.blogspot.com/2009/11/too-many-open-files-in-intellij-idea.html ou un espace disque/mémoire de problème causant l'java à l'écrasement. IntelliJ semblait juste être corrompu.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X