Hi,
der Thread scheint zwar schon lang tot, aber vielleicht stoßen andere ja wie ich auf ihn in ihrer verzweifelten Suche nach Hilfe, und deshalb hinterlass ich mal, was meine Probleme waren und was ich rausgefunden hab. Vieles ist zwar vielleicht eine Wiederholung, aber dann hat man's immerhin am Stück
. Außerdem versuch ich, auch für die nicht-so-ganz-Auskenner narrensicher zu sein (die anderen mögen großzügig darüber hinweglesen ...).
Meine Ausgangslage:
- Windows 7 SR1 64 Bit deutsch, darauf verschiedene JREs und JDKs, und Eclipse Helios (Eclipse 3.6) 32 Bit for Java Developers, keine wissentlich zusätzlich installierten Plugins.
- Lief ohne feststellbare Probleme (allerdings - wie ich im Zuge der jetzigen Forschung gesehen hab, gab's jede Menge Exceptions in der .metadata/.log ...).
- Wollte endlich updaten auf Eclipse Indigo (Eclipse 3.7.2), und in dem Zuge mal gleich auf 64 Bit (wenn schon).
- Ich arbeite als Benutzer mit Admin-Rechten (nicht Administrator) und mit eingeschalteter UAC (User Account Control - auf deutsch glaube ich "Benutzerkontensteuerung", die Windows-Nachfragerei, ob es etwas Problematisches tun darf oder nicht).
Meine Probleme:
(Blöderweise schreib ich alles nachträglich zusammen und hab deshalb die einschlägigen Fehlermeldungen nicht mehr parat
; hilft hoffentlich trotzdem.)
1.) Eclipse findet beim Start das zu startende Produkt nicht; den Fehler-Dialog hab ich leider nicht mal mehr ansatzweise parat, zu lang her :/
2.) Eclipse findet beim Start seine "companion shared lib" nicht; Fehler-Dialog: "the eclipse executable launcher was unable to locate its companion shared library"
3.) Eclipse findet beim Start keine JVM; Fehler-Dialog vermutlich: "a java runtime environment jre or java development kit jdk must be available in order to run eclipse..."
4.) Eclipse findet keine Update-Sites; Fehlermeldung im .metadata/.log z.B.: "Connection to
http://download.eclipse.org/eclipse/updates/3.7/p2.index failed on Connection reset. Retry attempt 0 started" mit einer java.net.SocketException ("Connection reset")
(meine) Erklärungen:
1.) lag daran, dass ich a) (unabsichtlich) nicht das Paket "Eclipse for Java Developer", sondern "Eclipse Classic" (oder so ähnlich) runtergeladen und installiert und b) (absichtlich) die eclipse.ini (siehe unten) mit der aus einer Sicherung (zuvor umbenanntes eclipse-Verzeichnis ...) abgeglichen hab, um meine früheren Einträge zu behalten. Dabei hab ich dann (aus Unkenntnis) das Argument von "-startup" oder "--launcher.library" verhunzt
. Das hat den Launcher (der offenbar verschiedenste Eclipse's oder Eclipse-Konfigurationen oder eclipse-basierte Anwendungen oder was auch immer starten kann) beim Start dann angewiesen, ein Produkt zu starten, das gar nicht (mehr) installiert war. Sollte also bei sorgfältiger Installation nicht vorkommen (schäm).
2.) Dafür hab ich keine echte Lösung, nur eine Vermutung und Quasi-Lösung: Auf jeden Fall scheint das ein Windows 7- (wahrscheinlich auch Vista-) spezifisches Berechtigungsthema zu sein. Bei mir trat der Fehler dann nicht auf, wenn ich Eclipse mit Administrator-Rechten gestartet hab (Rechtsklick auf eclipse.exe oder einen Eclipse-ShortCut - auf deutsch "Verknüpfung" - beispielsweise auf dem Desktop > "Als Administrator ausführen"). Ich hatte das Problem aber eh nur bei einer 32 Bit-Eclipse (die ansonsten natürlich - bis auf Nicht-Wissen - exakt analog zur 64 Bit-Eclipse installiert war). Falls das bei euch auch der Grund ist, kann eine dauerhafte, aber natürlich völlig unbefriedigende Abhilfe sein, Eclipse grundsätzlich Administrator-Rechte zu erteilen (geht über die Eigenschaften der eclipse.exe oder des ShortCut: Rechtsklick z.B. auf eclipse.exe > Eigenschaften > Kompatibilität > "Programm als Admin ausführen"). Andere Lösungen, die man im Netz findet (siehe z.B.
Vernon's blog: The Eclipse executable launcher was unable to locate its companion shared library) haben bei mir nicht funktioniert - die Cygwin-Lösung nicht, weil Cygwin (auf meinem PC) selbst zu wenig Rechte hat, die Änderung der Berechtigungsstruktur der DLL nicht, weil "weiß nicht", hat einfach nichts offensichtliches geändert.
Zusätzlicher Hinweis: Im Netz findet man ebenfalls Hinweise, dass man dieses Problem dadurch umgehen kann, dass man das ZIP-File mit Zippern wie 7zip oder ähnlichen statt mit Windows-Bordmitteln entpackt. Das kann ich nicht bestätigen - entweder ging's bei mir sowieso, oder auch andere Zipper konnten nicht helfen. Es mag aber durchaus sein, dass manche Zipper oder - bei entsprechenden Benutzer-Rechten - Windows selbst beim Entpacken direkt in den Programme-Baum zicken. Kann man ihnen eigentlich auch nicht verdenken (Stichwort "VirtualStore" - siehe unten), sowas macht man schließlich heutzutage auch nicht mehr! (Die Linux-Leute mögen fein stillschweigen: Auch wir kennen inzwischen Mechanismen wie rpm und installieren schon lang nicht mehr, indem wir ein tar-File auspacken!) Das ist meiner Meinung nach einer der ganz großen Kritikpunkte an Eclipse: Plattformunabhängig sein wollen (was ja wg. SWT eh nicht wirklich geht), aber DLLs verwenden, und dann aber wieder kneifen, wenn es um saubere Installation derselben geht! Ist es wirklich zu viel verlangt, nach Jahren mal endlich einen Installer zu basteln, der 1. sauber installiert und 2. korrekt UPDATED und Benutzer nicht im Regen stehen lässt, wie man das denn am besten bewerkstelligt?! Sogar NetBeans wird per Installer installiert, und die sind "purer" Java als Eclipse. (Sorry, musste ich jetzt mal loswerden - obwohl ich Eclipse an sich ja gegen z.B. NetBeans verteidige.)
3.) Liegt daran, dass Eclipse 1. überhaupt eine und 2. eine passende JVM finden muss. Passend heißt: Ein 32 Bit-Eclipse braucht eine 32 Bit-JVM, ein 64 Bit-Eclipse entspr. eine 64 Bit-JVM. Das ist Voraussetzung, ohne das geht sowieso nichts! Also ggf. eine passende JVM (JDK oder JRE - JDK ist besser, wenn man eh Java entwickeln will, weil dann z.B. die Quelldateien der VM-Klassen mitkommen, in die man doch gerne mal reinschaut) downloaden und installieren. Finden: Geht über verschiedene Mechanismen: a) PATH-Environment-Variable, übersteuert (vermutlich!) von b) JAVA_HOME-Environment-Variable, übersteuert (vermutlich!) von c) Eintrag in der eclipse.ini (steht im eclipse-Verzeichnis im Programme-Baum), übersteuert (vermutlich!) von d) Aufrufparameter (die Prioritäten könnten andere sein, aber so scheint's mir am logischsten); a) und b) übergeh ich mal, weil c) / d) in meinen Augen passender sind.
Für c) muss man zwei (in Worten: ZWEI!!) Zeilen in die eclipse.ini eintragen:
-vm
C:\Program Files......\<JDKoderJRE>\bin
Die zweite Zeile ist natürlich abhängig davon, wohin man Java installiert hat. Eine 32 Bit-JRE Version 6 könnte hier liegen:
C:\Program Files (x86)\jre1.6.0_23
Ein 64 Bit-JDK Version 7 z.B. hier:
C:\Program Files\jdk1.7.0_04
Ich hatte Erfolg mit dem JDK 1.7.0_04 (32 Bit / 64 Bit). Bestimmt geht aber auch ein Jxx 1.6.0_nn oder gar Jxx 1.5.0_nn, in der Beziehung ist Eclipse ja doch robust.
Wichtig:
- keine Anführungszeichen um den Verzeichnisnamen (trotz enthaltener Leerzeichen!)
- muss (anders als JAVA_HOME) mit "bin" enden - genau in diesem Verzeichnis muss ein java.exe oder javaw.exe stehen
- die beiden Zeilen müssen (mindestens)
vor der Zeile "-vmargs" stehen, falls es die gibt, und sie dürfen natürlich nicht andere "Zweizeiler" trennen! (Ob's weitere Einschränkungen gibt, weiß ich jetzt nicht, kenn die eclipse.ini auch nicht per du.)
Und
ACHTUNG: Wenn man die eclipse.ini mit einem "zu dummen" Editor - z.B. Notepad! - ändert und speichert, steht das Ergebnis anschließend mitnichten im eclipse-Verzeichnis im Programme-Baum, sondern im VirtualStore (Windows 7 lenkt alle nicht autorisierten Schreibversuche im Programme- und Windows-Baum unter der Decke in den "VirtualStore" um; der steht - benutzerabhängig - in C:\Users\<eigenerBenutzername>\AppData\Local\VirtualStore - einfach mal schauen, versteht man glaube ich sofort!).
Und
nochmal ACHTUNG: Windows lenkt
Lesezugriffe eines Programms auf solche "selbst und nicht autorisiert geschriebenen" Dateien ebenfalls unter der Decke in den VirtualStore um -
aber nur, wenn diese Dateien im Programme-Verzeichnis nicht schon existieren! Und das tut die eclipse.ini natürlich, stammt ja schließlich aus dem ZIP-File. Mit anderen Worten: eclipse.ini editieren, speichern
und dann aus dem VirtualStore in das eclipse-Verzeichnis zurückkopieren! Sonst ist das Verzweiflungsrisiko hoch ...
d) Wirkt dadurch, dass man Eclipse beim Start Argumente übergibt. Das geht am einfachsten, indem man die in einen Shortcut für Eclipse einträgt - und da liegt auch der Nachteil dieser Methode gegenüber c): Wirkt natürlich nur, wenn man zum Start
genau diesen Shortcut verwendet (ich hab gern drei ...). Ist dafür aber im Prinzip wesentlich einfacher als c). Theoretisch (ich hab die Methode nicht ausprobiert und kann sie leider auch nicht leicht ausprobieren, weil ich c schon hinter mir hab und nicht die ganze Prozedur wieder rückwärts machen will :/) ergänzt man das "Ziel" eines Shortcuts um das VM-Argument. Wenn Eclipse beispielsweise in C:\Program Files\eclipse und Java in C:\Program Files\Java\jre1.7.0_04 installiert ist, sollte dieses "Ziel" lauten:
"C:\Program Files\eclipse\eclipse.exe" -vm "C:\Program Files\Java\jre1.7.0_04\bin"
Man beachte, dass jetzt die Anführungszeichen nötig sein sollten (weil das zunächst noch durch die Hände von Windows geht und die Leerzeichen zerhacken, was zusammenbleiben sollte - Programmierer sollten damit vertraut sein, andere sollten es einfach so schlucken
).
4.) Dafür hab ich leider
immer noch keine Lösung - lässt mich bald verzweifeln!! Falls mir da jemand einen oder auch zwei passende Tipps hat: SEEEEHR GERNE. Ich denke aber, dass das nichts mit Eclipse zu tun hat, sondern ein lokales Netzwerk-Problem ist. Allerdings wüsste ich nicht, was ich noch tun kann - DNS, Firewall etc. hab ich so weit ich mich auskenne abgeklappert. Natürlich kann ich (z.B.) download.eclipse.org pingen oder im Browser öffnen, natürlich hab ich Eclipse schon alle Rechte in der Firewall (Avira Professional Security 2012, nebenbei) gegeben. Natürlich gehen auch andere Download-Sites nicht (Log4E, Mylyn, Oxygen, Eclipse Java Source Helper, HgEclipse). Temporäres Deaktivieren der Firewall bringt ebenfalls nichts, ebenso wenig das dauerhafte Ausschalten (die scheint allerdings im Untergrund trotzdem noch irgendwie aktiv zu bleiben, sicher nur zu meiner Sicherheit ...). Was sich nur ändert: Statt "Connection failed" kommt (manchmal - vielleicht sogar eh viel häufiger) "Unable to read repository at http://download.eclipse.org/eclipse/updates/3.7/content.xml." mit der SocketException-Meldung "Socket operation on nonsocket: recv failed".
Ach so: Ich weiß, dass ich Plugins auch manuell installieren kann (naheliegenderweise wieder durch Entpacken eines ZIP-Files ... funktioniert ja gut!). Ich mag es aber gerne lau (wenn ich das mal klauen darf), ehrlich gesagt, und finde es durchaus angenehm, wenn Eclipse sich um die Updaterei selbst kümmert. Und wenn ich das nicht falsch verstanden hab, tut es das
nicht, wenn man schon selbst installiert hat. Immerhin konsequent - aber ebenfalls fragwürdig.
Herzliche Grüße und euch hoffentlich mehr Erfolg!
Harald
