Eclipse für PHP unter Opensuse – II

In diesem 2-ten Teil der Beiträge zum Einsatz von Eclipse unter Opensuse 11.3/11.4 wollen wir Eclipse selbst auf unserem lokalen Entwicklungssystem installieren.

Wir beschreiben nachfolgend nur eine sehr individuelle Installation in einem persönlichen Verzeichnis mit Hilfe von Dateien, die wir aus dem Netz herunterladen. [Für eine systemweite Installation für mehrere User unter Opensuse und anderen Systemen sehen Sie bitte entsprechende Hinweise in einigen der Links am Ende dieses Beitrags.]

Angemerkt sei auch, dass einige Anwender Schwierigkeiten mit der Installation von Eclipse unter Opensuse 11.3 hatten – und zwar immer dann, wenn sie RPM-Pakete verwendeten. Wir werden nachfolgend dagegen die aktuellen Helios-Archive von den www.eclipse.org Websites und keine RPMs benutzen. Opensuse 11.4 beinhaltet übrigens auch kein Eclipse-RPMs mehr – zumindest nicht in den Standardrepositories von Opensuse.

Das Schöne an einer persönlichen Eclipse-Installation ist nun, dass sie im wesentlichen im Bereitstellen von Dateien eines Archivs in einem Verzeichnis im eigenen Verzeichnisbaum besteht. Das erleichtert die individuelle Kontrolle sowie Backups und Transfers auf andere Systeme enorm.

Voraussetzungen der Installation

Als Voraussetzungen nehmen wir zwar grundsätzlich an:

Das System ist gem. der Angaben des 1-ten Teils der Eclipse-Beiträge aufgesetzt.
https://linux-blog.anracom.com/2011/02/27/php-entwicklungssystem-mit-eclipse-i/

Tatsächlich benötigen wir für eine reine Eclipse-Installation ohne Anbindung an eine Testumgebung aber weder den Apache-Server, noch MySQL, noch SVN etc.. Diese kommen erst später – also in nachfolgenden Artikeln – ins Spiel.

Eclipse ist allerdings ein java-basiertes System. Um Eclipse in elementarer Form zum Laufen zu bringen, ist deshalb eine “Java Runtime”-Umgebung (JRE) erforderlich. Ich selbst habe auf meinem Opensuse 11.4 – System zwei JREs installiert:

java-1_6_0-openjdk – Java runtime environment based on OpenJDK 6 and IcedTea 6
und
java-1_6_0-sun – Java(TM) 6 Runtime Environment.

Ecdlipse arbeitet mit beiden Umgebungen gut zusammen. Natürlich ist unter Opensuse nur immer eine Umgebung wirksam – bei mir aktuell die OpenJdk-Umgebung. Wie man die Umgebung mit Hilfe des Kommandos

update-alternatives –config java

einstellt und wie man zwischen den Umgebungen wechselt, verrät folgender Artikel:

http://de.opensuse.org/Java#Zwischen_verschiedenen_Java_JREs_oder_SDKs_wechseln

Verwendete Abkürzungen: Nachfolgend verstehen wir unter “RMT” im übrigen die Anwendung der rechten Maustaste.

Schritt 1: Herunterladen und Entpacken von Eclipse

Wer sich über aktuelle und kommende Releases von Eclipse informieren will, findet erste Informationen hier:

http://en.wikipedia.org/wiki/Eclipse_%28software%29

Um Eclipse Helios für PHP in einer aktuellen Version zu installieren, kann man sich die notwendigen Pakte von folgender Adresse herunterladen:

http://www.eclipse.org/downloads/packages/release/helios/sr2

Dort wählt man das Paket “Eclipse for PHP Developers” und lädt es sich in ein Verzeichnis seiner Wahl herunter.
Anschließend expandiert man das tar.gz-Archiv (z.B. mit dem Tool “ark”) an einen Platz seiner Wahl im Verzeichnisbaum. Z.B. nach:

/MY_PFAD/eclipse

MY_PFAD steht hier für einen Pfad zu einem Verzeichnis, das mir zugänglich ist. Zur Not eben das HOME-Verzeichnis. In der Praxis halte ich aber meine Entwicklungstools und -Daten auf einer separaten Partition, für die ich besondere Backup-Regeln anwende, da ein Teil meines Geschäfts von den Ergebnissen der Entwicklungsarbeit abhängt.

Danach legen wir uns in Form eines weiteren Verzeichnisses unserer Wahl einen sog. “Eclipse Workspace” an, in dem wir PHP-Projekte unterbringen können. Solche Workspaces kann es mehrere geben. Mit Workspaces sind auch individuell, spezifische Konfigurationseinstellungen (u.a. der Benutzeroberfläche) von Eclipse verbunden. Eclipse fragt beim Öffnen normalerweise nach, welchen Workspace wir für die aktuelle Sitzung benutzen wollen. (Falls wir diese Nachfrage nicht explizit abschalten).

Ich lege für meinen ersten Workspace ein Verzeichnis

/MY_PFAD/ecl_wsp

an.

In dieses Verzeichnis hinein kopiere ich anschließend ein umfassendes Unter-Verzeichnis “myproject” mit diversen HTML-, DWT- und PHP5-Dateien, die ich in einem aktuellen Projekt verwenden will.

/MY_PFAD/ecl_wsp/myproject

Auf diesem Verzeichnis muss ich volle Schreibrechte besitzen. An dieser Stelle ist jeder natürlich selbst gefordert, eigene PHP-Projektdateien unterzubringen. Man kann das Verzeichnis “myproject” anfangs auch leer lassen und seine Dateien erst später in das Verzeichnis kopieren oder eben mit Hilfe von Eclipse selbst anlegen.

Schritt 2: Öffnen von Eclipse

Wir öffnen nun Eclipse, indem wir das Programm

/PFAD/eclipse/eclipse

starten. Z.B. über ein Terminal-Fenster und die Kommandofolge :

cd /PFAD/eclipse/
./eclipse

Man sollte vorab prüfen, dass die genannte Datei auch ausführbar ist und das ggf. ändern.

