Mon Eclipse arrête de charger le workbench. J'ai déjà essayé de commencer avec ./Eclipse --clean
En démarrant depuis la console, il lève l'exception suivante:
Java.lang.NullPointerException
at org.Eclipse.core.internal.runtime.Log.isLoggable(Log.Java:101)
at org.Eclipse.equinox.log.internal.ExtendedLogReaderServiceFactory.safeIsLoggable(ExtendedLogReaderServiceFactory.Java:57)
at org.Eclipse.equinox.log.internal.ExtendedLogReaderServiceFactory.logPrivileged(ExtendedLogReaderServiceFactory.Java:158)
at org.Eclipse.equinox.log.internal.ExtendedLogReaderServiceFactory.log(ExtendedLogReaderServiceFactory.Java:146)
at org.Eclipse.equinox.log.internal.ExtendedLogServiceFactory.log(ExtendedLogServiceFactory.Java:65)
at org.Eclipse.equinox.log.internal.ExtendedLogServiceImpl.log(ExtendedLogServiceImpl.Java:87)
at org.Eclipse.equinox.log.internal.LoggerImpl.log(LoggerImpl.Java:54)
at org.Eclipse.core.internal.runtime.Log.log(Log.Java:60)
at org.tigris.Subversion.clientadapter.javahl.Activator.isAvailable(Activator.Java:92)
at org.tigris.Subversion.clientadapter.Activator.getAnyClientAdapter(Activator.Java:81)
at org.tigris.Subversion.subclipse.core.SVNClientManager.getAdapter(SVNClientManager.Java:145)
at org.tigris.Subversion.subclipse.core.SVNClientManager.getSVNClient(SVNClientManager.Java:92)
at org.tigris.Subversion.subclipse.core.SVNProviderPlugin.getSVNClient(SVNProviderPlugin.Java:425)
at org.tigris.Subversion.subclipse.core.status.NonRecursiveStatusUpdateStrategy.statusesToUpdate(NonRecursiveStatusUpdateStrategy.Java:53)
at org.tigris.Subversion.subclipse.core.status.StatusCacheManager.refreshStatus(StatusCacheManager.Java:273)
at org.tigris.Subversion.subclipse.core.resourcesListeners.FileModificationManager.refreshStatus(FileModificationManager.Java:179)
at org.tigris.Subversion.subclipse.core.resourcesListeners.FileModificationManager.resourceChanged(FileModificationManager.Java:128)
at org.Eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.Java:291)
at org.Eclipse.core.runtime.SafeRunner.run(SafeRunner.Java:42)
at org.Eclipse.core.internal.events.NotificationManager.notify(NotificationManager.Java:285)
at org.Eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.Java:149)
at org.Eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.Java:395)
at org.Eclipse.core.internal.resources.Workspace.endOperation(Workspace.Java:1530)
at org.Eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.Java:45)
at org.Eclipse.core.internal.jobs.Worker.run(Worker.Java:54)
Il s’arrête lors du chargement de com.Android.ide.Eclipse.adt
Quel est le problème avec mon établi?
DISCLAIMER: THIS WILL DELETE ALL OF YOUR Eclipse WORKSPACE SETTINGS AND YOU WILL HAVE TO RE-IMPORT ALL YOUR PROJECTS, THERE ARE LESS DESTRUCTIVE ANSWERS HERE
Essayez ce qui suit:
Supprimez le dossier .metadata de votre espace de travail local(c’est ce qui a fonctionné pour moi). Il semble qu'il contient un fichier .LOCK qui, s'il n'est pas correctement fermé, empêche Eclipse de démarrer correctement. Sur les systèmes Unix, vous pouvez taper suivant en ligne de commande;
rm -r workspace/.metadata
Supprimez votre répertoire .Eclipse dans votre répertoire personnel. Lancez Eclipse. Si ça ne marche pas,
Ouvrez Eclipse sous un autre compte utilisateur. S'il se charge, vous savez que le problème vient de votre compte, pas de votre installation Eclipse.
La procédure indiquée à http://off-topic.biz/en/Eclipse-hangs-at-startup-showing-only-the-splash-screen/ A fonctionné pour moi:
Dans d'autres réponses:
Eclipse -clean -clearPersistedState
est mentionné - qui semble avoir le même ou même meilleur effet.
Voici un script pour MacOS (utilisant Macports) et Linux (testé sur Ubuntu avec Eclipse Equinox) pour faire le début avec une suppression facultative de Eclipse en cours d’exécution. Vous voudrez peut-être adapter le script à vos besoins. Si vous ajoutez de nouvelles plateformes, éditez le script directement dans cette réponse.
#!/bin/bash
# WF 2014-03-14
#
# ceclipse:
# start Eclipse cleanly
#
# this script calls Eclipse with -clean and -clearPersistedState
# if an instance of Eclipse is already running the user is asked
# if it should be killed first and if answered yes the process will be killed
#
# usage: ceclipse
#
#
# error
#
# show an error message and exit
#
# params:
# 1: l_msg - the message to display
error() {
local l_msg="$1"
echo "error: $l_msg" 1>&2
exit 1
}
#
# autoinstall
#
# check that l_prog is available by calling which
# if not available install from given package depending on Operating system
#
# params:
# 1: l_prog: The program that shall be checked
# 2: l_linuxpackage: The apt-package to install from
# 3: l_macospackage: The MacPorts package to install from
#
autoinstall() {
local l_prog=$1
local l_linuxpackage=$2
local l_macospackage=$3
echo "checking that $l_prog is installed on os $os ..."
which $l_prog
if [ $? -eq 1 ]
then
case $os in
# Mac OS
Darwin)
echo "installing $l_prog from MacPorts package $l_macospackage"
Sudo port install $l_macospackage
;;
# e.g. Ubuntu/Fedora/Debian/Suse
Linux)
echo "installing $l_prog from apt-package $l_linuxpackage"
Sudo apt-get install $l_linuxpackage
;;
# git bash (Windows)
MINGW32_NT-6.1)
error "$l_prog ist not installed"
;;
*)
error "unknown operating system $os"
esac
fi
}
# global operating system variable
os=`uname`
# first set
# Eclipse_proc - the name of the Eclipse process to look for
# Eclipse_app - the name of the Eclipse application to start
case $os in
# Mac OS
Darwin)
Eclipse_proc="Eclipse.app"
Eclipse_app="/Applications/Eclipse/Eclipse.app/Contents/MacOS/Eclipse"
;;
# e.g. Ubuntu/Fedora/Debian/Suse
Linux)
Eclipse_proc="/usr/lib/Eclipse//plugins/org.Eclipse.equinox.launcher_1.2.0.dist.jar"
Eclipse_app=`which Eclipse`
;;
# git bash (Windows)
MINGW32_NT-6.1)
Eclipse_app=`which Eclipse`
error "$os not implemented yet"
;;
*)
error "unknown operating system $os"
esac
# check that pgrep is installed or install it
autoinstall pgrep procps
# check whether Eclipse process is running
# first check that we only find one process
echo "looking for $Eclipse_proc process"
pgrep -fl "$Eclipse_proc"
# can't use -c option on MacOS - use platform independent approach
#Eclipse_count=`pgrep -cfl "$Eclipse_proc"`
Eclipse_count=`pgrep -fl "$Eclipse_proc" | wc -l | tr -d ' '`
# check how many processes matched
case $Eclipse_count in
# no Eclipse - do nothing
0) ;;
# exactly one - offer to kill it
1)
echo "Eclipse is running - shall i kill and restart it with -clean? y/n?"
read answer
case $answer in
y|Y) ;;
*) error "aborted ..." ;;
esac
echo "killing current $Eclipse_proc"
pkill -f "$Eclipse_proc"
;;
# multiple - this is bogus
*) error "$Eclipse_count processes matching $Eclipse_proc found - please adapt $0";;
esac
tmp=/tmp/Eclipse$$
echo "starting Eclipse cleanly ... using $tmp for Nohup.out"
mkdir -p $tmp
cd $tmp
# start Eclipse with clean options
Nohup $Eclipse_app -clean -clearPersistedState&
./Eclipse -clean -refresh
comme mentionné dans le commentaire par sulai 20 décembre 12 à 12:46, cela a fonctionné pour moi.
Cependant, sur Mac OS X, je devais trouver comment accéder à ./Eclipse
Voici la solution:
cd Eclipse.app/Contents/MacOS/
Merci Andrew pour le commentaire de cet article: https://stackoverflow.com/a/1783448/2162226
La meilleure solution que j'ai trouvée consiste à supprimer ce fichier: workspace/.metadata/.plugins/org.Eclipse.e4.workbench/workbench
pas besoin de supprimer les métadonnées entières. essayez simplement de supprimer le fichier .snap sous org.Eclipse.core.resources dans votre dossier d’espace de travail ex.
workspaceFolder.metadata.plugins\org.Eclipse.core.resources
J'ai résolu en supprimant * .snap du répertoire de l'espace de travail (et de tous les sous-répertoires):
métadonnées\.plugins\*. snap
Assez vieille question, mais la réponse de la {la plus simple} _ n'est pas encore postée.
C'est ici :
1) Dans [workspace]\.metadata\.plugins\org.Eclipse.e4.workbench
supprimerworkbench.xmi
fichier.
Dans la plupart des cas c'est assez - essayez de charger Eclipse.
Vous devez toujours reconfigurer vos paramètres de perspective spécifiques (le cas échéant).
2) Vous avez maintenant des problèmes pour construire des projets qui fonctionnent parfaitement? De par mon expérience, suivre les étapes suivantes aide:
- décochez Projets-> Construire automatiquement
- passer en perspective Java (si pas encore): Fenêtre -> Perspective ouverte -> Java
- localisez Problems ou ouvrez-le: Fenêtre -> Afficher la vue -> Problèmes
- faites un clic droit sur les groupes de problèmes et sélectionnez Supprimer. Assurez-vous de supprimer les erreurs Lint
- nettoie l'espace de travail: Projet -> Nettoyer ... avec l'option Nettoyer tous les projets
- vérifier Projets-> Construire automatiquement
- si le problème persiste pour certains projets: cliquez avec le bouton droit de la souris sur le projet, sélectionnez Propriétés -> Android et assurez-vous que Project Build Target est bien choisi.
3) C'était toujours suffisant pour moi. Mais si vous rencontrez toujours des problèmes, essayez les recommandations de @george post
La procédure suivante a fonctionné sur mon MacOS (Mavericks) et Eclipse Luna 4.4.1:
Supprimez le fichier .snap sous le chemin "workspaceFolder" .metadata.plugins\org.Eclipse.core.resources \
Si vous ne savez pas comment accéder à ce dossier sur Mac, appuyez sur Cmd + Maj + G (Aller au dossier) et tapez l'adresse complète à laquelle vous souhaitez accéder.
la suppression de l'espace de travail/.metadata/.lock et le démarrage d'Eclipse avec -clean -refresh ont fonctionné pour moi.
On dirait que vous avez probablement ce problème:
Vous devez supprimer le dossier org.Eclipse.e4.workbench dans metadata.plugins\que vous trouverez dans votre dossier d’espace de travail. La suppression de ce dossier a résolu le problème pour moi, j'espère que cela aidera quelqu'un d'autre!
J'ai eu ce problème dans Windows 7, c'est ce qui l'a résolu pour moi.
http://letsgetdugg.com/2009/04/19/recovering-a-corrupt-Eclipse-workspace/
cd ~/Documents/workspace/.metalog/.plugins
rm -rf org.Eclipse.core.resources
Le problème avec la suppression de fichiers dans le répertoire .metadata est que vous devez démarrer votre plan de travail à partir de zéro. Ainsi, il vous faudra peut-être un certain temps pour restaurer tous vos projets, surtout si vous en avez plusieurs. La restauration de .metadata à partir d’une sauvegarde en remplaçant simplement les fichiers existants par les anciens sauvegardés a fonctionné pour moi.
Il y a plusieurs raisons possibles à ce type de comportement. En plus d’exécuter à partir d’une invite Shell, il est utile de rechercher des indices dans le fichier journal de votre espace de travail, qui est le fichier .metadata/.log situé dans le répertoire de votre espace de travail. faire avec le code de journalisation lui-même, mais le journal peut toujours aider à déterminer ce qui se passait avant l'erreur.
Les recherches Web de messages trouvés donnent souvent lieu à des suggestions pour la suppression et la reprise de divers répertoires ou fichiers. J'ai parfois pu simplement supprimer des parties de .metadata/.plugins/org.Eclipse.ui.workbench/workbench.xml, pour des solutions moins destructives.
Obtenez une copie de sauvegarde du dossier .metadata/.plugin/org.Eclipse.core.resources, supprimez-le et lancez Eclipse. Cela devrait lancer l'espace de travail, mais tous les projets disparaîtront, car org.Eclipse.core.resources conserve la liste de tous les projets.
Ensuite, fermez correctement Eclipse et recopiez le fichier org.Eclipse.core.resources du dossier de sauvegarde dans le dossier .metadata/.plugins/en remplaçant le dossier existant.
Ouvrez Eclipse et tout devrait fonctionner normalement avec tous vos projets.
Après quelques recherches sur les dates des fichiers, j'ai résolu le même problème (problème récurrent sur mon Kepler) en supprimant simplement le fichier suivant dans mon espace de travail local: .dat
avec un impact négligeable sur la restauration de l'espace de travail.
J'espère que cela pourra aider quelqu'un d'autre ...
Voici une méthode moins destructive qui a fonctionné pour moi:
Je suis sur une machine Windows avec une copie de Spring Tool Suite (une extension d'Eclipse) que je lance à partir d'un répertoire aléatoire. Dans l'invite de ma ligne de commande, je devais accéder au répertoire contenant mon STS.exe
et exécuter: STS.exe -refresh
.
Après cela, je pouvais ouvrir mon Eclipse de manière normale (via une icône de barre des tâches épinglée).
gel d'Eclipse au démarrage - avant de charger l'espace de travail très bonne réponse à ce message. répéter la réponse qui a fonctionné pour moi
Dans votre répertoire d’espace de travail, procédez comme suit:
cd .metadata/.plugins
mv org.Eclipse.core.resources org.Eclipse.core.resources.bak
Lancez Eclipse. (Il devrait afficher un message d'erreur ou un espace de travail vide car aucun projet n'a été trouvé.)
Fermez tous les onglets d'éditeurs ouverts.
Quittez Eclipse.
rm -rf org.Eclipse.core.resources (Supprime le répertoire nouvellement créé.)
mv org.Eclipse.core.resources.bak/org.Eclipse.core.resources (restaure le répertoire d'origine.)
Lancez Eclipse et commencez à travailler. :-)
Répondre par CharlesB
Essayez également de charger et d’enregistrer l’espace de travail avec une version plus récente d’Eclipse:
J'utilise Eclipse 3.8. Lors du démarrage, l'écran de démarrage se bloquait. Il n'y avait aucun message d'erreur dans le journal. Ce qui a aidé a été d'ouvrir l'espace de travail avec Eclipse 4.2.2. Après avoir ouvert et fermé l’espace de travail, j’ai pu le charger à nouveau avec 3.8.
Dans votre espace de travail, vous trouverez le nom de dossier caché .metadata dans lequel vous trouverez un autre dossier caché ".mylyn", supprimez-le et videz votre corbeille Dans le gestionnaire de tâches, arrêtez le processus d'Eclipse et redémarrez Eclipse cette fois, cela fonctionnera .
Prendre plaisir!