Tag Archives: Eclipse

Coffee Connection: Netzwerkverbindungen mit Java im Debian Sid

Ein länglicher Titel für ein ärgerliches Problem mit kurzer Lösung:

Seit einigen Tagen mag sich Eclipse unter Debian Sid auf meinem Arbeitsnotebook nicht mehr mit dem Internet verbinden. Die Fehlermeldungen sind, je nach Modul, verschieden, laufen letztendlich aber immer auf etwas in der Form “Network noch reachable” hinaus. Erst dann fällt auch auf, wie oft ich doch bei der Entwicklung auf das Internet zugreife: Subversion und Maven funktionieren nicht mehr, Updates und das Einspielen von Plugins ist unmöglich und irgendwann – ein wichtiger Hinweis auf die Fehlerursache – stellte sich heraus, dass gar keine Java-Anwendung mehr Zugang zum Netzwerk hat.

Nachdem ich zunächst nach Fehlern bei Eclipse gesucht habe, war die Lösung nun recht nahe: Ein Blick in die Fehlerberichte für das Paket sun-java6-jdk zeigt den Bug #560044, der genau mein Problem beschreibt. Offenbar hält SUNs Java sich nicht an die Konventionen für den Umgang mit IPv4- und IPv6-Verbindungen, so dass IPv4 gar nicht mehr funktioniert.

Der Fehlerbericht enthält am Ende auch einen Workaround, der bei mir funktioniert: In der Datei /etc/sysctl.d/bindv6only.conf die Variable net.ipv6.bindv6only von 1 auf 0 setzen, und schon dürfen IPv6-Sockets auch IPv4-Pakete empfangen. [Update: Mit dem Aufruf invoke-rc.d procps restart muss die Konfiguration dann noch neu geladen werden.] Problem solved.

Nun muss dieser Bug nur noch unter dem Google-Query “Debian Eclipse network connection error” erscheinen, dann wäre er auch keinen Blogeintrag mehr wert. 8-)

Hierarchische Package-Darstellung in Eclipse

Nachdem mir heute wieder ein “Wie machst Du das eigentlich?” begegnet ist, bringe ich als Abwechslung zu ewig langen Text-Einträgen mal ein kurzes Bunte-Bildchen-Howto:

Viele Eclipse-Nutzer sehen in der Java-Perspektive ihre Package-Struktur so:

Package-Explorer - flache Darstellung

Der Nachteil dieser Darstellung ist, dass sich die Baumstruktur der Packages nur schwer nachvollziehen lässt. Die Darstellung ist flach und genauso heisst sie auch: Flat Package Presentation.

Viel günstiger ist aber meist die Hierarchical Package Presentation, bei der Packets wieder in einer Baumstruktur dargestellt werden:

Package Explorer - hierarchische Darstellung

Erreicht wird dies, indem man in der rechten oberen Ecke des Package Explorers das Menü öffnet und die Option Package Presentation von Flat auf Hierarchical umstellt:

Package Explorer - Menü

Dort befinden sich auch einige andere nützliche – oder vielleicht auch nervige – Optionen der Package-Darstellung, die sich je nach Belieben aktivieren oder deaktivieren lassen.

Subversion Relocate mit Eclipse und TortoiseSVN

Wir sind vor einigen Tagen mit unserem Projekt IMPULS von Sourceforge auf unseren eigenen, diesen Webserver umgezogen. Das heißt, wir haben nicht nur die Homepage migriert und ein Trac eingerichtet, sondern auch das Subversion-Repo verschoben. Für ausgecheckte Working Copies ist dann ein sogenannte Relocate fällig. In Verbindung mit Eclipse kann man da auf die Nase fallen.

Subversion mit Eclipse ist eigentlich erstmal kein Problem. Es gibt Subclipse und da funktionieren Checkout, Update, Commit usw. wunderbar. Rechtsklick auf auf’s Projekt, »Team« angeklickt und los geht’s – leider ohne Relocate. Wenn ich das jetzt einfach außerhalb von Eclipse machen würde, zerschieße ich mein Projekt, weil in den Projekteinstellungen der Pfad auf’s Repository vermerkt ist. Es gibt aber eine Lösung. Zunächst vergewissern wir uns, welche URL grad für das Projekt angegeben ist:

Subversion Pfad in Projekteinstellungen

Hier ist also noch der alte Pfad des Repos bei Sourceforge eingetragen. Der nächste Schritt in der Punkt »Disconnect« im bereits erwähnten Menü »Team«. Draufklicken und dann kommt folgender Dialog. Dort bestätigt man mit der Option, die Subversion-Dateien zu behalten.

Disconnect im Menü »Team« von Eclipse

Dann kommt das eigentliche Relocate. Das geschieht unter Windows am einfachsten mit TortoiseSVN, wie im folgenden Bild zu sehen ist. Natürlich kann man hier auch die Kommandozeilenversion von Subversion benutzen, wenn man grad kein TortoiseSVN zur Hand hat. Wie das geht, steht im Subversion-Buch.

Relocate mit TortoiseSVN

Der letzte Schritt besteht darin, dem Projekt in Eclipse wieder beizubringen, dass es eigentlich ein mit Subversion verwaltetes ist. Dazu wieder ein Rechtsklick auf das Projekt und im Menü »Team« den Punkt »Share« und dann natürlich »SVN«. Subclipse erkennt, dass es sich bereits um eine korrekte Working Copy handelt und übernimmt den richtigen Pfad aus Schritt drei. Nur noch einmal den folgenden Dialog abnicken und fertig ist die Laube.

Subversion Working Copy Eclipse wieder bekannt machen