Bzgl. der Aufnahme des Eclipse Executables in den eigenen Pfad hilft folgendes (s. auch http://www.fedoranews.org/contributors/yves_janse/eclipse/06.shtml):

Anlegen eines Files ” /etc/profile.d/eclipse.sh” mit dem Inhalt:

export ECLIPSE_HOME=/usr/local/eclipse
export PATH=$PATH:$ECLIPSE_HOME

Ausführbar machen und in der aktuellen Shell ausführen:

sudo chmod +x /etc/profile.d/eclipse.sh
source /etc/profile.d/eclipse.sh

Danach kann man Eclipse auf der Kommandozeile einfach mittels des Kommandos “eclipse” starten. Auf meinem KDE-Desktop – genauer im “KDE-Arbeitsordner”- lege ich mir aber zusätzlich ein Icon zum schnellen Starten von Eclipse mittels der Maus an.

Auf die Rückfrage von Eclipse beim Starten, welchen Workspace wir öffnen wollen, geben wir das gerade angelegte Verzeichnis an. Dort liegen zwar Dateien; diese sind aber von Eclipse noch keinem Projekt zugeordnet, und es wurden daher auch keine entsprechenden “Metadaten” im Projektverzeichnis angelegt. Deshalb erscheint zunächst eine relativ einfache Eclipse-Oberfläche, die u.a. Links zu Informationen und Tutorials bietet. (Zu dieser Eröffnungsseite gelangt man später in Eclipse übrigens durch den Menüpunkt “HELP” >> “Welcome”).

eclipse_start

Schritt 3: Wechsel zur Workbench

Ganz rechts auf dem Begrüßungsschirm finden wir einen Link zur sog. Workbench, den wir benutzen.
Bei der sich nun öffnenden “Workbench” handelt es sich um ein mehrfach unterteiltes Fenster, das wir uns später per Maus sehr flexibel und persönlich einrichten können. Ganz links erkennen wir den sog. “PHP-Explorer”, in dem wir später unsere Projekte und entspr. Verzeichnisstrukturen in einer hierarchischen Gliederung sehen werden. Die nachfolgende Abbildung gibt darauf einen Vorgeschmack.

eclipse_workbench

Das Eclipse-Fenster stellt in der Regel sogenannte “Perspectives” dar. Davon gibt es – je nach Entwicklungsarbeit und Projekttyp – eine Vielzahl. Bei der oben dargestellten Perspektive handelt es sich um die sog.

PHP Perspective.

Andere Perspektiven öffnet man in Eclipse über den Menüpunkt

Window >> Open Perspective >> Other.

Innerhalb einer Perspektive kann man zusätzlich diverse sog. “Views” auf bestimmte Projektdaten oder Projektaspekte öffnen. Dies geschieht über den Menüpunkt

Window >> Show View

So werden wir unsere “PHP Perspective” später noch um einen “SVN Repository View”, einen “Task View” und einen “Remote System View” ergänzen.

Schritt 4: Anlegen eines ersten PHP-Projekts

Um ein erstes Erfolgserlebnis zu haben, legen wir nun ein PHP-Projekt an, das unsere bisherigen Dateien im Verzeichnis “myproject” unterhalb der Workbench umfassen soll. Wir nutzen hierfür den Menüpunkt:

“File” >> “New” >> “PHP Project”

Im sich öffnenden Dialog wählen wir einen Projektnamen, z.B.: “my_project”.

Eclipse New Project

Wir klicken auf den Radiobutton “Create new projects in workspace”.

Falls wir bestimmte PHP-Versionsprüfungen aktivieren wollen, wählen wir dies unter “Use project specific settings”. In meinem Fall “PHP 5.1/5.2”. Wir klicken ferner “use project as source folder”.

Den Punkt “Enable JavaScript support for this project” kann man bei sehr großen Projekten zunächst auch weglassen (dies kostet sehr viel zeitlichen Overhead bei den von Eclipse durchgeführten Fehler-Prüfungen und lohnt sich nur, wenn man viel mit Javascript-Programmen arbeitet).

Zu den Projekteinstellungen noch zwei Hinweise:

  • Hinweis 1: Ein Klick auf das Hilfe-Icon (Fragezeichen) führt zu Hilfeseiten mit vielen nützlichen Kurzinformationen zu den eben benutzten Optionen.
  • Hinweis 2: Die Javascript-Unterstützung kann man einem Projekt (ebenso wie die PHP-Unterstützung) auch noch im nachhinein zufügen. Die relevanten Menüpunkte findet man unter
    RMT auf das Projekt >> Configure

    Auf Details von Projekteinstellungen gehe ich aber noch in einem späteren Beitrag ein.

Nach den Festlegungen für unser Projekt klicken wir auf den Button “Weiter”. Auf der nächsten Konfigurationsseite wird angezeigt, dass unser Projekt-Verzeichnis als Source-Folder in den Include-Pfad eingefügt wurde. Man erkennt, dass man hier bei Bedarf noch andere Ressourcen in den Include-Pfad integrieren könnte. Die anderen verfügbaren Reiter ignorieren wir und drücken schließlich auf den Button “Finish”.

Im PHP-Explorer-Fenster wird nun das PHP-Projekt angelegt. Dass es sich tatsächlich um ein PHP-Projekt handelt, erkennt man am kleinen “P” oberhalb des Namens. (Ein
anderer Web-Projekttyp könnte etwa ein Javascript-Projekt sein – dieses würde dann über ein “JS” oberhalb des Namens angezeigt werden).

Eclipse PHP Explorer

Rechts unten in der Fußzeile des Eclipse-Fensters sehen wir übrigens für einige Sekunden (je nach Größe und Anzahl der bereits vorhandenen Dateien) den Fortschritt der sog. “Build-Operationen” für das Projekt. Hier werden u.a. auch alle Dateien auf Fehler oder Probleme geprüft, die dann zu entsprechenden Hinweisen im Eclipse-System führen (unter der Ansicht “Problems”, die sich standardmäßig im unteren Fensterbereich befindet.

Schritt 5: Modifikation der Default Character Codes für die Dateien des Projekts

Nun klicken wir per RMT auf den Projektnamen im PHP-Explorer und öffnen im Kontext-Menü den Punkt “Eigenschaften”. Im dortigen Dialog stellen wir bei Bedarf die Default-Character-Kodierung der Projektdateien um, um beim Betrachten der Dateien im Editor problematische Zeichen zu vermeiden. Will man den verwendeten Character-Set für den Workspace generell ändern, muss man den entsprechenden Punkt unter

Window >> Preferences >> General >> Workspace

einstellen.

Eclipse Preferences

Character-Code-Einstellungen kann man übrigens auch pro Datei vornehmen (s.u.).

Schritt 6: Öffnen von Dateien und elementare Einstellungen des Eclipse PHP-Editors

Nun können wir auch eine unserer Projekt-Dateien im Eclipse Editor (für PHP) öffnen. Dazu klappen wir die Verzeichnisstruktur des Projekts im PHP Explorer auf (Klicks auf die dem Projekt und seinen Unterverzeichnissen vorangestellten Dreiecke). Eine Datei öffnet man durch Doppelklick auf den Dateinamen. Hierbei öffnet sich rechts der in Eclipse integrierte “PHP Editor”.

Andere Möglichkeiten zum Öffnen einer Datei erreicht man über einen RMT-Klick auf den Dateinamen im PHP-Explorer und die Optionen des sich öffnenden Kontext-Menüs. Externe Editoren erreicht man über

RMT auf Dateinamen >> Open With >> Other >> External Programs

Font- und Farb-Preferenzen für den Editor

Welche Schriften und Markierungen der Eclipse eigene PHP-Editor benutzen soll, legen wir auch unter den “Preferences” fest:

Window >> Preferences >> General >> Appearance >> Structured Text Editors

Dort kann die Vorgabe der Fonts für den Editor editiert werden. Wesentliche Farben für die Hervorhebung bestimmter Elemente eines PHP-Programms definieren wir dagegen über den Menüpunkt

Window >> Preferences >> PHP >> Editor >> Syntax Coloring.

(Diese Umstellung kostet nach dem “Apply” manchmal leider etwas Zeit – vor allem wenn die Farben zur Hervorhebung von Klassenelementen geändert werden.)

Anzeige von PHP-Konstrukten im Outline View

Standardmäßig führt das Öffnen einer Datei mit dem eingebauten Editor auch zu einer Anzeige der wesentlichen definitorischen Elemente – wie Klassen, Methoden, Variablen etc. im sog. “Outline”-Fenster, das in der Regel rechts neben dem Editor-Fenster angezeigt wird.

Character Code pro Datei einstellen

Dies geht bei geöffneter Datei im Eclipse-eigenen Editor (der Mauscursor muss im Editor aktiv sein) über den Menüpunkt

Edit >> Set Encoding

Schritt 7: Sichten und weitere Fenster

Alle angebotenen “Sichten” oder “Perspektiven” von Eclipse auf die aktuellen Projekte und Daten (je nach aktueller Installation von Eclipse-Paketen und Plugins) kann man

  • entweder über die Menüpunkte “Window” >> “Open Perspective” oder “Window” >> “Show View”
  • oder ganz links unten über das langgestreckte Symbol mit dem Pluszeichen rechts

eclipse_view_but

öffnen und per Maus im Hauptfenster oder einem seiner Teilfenster an passender Position anordnen. Hier hilft dir durchgehende Reiter-Technologie von Eclipse dabei, die Übersicht zu behalten.

Links mit weiteren Hinweisen zur Installation


http://www.jacovosloo.info/blog/general-it/eclipseonopensuse113

http://www.unixboard.de/vb3/showthread.php?39958-Eclipse-installieren&p=314170
http://tropenhitze.wordpress.com/2010/02/01/installing-eclipse-ide-on-linux-opensuse-11-2/
http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/406454-installing-eclipse.html
http://www.linux-club.de/viewtopic.php?f=28&t=95531
http://www.linuxquestions.org/questions/linux-software-2/guide-to-install-eclipse-564770/

http://www.fedoranews.org/contributors/yves_janse/eclipse/06.shtml

http://www.ubuntu-forum.de/artikel/443/eclipse-installieren.html
http://www-rbi.informatik.rwth-aachen.de/Helpdesk/eclipse-linux-installieren.php
http://wiki.ubuntuusers.de/Eclipse?action=export&format=raw&rev=29957
http://wiki.ubuntuusers.de/eclipse

Hinweise zu einer systemweiten Installation
Es empfiehlt sich dann aus meiner Sicht, eine Installation unter den Verzeichnissen “/opt”, “/usr/local” oder “/usr/share” mit hinreichenden Ausführungsrechten. Allerdings muss man sich dann auch intensiv Gedanken über die Update-Politik innerhalb von Eclipse machen. Da dies nicht zu den einfachsten Aufgaben gehört, habe ich das Thema bisher regelmäßig durch individuelle Installationen umgangen. getreu der Devise: Jeder Entwickler ist im Kern selbst für seine Entwicklungsumgebung verantwortlich.

http://divby0.blogspot.com/2007/08/howto-install-eclipse-for-multi-user.html
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/multi_user_installs.html

Eclipse für PHP unter Opensuse – I

Einführung – Eclipse statt Dreamweaver für die PHP-Entwicklung

Lange Zeit habe ich bei einfachen PHP-Projekten aus historischen Gründen Dreamweaver CS4 als besseren “Editor” eingesetzt und damit “herumgedoktert”. Und das gleich in zweifacher Hinsicht:

  • Dreamweaver betreibt man trotz Wine und Crossover Office immer noch am besten unter Windows. Aber wer will als Linuxer schon auf Dauer mit einer solchen Umgebung leben? Selbst wenn sie sich nur in einer virtuellen Maschine entfalten darf …..
  • Zudem ist die Arbeit bei komplexen Projekten sehr unkomfortabel, denn für einen schnellen, organisierten Entwicklungsprozess fehlen Dreamweaver eine Reihe von Features, die man im Lauf der Zeit immer mehr vermisst

Nachfolgend nenne ich nur drei der Mängel:

Fehlende Editor-Funktionen und Unterstützung bei der Bearbeitung von Klassen in Dreamweaver
So ist eine aktive Unterstützung während des Editierprozesses speziell von Klassen (u.a. Syntaxprüfung, automat. Angebot an Membervariablen / Methoden) so gut wie nicht vorhanden. Das reduziert sich bei Dreamweaver im wesentlichen auf Code-Highlighting und Angaben zu Interfaces von PHP-Standard-Funktionen. Auch ist es für den Entwickler kaum möglich, bei umfangreichen Klassen einen schnellen Überblick über die benutzten Variablen und Methoden der Klasse mit entsprechenden Links zu den Codestellen im Editor zu bekommen.

Fehlende Anbindung an ein Versionskontrollsystem in Dreamweaver CS4
Vor allem aber erforderte ein vernünftiges Versionsmanagement zumindest bis zur CS4-Version einen mühsamen Umweg über den Linux-Host, um erstellte Dateien dort in eine aktuelle SVN-Version einchecken zu können. Ganz sinnvoll und praktikabel fand ich aber unter Dreamweaver das Checkout/Checkin-Verfahren mit den zugehörigen Dateisperren im Zusammenspeil mehrerer Entwickler. (Hinweisen möchte ich allerdings darauf, dass man seit der CS5-Ausgabe SVN Repositories auch für die SVN Version 1.6.x angeblich an Dreamweaver anbinden kann).

Kein integriertes Tool zur systematischen Erfassung von anstehenden Aufgaben
Ein Nachteil ist aus meiner Sicht auch, dass man das systematische Erfassen und Abarbeiten von Aufgaben mit separaten Tools (z.B. einem Task- oder Projektmanagement-Tool) übernehmen muss, die nicht in die Entwicklungsumgebung “Dreamweaver” integriert sind.

Diese Nachteile einer PHP-Entwicklung unter Adobes Dreamweaver lassen sich dann gut ertragen, wenn in der Regel nur zwei bis drei Personen mit einem Projekt beschäftigt sind, die Entwicklung der Benutzerschnittstelle im Vordergrund steht und die Projekte – speziell die Klassen-Bibliotheken – einen überschaubaren Umfang haben.

Eclipse “Helios” als Kern eines Linux-basierten PHP-Entwicklungssystems als kostenfreie Alternative
Im vergangenen Jahr wurden unsere Projekte aber immer komplizierter und die Anzahl der Klassenbibliotheken immer größer. Deshalb war es allerhöchste Zeit, zu einer besseren Entwicklungsumgebung zu wechseln. Im Frühjahr 2010 ist dann Eclipse in der “Helios”-Version erschienen. Dieser IDE ging ein guter Ruf voraus. Auch die früheren Schwieigkeiten bei der Einbindung von Subversion sollten dort behoben sein. Nach einigen Tests und einer Einarbeitungsphase bin ich inzwischen komplett auf Eclipse Helios unter Linux umgestiegen.

In der folgenden Serie von Artikeln in diesem Blog will ich die Installation und den Einsatz von Eclipse in einer Linux-Umgebung unter Opensuse 11.3/11.4 beschreiben. Wichtig ist mir dabie die Kombination mit SVN, einer Apache/MySQL-Test-Umgebung und nicht zuletzt auch mit Dreamweaver.

Kombination von Eclipse mit Adobe Dreamweaver möglich ?
Wenn mehrere Leute zusammenarbeiten und eine Person sich weiter mit der Wysiwyg-Umgebung Dreamweaver
um die Benutzerschnittstelle kümmern will oder muss, stellt sich natürlich die Frage, wie man die Eclipse-Helios-Welt unter Linux mit der Adobe Dreamweaver/Windows-Welt in einem geordneten Entwicklungsprozess kombinieren will. Das ist tatsächlich nicht ganz einfach, da das Checkout/Checkin-Verfahren der Dreamweaver-Umgebung schlecht zu Subversion passt. Hier wird vom Entwickler einige Disziplin verlangt. Dennoch ist ein geordnetes Vorgehen möglich.

Meine unter Eclipse entwickelten PHP-, HTML-, CSS-, Javascript-Dateien stehen heute – nach einigen Experimenten – immer auch meiner Mitarbeiterin zur Verfügung, die (noch) unter Dreamweaver weiterentwickelt und sich auf die Benutzerschnittstelle unserer Weblösungen konzentriert. Wir haben bei uns im Lauf der Zeit ein zweistufiges Entwicklungsverfahren unter der Einbeziehung von Eclipse unter Linux und Adobe Dreamweaver unter Windows etabliert. Das Vorgehen beruht wesentlich auf dem Einsatz von Samba als vermittelndem Verzeichnisdienst zwischen der Adobe-Umgebung in einem virtuellen Windows-System und der eigentlichen Web- und Datenbankserver-Umgebung unter Linux.

Einführung

Für wen ist die kommende Artikelserie zu Eclipse gedacht? Was werden die Inhalte sein?

Die nachfolgenden Artikel befassen sich mit der Implementierung von Eclipse und den ersten erforderlichen Schritten für den späteren produktiven Einsatz unter Opensuse-Linux. Die Artikelserie ist für Leute gedacht, die sich noch nicht mit Eclipse auseinandergesetzt haben, aber den Umstieg auf Eclipse und eine PHP-Entwicklungsumgebung unter Linux unter Einbeziehung eines Web- und Datenbankservers in Erwägung ziehen.

Administrative Grundkenntnisse im Umgang mit Linux (hier in der Opensuse-Ausprägung) sind dabei nötig. Das hält sich aber in Grenzen, da ich mich hier der Einfachheit halber hauptsächlich auf eine Implementierung auf einem einzigen lokalen Linux-System beschränken werde. Das Ergebnis entspricht dann etwa einem autonomen Entwicklungssystem auf einem Desktop-Rechner oder einem Laptop, auf dem eben auch einige einfach konfigurierte Serverkomponenten mitlaufen.

Man sollte also neben dem reinen Interesse für Eclipse auch den Ehrgeiz mitbringen, auf seinem Entwicklungssystem unter Linux auch einen Apache-Server und einen MySQL-Server aufzusetzen. Ohne einen Web- und Datenbank-Server macht ja eine PHP-Entwicklung ohnehin kaum Sinn. Ich werde mich in dieser Artikelreihe allerdings nicht mit den Details einer umfassenden Installation von Server-Modulen, geschweige denn mit der Konfiguration eines Netzwerkes mit Apache-, Samba-, DNS- und Datenbankservern befassen. Im hiesigen Zusammenhang müssen Hinweise auf eine lokale Server-Installation auf einem minimalen, aber hinreichenden Niveau genügen.

Ich selbst habe den Einstieg in Eclipse selbst insgesamt als etwas knifflig empfunden. Da ich auch nach fast 12 Monaten noch längst nicht alle Seiten der Eclipse IDE erkundet habe, bitte ich bei dem einen oder anderen möglichen Fehler oder der einen oder anderen Nachlässigkeit oder Unvollständigkeit der Ausführungen um Nachsicht.

Ich möchte an dieser Stelle nicht verhehlen, dass Eclipse auch einige Nachteile hat. U.a. ist die miserable Performance des eingebauten Editors bei der Behandlung großer Dateien (> 4000 Lines) zu nennen. Ferner kann es manchmal bei komplexen Operationen und Eingriffen in Dateiinhalte mit Fremd-Editoren zu merkwürdigen Kapriolen in der Versionsverwaltung kommen, die man nicht immer versteht. Zudem laufen Updates des Eclipse-Systems und seiner Plugins nicht immer anstandslos durch, weil ggf. Repositories fehlen oder nicht alle Abhängigkeiten aufgelöst werden können. Aber ich habe hier bislang noch immer in relativ kurzer Zeit ein Lösung gefunden.

Alles in allem möchte ich Leuten, die PHP-Entwicklung betreiben wollen und mit ihrer Entwicklungsumgebung – im speziellen Dreamweaver – unzufrieden sind, doch anraten, Eclipse wenigstens
einmal testweise auszuprobieren. Der Schritt von Eclipse zu umfangreicheren Umgebungen (z.B. zu einer voll ausgebauten Zend Entwicklungsumgebung) ist dann oft recht einfach.

Implementierung für ein lokales und autonomes Entwicklungssystem

Die Implementierung möchte ich zur Vereinfachung am Beispiel eines lokalen Entwicklungssystems unter Opensuse 11.3/11.4 darstellen. Ich selbst habe die hier beschriebenen Schritte zum Einsatz von Eclipse im Juli 2010 zunächst auf einem Laptop mit nagelneu installierten “Opensuse 11.3”-System und KDE 4.4.4 durchgeführt und habe danach eine Installation in einer Umgebung mit separaten File, Web- und Datenbank-Servern nachgezogen. (Heute läuft Eclipse bei mir auf mehreren Desktops und Laptops unter Opensuse 11.4 und KDE 4.6.1.)

Unser lokales, autonomes Entwicklungssystem soll nach seiner Implementierung folgende Komponenten umfassen:

  • einen SSL-fähigen Apache-Webserver mit “PHP 5.3”-Modulen,
  • MySQL 5,
  • SVN 1.6,
  • Eclipse Helios mit Erweiterungen für die PHP-Entwicklung, eine SVN-Anbindung und mit Tools für Remote System Interaktionen.

Hinzu kommen für die Kooperation mit Dreamweaver

  • eine lokale virtuelle Maschine (in meinem Fall unter VMware Workstation mit einem Windows-System und der Adobe Web Premium Suite CS4.
  • ein lokaler Samba-Server.

In diesem ersten Teil befasse ich mich kurz mit den notwendigen Installationsarbeiten zu Apache, MySQL und SVN. Im zweiten Teil gehe ich dann auf die eigentliche Eclipse-Installation inkl. der Anlage eines ersten PHP-Projektes ein. Im 3-ten Teil behandle ich kurz die Implementierung von Eclipse-Erweiterungen (speziell für SVN) samt Updates. In Teil 4 wird zunächst ein Testprojekt mit SVN verbunden. Danach erzeugen wir im fünften Teil 5 umgekehrt ein PHP-Projekt unter Eclipse aus den Inhalten eines bereits vorhandenen SVN-Repositories.

Im sechsten Teil dieser Reihe binden wir das Eclipse-Testprojekt dann an den Apache-Server an. In weiteren Teilen gehe ich noch auf Besonderheiten wie das Code-Debugging auf dem Webserver ein. Abschließend fasse ich einige persönliche Erfahrungen mit Eclipse zusammen und beschreibe zudem grob das Zusammenwirken mit Adobe Dreamweaver CS4 in einer virtuellen Windows-Umgebung unter Linux.

Hardware- und Betriebssystem-Umgebung – Hinweise zu HW-Voraussetzungen

Der bei meiner ersten Eclipse-Installation verwendete Laptop hatte 2 GB Hauptspeicher – und die braucht er auch, wenn neben Linux, KDE, Apache, MySQL auch Eclipse in einer Java-Runtime-Umgebung läuft. Der Speicherbedarf von Eclipse ist enorm, bei größeren Aufgaben auch der Bedarf an Zeigern des Betriebsystems zu offenen Dateien – speziell wenn man gleichzeitig SVN einsetzt. Hier sind entsprechende Anpassungen im OS nötig, auf die ich an passender Stelle eingehen werde.

Der Dual-Core Prozessor des Laptops war mit 2,14 GHz ist für ein flüssiges Arbeiten völlig ausreichend. Wegen der doch sehr umfassenden und in viele Teilbereiche gegliederten Benutzer-Oberfläche vom Eclipse war ich zudem sehr froh über den 17 Zoll-Schirm des Laptops und seine hohe Auflösung (1920×1200 px). Im professionellen Einsatz möchte ich allerdings zu einer Desktop-Umgebung raten, in der man mit 2 größeren Schirmen arbeitet. Dies gilt erst recht, wenn neben Eclipse auch noch Adobe’s CSx-Umgebung (in einem virtuellen Windows) zum Einsatz kommt.

Vorbereitung und Know-How-Aufbau

Da ich mich mit Eclipse für PHP in der Praxis so gut wie nicht auskannte, habe ich vor meinen ersten Schritten versucht, im Internet Informationen zu finden, die für Einsteiger geeignet sind. Leider sind die meisten Artikel, die ich
gesehen habe, naturgemäß an Java-Entwickler gerichtet – und die damit zusammenhängenden Verfahren und Subsysteme von Eclipse interessieren mich als PHP-Entwickler weniger. Leider sind die verfügbaren Artikel auch keineswegs immer so geschrieben, dass man das dort Gesagte einfach auf eine PHP-Entwicklungssituation übertragen könnte.

Wirklich hilfreich für mich war dann eine Video-Tutorial-Serie von “Ralphz” (s. die Links weiter unten), die ich empfehlen möchte. Sie betreffen zwar ältere Eclipse- und PTD-Versionen – aber didaktisch sind die Tutorials so gehalten, dass man das dort Gezeigte fast problemfrei auf die Helios-Umgebung übertragen kann.

Bitte also die Video-Tutorials in Ruhe und komplett ansehen, bevor man mit den Installationsarbeiten beginnt. Man sollte sich erst einen Überblick über die vielfältigen Möglichkeiten und PHP-relevanten Plugins sowie SVN-Plugins etc. verschafft haben, bevor man beginnt, seine persönliche Entwicklungsumgebung aufzubauen.

Die Tutorials machen auch klar, wie Eclipse mit SVN zusammenarbeitet. Man muss über SVN nicht viel wissen, um es zumindest für ein Projekt ohne Entwicklungsverzweigung unmittelbar einsetzen zu können. Ansonsten sei hier auf das auch von “Ralphz” zitierte Online-Buch zu Subversion verwiesen.

Links:

http://vimeo.com/1077103 und die dortigen weiteren Videos aus der Serie von “Ralphz”.
http://theorangeit.org/category/programming/php/page/3/ Ralphz’s Blog
http://www.eclipse.org/subversive/documentation/gettingStarted/aboutSubversive/install.php
– Installation-Info zum Subversion-Plugin

Installationsplanung

Mein Ziel war es wie gesagt, eine vollständige Entwicklungsumgebung auf einem Laptop zum Laufen zu bringen. Eclipse ist davon natürlich nur ein Teil und interagiert mit anderen Komponenten. Ich liste mal die wesentlichen Komponenten etwas detaillierter als oben auf:

  • Apache2-Server mit virtuellen, SSL-fähigen Domainen (warum letztere nützlich sind, erläutere ich weiter unten).
  • Apache’s PHP5-Modul zur Unterstützung von PHP
  • Einen laufenden MySQL5-Server.
  • PhpMyAdmin
  • SVN in der Version 1.6.6 als Versionsverwaltungstool.
  • KDESVN als primären SVN-Client
  • Java 6 JRE von SUN oder das Open-JDK in der Version 1.6
  • Kate als sekundären Editor
  • Firefox als Browser
  • Eclipse Helios mit folgende Plugins:
    • dem PTD-Plugin für die eigentliche PHP-Entwicklungsarbeit,
    • dem Subversive-Plugin und Subversive Connectors für die Anbindung an SVN,
    • dem Web-Entwicklungs-Plugin WTP plus Javascript Development-Unterstützung,
    • das Target-Management mit dem Remote-System-Explorer
    • XDebug als Debugging-Subsystem.

Bzgl. einiger Eclipse Plugins gibt es Alternativen – z.B. das “Subclipse”-Plugin statt des “Subversion”-Plugins für die Anbindung an SVN oder ZEN-Tools für das Debugging. Ich habe Subclipse noch nicht erforscht und kann daher dazu nichts Vernünftiges sagen. Die von mir installierten Subversion-Plugins funktionieren aber gut und ich kann damit im Moment leben.

Installation der Nicht-Eclipse-Komponenten

In diesem Beitrag kann ich die Installation von Apache, MySql, etc. nicht im Detail beschreiben. Das würde den Rahmen sprengen. Ich habe die Minimal-Installation für beide Systeme aber in früheren Blog-Artikeln dargestellt, auf die ich an dieser Stelle hinweise. Ansonsten
noch ein paar zusätzliche Anmerkungen:

Apache und PHP5 – lokale Installation

Das lokale Entwicklungssystem soll später autonom – d.h. ohne Netzverbindung funktionieren. Ein DNS-Dienst ist für ein rein lokales System überflüssig. Daher können Einträge in “/etc/hosts” das Loopback-Interface verwenden und etwa so aussehen.

127.0.0.1 localhost.localdomain localhost
127.0.0.2 mylap.myprivatedomain.de mylap
127.0.0.2 devdomain

Die IP-Adresse ist wichtig für das spätere Aufsetzen einer IP-basierten, SSL-fähigen virtuellen Web-Domaine “devdomain”. Unter dieser Domaine werden im weiteren Verlauf die Resuktate meines PHP-Projektes sichtbar werden. Als “Netzwerk-Adresse” in einem Browser muss dann halt eine Loopback-Adresse herhalten.

Es gibt im Internet immer wieder kritische Diskussionen zur Verwendung von Loopback-Adressen – ich denke, man kann das im hiesigen Zusammenhang mal getrost ignorieren. Der Weg über “/etc/hosts” und Loopback-Adressen ist eine Krücke Aber die wesentliche Funktionalität eines autonomen Entwicklungs- und Test-Systems lässt sich damit schnell, übersichtlich und ohne große Umwege erreichen.

Apache kann man unter Opensuse einfach über die Yast und die dortige Paketverwaltung installieren. Der folgende frühere Artikel in diesem Blog gibt eine Übersicht darüber, was zu tun ist, um auf die Schnelle die SSL-Fähigkeit des Servers zu aktivieren, eine Standarddomaine (für localhost) sowie eine SSL-fähige “devdomain” bereitzustellen.

Lokaler Apache auf die Schnelle

Die meisten meiner PHP-Lösungen für Kunden erzwingen in der Regel einen HTTPS-Verbindung. Wenn ich das lokal testen will, komme ich um SSL also nicht herum. SSL geht nur über IP-basierte virtuelle Domainen. Für den Standardhost “localhost” ist daher eine zweite separate virtuelle Domaine einzurichten. Siehe zu den Details und den Apache-Konfigurationsdateien den eben genannten, früheren Beitrag.

Die virtuelle SSL-Domaine “devdomain” des Apache-Servers wird über dei DocumentRoot-Anweisung in der Apache-Konfiguration später entweder dem Verzeichnis

DocumentRoot “/srv/www/htdocs/Entwicklung/devdomain/trunk”

oder aber einfacher dem Verzeichnis

DocumentRoot “/srv/www/htdocs/Entwicklung/devdomain/”

zugeordnet. Dieses Verzeichnis wird später auch über die Datei-Transfermechanismen des “Target-Managements” von Eclipse gefüllt.

Die erste Variante benötigt man, wenn man mit Entwicklungszweigen unter SVN arbeiten will. Die Zuordnung zu dem Unterverzeichnis “trunk” deutet bereits an, dass eine verzweigte SVN-Repository-Struktur auf den Apache-Server abgebildet wird. Man kann allerdings auf das “trunk”-Unterverzeichnis auch verzichten. In vielen einfachen Entwicklungsszenarien, in denen “Forks” keine Rolle spielen, ist das evtl. sogar hilfreich. Ich gehe auf beide Alternativen später beim Beschreiben (m)einer Variante des Zusammenspiels von Eclipse mit dem Apache-Server und auch Dreamweaver ein.

Die eingerichtete virtuelle Web-Domaine hilft später beim Testen übrigens auch deshalb erheblich, weil man damit die Tipparbeit in der Adresszeile des Browsers erheblich abkürzt.

Anpassungen der php.ini-Konfigurations-Datei

Auf einem Entwicklungssystem will man natürlich Fehlermeldungen und Warnungen zu PHP5-Programmen sehen. Evtl. hat man auch Programme, die mit der Kurzform der Script-Tags

statt

lauffähig sein sollen. Um zudem beim Einsatz der Funktion date() Warnungen zu vermeiden, ist man zudem genötigt, die Standardzeitzone für das PHP-Modul ein.

nFür all das muss man entsprechende Modifikationen an der Datei

“/etc/php5/apache2/php.ini”

vornehmen. Sehen Sie zu Details bitte den oben genannten, früheren Beitrag zur Apache-Installation .

XDebug

Plant man XDebug als Test- und Debug-Umgebung auf dem Apache/PHP-Server zu verwenden, so muss man unter Opensuse noch ein Repository für die Installation der zugehörigen Module aktivieren. Siehe:

http://download.opensuse.org/repositories/server:/php:/extensions/server_php_openSUSE_11.3

Generelle Informationen zu XDebug findet man unter:

http://www.xdebug.org/

Zur Installation von XDegbug sind ggf. folgende Beiträge hilfreich:

http://www.howtoforge.com/installing-php5-debugger-on-opensuse-11.3
http://serwatka.net/blog/xdebug_and_apc_on_opensuse
https://build.opensuse.org/package/show?package=php5-xdebug&project=server:php:extensions
http://osdir.com/ml/php.xdebug.general/2006-12/msg00015.html

Bzgl. Xdebug sind noch nachfolgende Einträge in der php.ini erwähnenswert. Ich folge hier im wesentlichen den Vorgaben des Videos 7 in der Eclipse-Video-Reihe von “ralphz” zu diesem Thema:

zend-extension=”/usr/lib64/php5/extensions/xdebug.so”

xdebug.remote_enable=On

xdebug.remote_host=”localhost”

xdebug.remote_port=9000

xdebug.dump_undefined=On

xdebug.collect_parms=4

xdebug.var_display_max_depth=4

Einheitliche Gruppe und Rechte für das Apache-Entwicklungs-Verzeichnis setzen

Nach der Einrichtung des Apache-Servers wollen wir uns das Leben bzgl. der Rechte auf dem lokalen Testserver etwas vereinfachen. Hierzu legen wir eine Gruppe “entwicklung” an, der der Apache-User – unter Opensuse “wwwrun” – und weitere Entwickler – hier “myself” und “developer” angehören sollen.

Alle Dateien, die wir später aus Eclipse in das zugeordnete Verzeichnis des Webservers – hier “/srv/www/htdocs/Entwicklung/devdomain/” – transportieren wollen, sollen automatisch Zughörigkeit zur Gruppe “entwicklung” und einen einheitlichen Rechtekamm für die Gruppenrechte erhalten.

Wie man zur Vererbung von Gruppenrechten mit ACLs vorgeht, ist ausführlich in einem früheren Beitrag beschrieben

Vererbung von Gruppenrechten mit ext3/ext4 und ACLs

Zunächst prüfen wir in der datei “/etc/fstab” nach, dass ACLs für das Dateisystem aktiv sind, auf dem auch die Apache DocumentRoot-Dateien untergebracht sind. Danach führen wir für das Apache-Haupt-Verzeichnis zu unseren Entwicklungsarbeiten

“/srv/www/htdocs/Entwicklung/”

folgende Kommandos durch (als root-User)

cd /srv/www/htdocs/

chgrp   entwicklung     Entwicklung

chmod   775     Entwicklung

chmod   g+s     Entwicklung

setfacl -m    m::rwx     Entwicklung

setfacl -dm   g:entwicklung:rwx     Entwicklung

Von nun an erben alle Verzeichnisse und Dateien, die später unterhalb des Verzeichnisses “/srv/www/htdocs/Entwicklung” angelegt werden, die Gruppenzugehörigkeit zur Gruppe “entwicklung” und die angegebenen vollen Gruppenrechte.

MySQL und PhpMyAdmin

Die MySQL-Installation unter Opensuse ist recht einfach. Sie ist in Grundzügen im Artikel

https://linux-blog.anracom.com/2010/08/28/lokale-mysql-phpmyadmin-installation/

beschrieben.

Installation SVN

Subversion ist schnell über entsprechende Pakete installiert:

subversion

subversion-server (wenn man plant, Subversion auf dem Apache-Server selbst laufen zu lassen)

svnmanager (wenn man plant, Subversion auf dem Apache-Server selbst zu administrieren)

subversion-tools

kdesvn (graphischer KDE Client für Subversion)

usvn (PHP-Tool für Subversion auf dem Apache Server)

Installation JRE

Die für Eclipse benötigte Runtime Umgebung installiert man unter Opensuse schnell mit Yast un der dortigen Paket-Verwaltung. Hier stehen das JDK und die Sun JRE zur Auswahl. Für weitere Informationen und zum Wechsel zwischen den Umgebungen – falls man beide installieren und ausprobieren will – siehe :

http://de.opensuse.org/Java#Zwischen_verschiedenen_Java_JREs_oder_SDKs_wechseln

So ausgestattet haben wir nun ein System, das alle elementaren Zutaten für eine autonome PHP-Web-Entwicklungsumgebung unter Opensuse 11.3/11.4 aufweist.

Im nächsten Beitrag beschäftigen wir uns dann mit der Eclipse-Installation und den erforderlichen Erweiterungen für PHP und Subversion.

Suse 11.3, KDE 4.5, Sound, udev, cdrom

Ich habe zwei DVD-Laufwerke – einen Brenner und ein gewöhnliches DVD/CDROM-Lesegeät. Beides sind SATA-Geräte und erscheinen als folgende Gerätedateien

/dev/sr1 – DVD/CD-ROM Lesegerät
/dev/sr0 – DVD/CD-RW Brenner

Mit dieser Kombination kommen weder Opensuse 11.3 noch KDE 4.5 so richtig klar. Audio-CDs und DVDs werden mit den Default-Einstellungen leider im Brenner – und nur dort – erwartet. Hier also unter : /dev/sr0.

Relevant hierfür sind symbolische Links für “/dev/dvd” oder “/dev/cdrom” , die vom System auf dieses Gerät gesetzt werden. Diese Links werden u.a. von KDE’s KIO-Slave-Prozessen benutzt. In meinem Fall tauchen im Geräte-Verzeichnis “/dev” folgende Einträge auf:

user@mysystem:/dev> dir cd*
lrwxrwxrwx 1 root root 3 9. Jan 15:26 cdrom -> sr0
lrwxrwxrwx 1 root root 3 9. Jan 15:26 cdrom1 -> sr1
lrwxrwxrwx 1 root root 3 9. Jan 15:26 cdrw -> sr0

user@mysystem:/dev> dir dvd*
lrwxrwxrwx 1 root root 3 9. Jan 15:26 dvd -> sr0
lrwxrwxrwx 1 root root 3 9. Jan 15:26 dvd1 -> sr1
lrwxrwxrwx 1 root root 3 9. Jan 15:26 dvdrw -> sr0

Es hilft in einer solchen Situation leider wenig, nur in den KDE-Systemeinstellungen für “Multimedia”-Geräte verschiedene Einstellungen auszuprobieren. KsCD, Amarok und andere Anwendungen reagieren trotzdem falsch bis unterschiedlich.

Ein typisches Problem ist das, dass weder KsCD, Banshee, Kaffeine, Dolphin noch Amarok Audio-CDs in dem nomalerweise benutzten Lesegerät (hier /dev/sr1) erkennen, öffnen und abspielen können. Auch nicht, wenn man in den KDE-Systemeinstellungen /dev/sr1 oder /dev/cdrom1 für Audio-Medien vorgibt. Das ist eines der vielen Ärgernisse im Umgang mit KDE, die man mit den Jahren satt hat. Aber was solls, solange es eine Lösung gibt.

Leider vergesse ich selber immer wieder, was man tun muss, um Schwierigkeiten von vornherein aus dem Wege zu gehen. Daher an dieser Stelle ein kurzer Hinweis auf die relevanten Konfigurationseinstellungen:

Udev-Einstellungen

Unter “/etc/udev” werden permanente Einstellungen für das Udev-System (und damit u.a. auch für die Audio-Wechselmedien-Geräte) hinterlegt. Die relevante Datei ist

/etc/udev/rules.d/70-persistent-cd.rules

Damit meine /dev/sr0 und /dev/sr1-Geräte so zugeordnet werden, dass “/dev/cdrom” und “/dev/dvd” auf das Lesegerät “/dev/sr1″ fallen, müssen die Einstellungen – entgegen dem Default – in meinem Fall wie folgt gesetzt werden:

# CDDVDW_SH-S223F (pci-0000:00:1f.2-scsi-0:0:0:0)
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-0:0:0:0″, SYMLINK+=”cdrom1″, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-0:0:0:0″, SYMLINK+=”cdrw”, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-0:0:0:0″, SYMLINK+=”dvd1″, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-0:0:0:0″, SYMLINK+=”dvdrw”, ENV{GENERATED}=”1″

# DVD-ROM_SH-D163B (pci-0000:00:1f.2-scsi-1:0:0:0)
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-1:0:0:0″, SYMLINK+=”cdrom”, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-1:0:0:0″, SYMLINK+=”dvd”, ENV{GENERATED}=”1″

Bei anderen Systemen können die Einstellungen und im Besonderen die SCSI-Ids natürlich etwas anders aussehen.
Wichtig ist, dass das zweite SCSI-Gerät ( hier: … scsi-1:0:0:0) für das Lesegerät beim Symlink auf “cdrom” und “dvd” gesetzt werden. Diese Einstellungen legen die oben genannten symbolischen Links fest, die während der Startphase des Systems im “/dev”-Verzeichnis eingetragen werden.

Hat man diese Einstellungen vorgenommen, sollte man den
Rechner neu booten.

Check der symbolischen Links im “/dev”-Verzeichnis

Nach dem Neubooten sollten folgend Links im /dev-Verzeichnis auftauchen:

user@mysystem::/dev> dir cd*
lrwxrwxrwx 1 root root 3 9. Jan 15:26 cdrom -> sr1
lrwxrwxrwx 1 root root 3 9. Jan 15:26 cdrom1 -> sr0
lrwxrwxrwx 1 root root 3 9. Jan 15:26 cdrw -> sr0

user@mysystem::/dev> dir dvd*
lrwxrwxrwx 1 root root 3 9. Jan 15:26 dvd -> sr1
lrwxrwxrwx 1 root root 3 9. Jan 15:26 dvd1 -> sr0
lrwxrwxrwx 1 root root 3 9. Jan 15:26 dvdrw -> sr0

KDE-Einstellungen

Unter KDE 4.5 muss man nun die “System-Einstellungen” aufrufen (entweder über das KDE-Menü oder durch Eingabe von “systemsettings” am Prompt der Kommandozeile). Dann wählt man im Bereich “Hardware” den Punkt “Multimedia” und dort dann die Einstellungen für “Audio-CDs”. Hier setzt man beim Punkt

“CD-Gerät angeben” : /dev/cdrom

ein. U.a. Amarok benutzt diese Einstellung, um eingelegte Audio-CDs zum Abspielen bereitzustellen .

Tests mit Dolphin, KSCD, Amarok

Nach den obigen Einstellungen sollte ein Einlegen einer Audio-CD in das normale Lesegerät keine Probleme mehr bereiten. Der Inhalt sollte in Dolphin etwa wie folgt angezeigt werden

audi_600

Amarok sollte die Audie-CD ebenfalls anbieten – ggf. nach etwas Warten für das Auslesen der CD :

amarok_600

KSCD sollte die Audio-CD ebenfalls abspielen:

KSCD_600

Viel Spass nun mit Audio-CDs im richtigen CD/DVD-Lesegerät.

KDE 4.6 Beta2 – oder Alpha preview ?

No risk – no frustration ……

Also ich gebe jetzt auf. Es ist ein Chaos mit KDE 4.6 Beta 1/2 – zumindest in den variierenden RPM-Zusammenstellungen, die Opensuse sukzessive im KDE Factory Repository angeboten hat.

[
Nachtrag 18.12.2010:
Hier muss ich präziser sein: Gemeint ist das Factory Repository im DISTRO-Zweig, also:
http://download.opensuse.org/repositories/KDE:/Distro:/Factory/openSUSE_11.3
In anderen “Factory”-Repositories – wie etwa dem im UNSTABLE-Zweig – mag sich ein anderer Stand widerspiegeln, aber man kann als normaler User ja nicht alles aus- und durchprobieren.
]

Der dauernde Zwang zu immer neuen Experimenten und neuen Konfigurationsanläufen aufgrund variierender Fehler kostet mich einfach viel zu viel Zeit. Ich gehe jetzt zurück zu KDE 4.5.3 und lasse das Ausprobieren von KDE 4.6 erst mal sein … so interessant der Blick auf einen breiteren Akonadi-Einsatz auch war.

Ein paar Gründe:

  • Akonadi, Kmail und IMAP in der Kombination mit Nepomuk/Virtuoso-t kosten zuviel CPU-Zeit (never ending indexing story)
  • Akonadi und OX 5 Ressourcen (Kalender, Adressbuch) arbeiten nur mangelhaft oder gar nicht zusammen. Eine simple Verbindung zum OX-Server wie in KDE 4.5 funktioniert nicht mehr und endet mit Fehlern. Eine manuelle Verbindung zum OX Adressbuch geht nur über LDAP. Die Anbindung des Kalenders nur manuell über eine webdav.ical – Verbindung. Aber auch dann nur lesend ….
  • Man kriegt nach neuen KDE-Updates die Sache oft nur wieder zum Laufen, indem man die rc-Konfigurationsdateien löscht und die Akonadi-Ressourcen komplett neu aufsetzt.
  • Zwischenzeitlich funktioniert dann mal die automatische Adressvervollständigung beim Schreiben von Mails nicht mehr.
  • Dann werden seit einem der letzten Updates die FORM-Felder in Mails nicht mehr gefüllt, wenn man in der Kmail Identity beim eigenen Namen einen Dr. mit einem Punkt (also Dr. Moenchmeyer) einträgt. Lässt man den Punkt weg (Dr Moenchmeyer), wird die FROM-Information in der Mail wieder wie gewohnt angegeben. (Ist im Unstable-Zweig gem. der Entwickler so aber nicht mehr nachweisbar …)
  • Seit einer der letzten Versionen funktionieren Programmicons, die man in die KDE Fußleiste zieht, nicht mehr.
  • Amarok ist seit einem “Update” heute nicht mehr in der Lage, die lokale Musik-Sammlung einzulesen oder upzudaten – es werden Null Songs angezeigt, obwohl vor dem Update noch ca. 1500 vorhanden waren.
  • Dann bietet Opensuse heute zweimal Updates im KDE-Factory-Repository an – und das zweite “Update”-Angebot beinhaltet dann KDE-PIM-Versionen aus der 4.4er- bzw. 4.5er-Zeit (genauer Kontact 4.4.8). (Offenbar hat auch Suse die mitbekommen, dass Kontact und Akonadi unter KDE 4.6 Beta doch noch massive Probleme haben.) Leider funktioniert nach dem Downgrade dann das “alte” Akonadi nicht mehr richtig mit OX 5 Adressbüchern zusammen und es kommt zu Segmentation Faults.

Damit kann ich nicht arbeiten. Das artet in alpha-Testing aus. Als Anwender ist es mir letztlich auch egal, wer an dem Kuddelmuddel schuld ist.

Fazit
Leuten, deren Zeit für Experimente begrenzt ist und die sich in der Weihnachtszeit nicht laufend ärgern wollen, empfehle ich jedenfalls: Im Moment Finger weg von KDE 4.6 Beta und mindestens noch 2 Monate bis zu einem neuen Anlauf warten.

Nachtrag – 23.03.2010
Ich benutze inzwischen Opensuse 11.4 sowhl auf meinem Desktop als auch Laptops zusammen mit KDE 4.6.1 aus dem Opensuse Factory Repository für KDE. Dort ist Kontact allerdings in der Version 4.4.10 enthalten. In dieser Kombination funktioniert alles relativ gut (weil Akonadi offenbar nicht für den IMAP-Betrieb zwischengeschaltet ist. Kmail hat die Version 1.13.6 – also kein Kmail 2.x !). Auch hier muss man aber bzgl. des Adressbuchs die schon früher
beschriebenen Verrenkungen betreiben.

KDE 4.6 Beta, K3b, Kmail, Akonadi, virtuoso-t, OX5

No risk no fun ! Dachte ich und habe mir mal KDE 4.6 Beta auf einem meiner Opensuse 11.3 Systeme installiert. Aus drei Gründen war das für mich ein interessantes Experiment :

  1. Weil unter KDE 4.5.2, KDE 4.5.3 K3b nicht mehr funktionierte und ich gemäß der Einträge bei den entsprechenden KDE-Bugs aber die Hoffnung bekam, es könne nun wieder laufen.
  2. Weil unter KDE 4.6 das Akonadi-Subsystem nicht mehr nur für das Adressbuch sondern auch für die Verwaltung der Mailordner zuständig wird. Hier ist das Wechselspiel mit IMAP-Systemen interessant.
  3. Weil Akonadi auch mit den Kalender-Ressourcen eines Open-Xchange 5 Servers zusammenarbeiten sollte.

Um es vorweg deutlich zu sagen: Solche Experimente mit Beta-Systemen wie zu Punkt 2 sollten keine produktiven IMAP- oder OX-Server einbeziehen, sondern nur Server, die Kopien der eigentlichen IMAP-Mail-Ordner und Kalenderdaten beinhalten! Zur Not richtet man sich einen IMAP-Testserver halt auf einem Laptop oder einem virtuellen System ein. Bei OX5 oder OX6 ist das zugegebenermaßen schon schwieriger.

Zu Punkt 1 – K3b:

K3b läuft unter Opensuse 11.3 und KDE 4.6 wieder – allerdings nur mit den letzten K3b RPM-Paketen 2.0.1-44.1 im Opensuse Factory Repository. Eine CD habe ich mal testweise gebrannt – das lief ohne Probleme. Genauer getestet habe ich das Brennen von unterschiedlichen Medien (DVD+-R, DVD+RW, etc. aber noch nicht. Das Rippen von CDs läuft mit der aktuellen Version aber wie gewohnt. Anzumerken bleibt: Die aktuellen RPMs von Packman 2.0.1.pm.2.26 laufen nicht. (Vermutlich wegen der erfolgten Änderungen im HAL-Bereich)

Zu Punkt 2 – Kmail, Akonadi, IMAP – und die problematische Wirkung von Filtern :

Die Verwaltung von Mailordnern durch Akonadi stelle ich mir persönlich als eine komplexe Angelegenheit vor. Im Besonderen dann, wenn die Mailordner auf einem IMAP-Server liegen und die Filterung von Mails (Spam und andere Filter) aber lokal unter KDE’s Kmail erfolgt. Ich habe auf meinem Desktop-System eine ganze Reihe von Filtern eingestellt. Nicht nur zum zusätzlichen Filtern von Spam, der auf dem Server nicht erkannt oder zu vorsichtig behandelt wurde, sondern auch themen- und kundenbezogene Filter.

Für mich als Anwender stellt sich doch die Frage, wie der mindestens zweistufige Weg der Filterung von Kmail über die Akonadi-Maschinerie hin zum IMAP-Server abläuft. Kmail als Frontend zu Akonadi initiiert die Filterung und als Reaktion werden dann ggf. Verschiebungen von Mails aus dem Posteingangsordner hin zu anderen Ordnern durchgeführt. Das Ergebnis muss sich zunächst auf dem lokalen Akonadi-System und dessen Abbildung der Mailordner niederschlagen. Die vorgenommenen Ergebnisse der Filteraktionen wie Löschungen im Ursprungsordner und entsprechende Neuzugang in definierten Zielordnern müssen ja aber auch periodisch zwischen Akonadi und dem IMAP-Server abgeglichen werden. In einer solchen Verarbeitungskette – MUA-Client <> Akonadi (als zwischengeschobenes zentraler Puffer) <> IMAP-Server – eröffnen sich zahlreiche Möglichkeiten für Fehler.

Meine Erfahrungen waren entsprechend :
Die Migration der vorhandenen Mail-Ordner aus dem alten Kmail hin zu Akonadi ging grundsätzlich ohne Probleme vonstatten. Es dauerte allerdings etliche Minuten, da unsere Mailordner mehrere Gigabyte umfassen. Die Zeitdauer für die Migration war aus meiner Sicht absolut OK. Probleme verursachten dann aber die bereits konfigurierten Mail-Filter aus meiner KDE 4.5.3-Kmail-Version. Diese fingen nämlich beim Füllen meiner doch zahlreichen Mailordner an zu wirken – und zwar nicht in der gewohnten Weise. Es wurde in andere lokale Ordner verschoben, die begonnen Filtervorgänge schluckten
enorm viel CPU-Zeit, die Kmail-Oberfläche kam letztlich zum Stillstand und war nicht mehr bedienbar …. Ursache war hier vermutlich, dass viele Mailordner im Zuge der Migration gleichzeitig neu befüllt wurden.

Kurzum:
Die Filter verursachten zeitversetzt und im Nachgang zum eigentlichen Migrationslauf zunächst ein ziemliches Chaos und ungewohnte Verschiebungen in lokale (!) Spam- und Trash-Ordner. Offenabr war ein teil der alten Konfiguration – nämlich die Festlegung der Zielordner – verloren gegangen. Nun ließen sich die laufenden Filterprozesse wegen des Stillstands der Kmail-Oberfläche leider auf konventionellem Wege auch nicht mehr aufhalten. Ein Killen der entsprechenden Prozesse, ein Löschen der Konfigurationsdatei kmail2rc und ein Neustart verhalfen mir schließlich zu der Möglichkeit, meine Filter zu entfernen und komplett neu anzulegen. Danach verhielt sich Kmail ruhiger und ließ sich fast (s.u.) normal bedienen. Die fälschlich verschobenen Mails habe ich dann wieder in ihre Ursprungsordner einstellen können.

Ich kann daher jedem, der größere Mailordner sein eigen nennt, nur raten, vor einem Umstieg auf das neue KDE und sein Kmail alle eingerichteten Filter zunächst mindestens zu deaktivieren, wenn nicht gar zu löschen – und sie erst im Nachheinein neu einzurichten.

Aber auch dann bereiten die lokalen Filter in Kmail noch weitere Probleme:

Im Gegensatz zu früheren Kmail-Varianten werden nämlich alle auf dem IMAP-Server für das Löschen markierte – aber im IMAP-System aus den Ursprungsordnern physikalisch noch nicht gelöschte Mails – erneut in den Mail-Ordnern von Kmail angezeigt (in grauer Schriftfarbe). Regeln zur Kompaktifizierung der IMAP-Ordner – sprich zu einem sofortigen Löschen von Mails in den IMAP-Ordnern auf dem Server – sind bei mir deaktiviert. Mails werden daher auf dem IMAP-Server bei Lösch- oder Verschiebe-Vorgängen in ihrem Ursprungsordner nur zum Löschen markiert. Die eigentlichen Löschungen laufen dann am IMAP-Server zwar periodisch, aber mit deutlichem zeitlichem Abstand. Das ist eine reine Vorsichtsmaßnahme, von der die User an ihren Clients (wie dem alten Kmail) normalerweise gar nichts mitbekommen.

Aus der Anzeige der zum Löschen markierten Mails in Kmail lässt sich schließen, dass Akonadi beim Filtern und Verschieben der Mails in neue Ordner also mitbekommt, dass die verschobenen Mails auf dem IMAP-Server noch im Ursprungsordner vorhanden sind – wenn auch mit geändertem Status. Nun wirkt sich das leider negativ auf die Filter in Kmail aus. Die Filter bewerten die markierten Mails offenbar als neu eingegangene (möglicherweise wegen der Statusänderung) und filtern sie deshalb auch erneut. Obwohl sie ja schon früher behandelt und in andere Ordner verschoben wurden. Und das setzt sich dann so fort ….

Ergebnis:
Nach einigen periodischen Abgleichen zwischen Akonadi und dem Imap-Server wächst der Inhalt in Trash oder Spam-Ordnern linear an. Mit immer den gleichen Dateien. Das ist im Produktivbetrieb ein Desaster. Als Anwender kann man hier das Gesamtsystem nur so einstellen, dass bei der Löschung/Verschiebung einer Mail aus einem Ordner durch eine Kmail-Aktion auch eine sofortige Löschung der Mail in ihrem Ursprungsordner auf dem IMAP-Server vorgenommen wird. Das ist zumindest riskant. Oder man muss die Filter um sehr spezielle Einstellungen und Kriterien erweitern – was man vom normalen User nicht verlangen kann.

Die Lösung aus meiner Sicht wäre eine andere Behandlung von Mails, die auf dem IMAP-Server zum Löschen markiert sind, in Akonadi wie in der Anzeige und den Filter-Routinen von Kmail.

In der jetzigen Form ist das Kmail/Akonadi-Verhalten im Zusammenspiel mit IMAP-Servern zwar schon erstaunlich stabil und auch die Migration der Mailordner zu Akonadi-Ressourcen funktioniert im Kern schon richtig. Aber die Behandlung von Mails, die aufgrund von Client-Aktionen auf den IMAP-Servern zum Löschen vormarkiert werden, muss für den produktiven Einsatz geändert werden.

Hinzu
kommt ein weiteres Problem, dessen Ende ich auf meinem Versuchssystem noch nicht absehen kann. Mindestens am ersten Tag der Umstellung fraß der “virtuoso-d”-Prozess mit führendem Abstand die allermeiste CPU-Zeit auf meinem System (in Form von nice-Last). Ursache ist die Indizierung von Mails durch Nepomuk mit Virtuoso als Backend (virtuoso-t ist wohl ein zugehöriger Datenbank-Prozess).

Dabei war die Konkurrenz um die Prozessorzeit keineswegs gering – auf zwei von 4 CPU-Cores habe ich andauernd unter VMware auf einem virtuellen Windows-System gearbeitet. Normalerweise würde VMware die meiste CPU-Zeit beanspruchen. Bei KDE 4.6 Beta war es bislang aber der Prozess “virtuoso-d”. Er verbrauchte doppelt soviel CPU-Zeit wie VMware – und zwar im bereich mehrerer Stunden. Das ist wirklich viel!

Ob das daran liegt, dass ich Gigabytes an Mails habe, vermag ich im Moment nicht zu sagen. Ich hoffe jedenfalls noch, dass “virtuoso-t” nach vielleicht weiteren 12 Stunden endlich Ruhe gibt. Im Moment ist er immer noch fleißig am Werkeln. Fairerweise muss ich sagen, dass vituoso-t sich auf einen Prozessor-Core beschränkt und nach ersten Eindrücken auch nur dann so richtig aktiv wird, wenn tatsächlich noch CPU-Zeit verfügbar ist. Na ja, wir werden sehen, ob die Nepomuk- Indizierung auch mal zu einem Ende kommt. Insgesamt ist das Ganze aber in Indiz dafür, dass man Virtuoso oder aber das Zusammenspiel von Akonadi und Virtuoso ggf. noch effizienter machen muss.

Im Moment würde ich wegen der geschilderten Erfahrungen noch niemanden raten, auf produktiven Systemen auf das neue Kmail umzusteigen.

Zu Punkt 3 – Korganizer, Kadressbuch, OX5:

Das funktioniert im Moment schlicht und einfach nicht. Die Einrichtung von Kalendern als Teil einer OX5-Verbindung zu Kontakt scheitert. Einen entsprechenden Bug habe ich eingestellt. Das ist für mich im Moment übrigens der Hauptgrund, bei KDE 4.5.3 zu bleiben.

Auf einige Ungereimtheiten beim Umgang mit dem OX5-Adressbuch mag ich hier nicht mehr eingehen. Das läuft zwar als Relikt aus 4.5.3 zwar irgendwie, aber dennoch habe ich den Eindruck, dass die zugehörige Akonadi-Ressource nicht wirklich migriert wurde. Denn wenn ich auf die Eigenschaften der entsprechenden Akonadi-Resource zum OX5-Adressbuch gehe, öffnet sich ein Dialog zur Migration – in dem leider Open-Xchange gar nicht als Alternative erscheint. Womöglich arbeitet das “übernommene” Adressbuch also auf einer alten, nicht upgedateten Akonadi-Resource, die keine Verbindung zum OX-Server mehr aufweist. Bin im Moment aber zu faul, mir das genauer anzusehen.

Fazit:

Interessant war es schon, Akonadi nun mal im breiten Einsatz für Gigabytes an Mail zu sehen und nicht nur als Quelle für simple und in der Anzahl überschaubare Adressbuch-Daten. Im Kern funktioniert das schon. Bis auf “Kleinigkeiten” wie die Anzeige von zum Löschen markierten Mails des IMAP-Server und die Behandlung von Filteraktionen für solche Mails.

Ich bin daher sehr gespannt, wie sich KDE 4.6.Beta 2 bzw. der Release-Kandidat präsentieren werden. Im Moment ist Kontact KDE 4.6 in unserem Arbeits-Umfeld jedenfalls noch nicht reif für den produktiven Einsatz. Was ich bei einer ersten Beta-Version auch keinesfalls überbewerten will, sondern als normal ansehe.

Nachtrag: Problem mit der FROM-Adresse

Gerade macht mich meine Frau darauf aufmerksam, dass Mails, die ich von meiner Testinstallation verschicke, eine leere FROM-Envelope-Adresse aufweisen. Dies geschieht seit der Installation der letzten Kmail-RPM-Variante 4.5.80-261.2 vom Opensuse Factory-Repository unter KDE 4.6 Beta. Obwohl alle notwendigen Daten in der Kmail-“Identität” gepflegt sind. Na ja, Beta halt ……