Kategorien
PEAR und Eclipse
Da ich genau wusste, dass ich am Montag nach der PHP Unconference (das müsste heute sein) ziemlich platt sein werde, habe ich schon mal, schlau wie ich bin, einen Artikel vorbereitet. Warum erzähle ich euch das? Keine Ahnung, vielleicht haben sich ja einige schon auf meine Berichte der Konferenz gefreut und die muss ich jetzt leider enttäuschen. So genug Nichtigkeiten erzählt, ab zum Thema.
Eine Sache, die ich früher immer falsch gemacht habe, wenn es um Projekte in Eclipse bzw. PDT ging, war der Umgang mit allgemeinen Bibliotheken. Wenn ich auf meinem Webserver oder auch lokal z.B. PHPUnit Tests geschrieben habe, dann lagen die immer sehr nahe am Projekt und auch im selben Repository. PHPUnit liegt aber irgendwo anders, was auch Sinn macht, da viele Projekte dies nutzen. Dummerweise muss ich aber trotzdem meinem Eclipse sagen, dass es da ein PHPUnit irgendwo gibt, denn sonst kann ich nicht so schön von den Klassen ableiten, so wie ich das gerne hätte.
Früher, als ich noch der naive kleine Nils war – nein nicht der aus dem Radio – da habe ich einfach die Sourcen genommen und die mit in mein Projektverzeichnis geworfen. Ein svn:ignore drauf und fertig was das Ganze. Eclipse macht es einem da aber einfacher. Wir legen einfach ein neues Projekt an, das da heißt PHPUnit, bzw. PEAR. Der Pfad zu dem Projekt liegt dieses mal ausnahmsweise nicht im Workspace, sondern zeigt auf das PEAR/PHPUnit Hauptverzeichnis. Wäre jetzt ein super Augenblick für Screenshots, oder? Kommen sofort. 
Mit draufklicken wird es übrigens groß. Jetzt müssen wir PDT nur noch irgendwie erklären, dass das eine Projekt das andere nutzt. Denn Initial sind die beiden erstmal unabhängig voneinander, was ja nicht verkehrt ist.
Wie immer (wenn man weiß, wo man suchen muss) in Eclipse ist auch das Einrichten dieser Abhängigkeit ein Kinderspiel. Klickt einfach auf das Hauptprojekt und schaut euch die „Properties“ an. Dort auf „PHP Include Path“ gedrückt seit ihr schon fast am Ziel. Jetzt noch im Reiter Projects den „Add“ Button genutzt und das PHP Unit Projekt hinzugefügt. Wenn es am Ende dann wie in meinem Screenshot aussieht, dann sollte alles geklappt haben. Ihr könnt nur auch für die PHPUnit Klassen die Autovervollständigung und andere Features nutzen, als ob es ein großes Projekt wäre.
Das gilt natürlich auch für das Zend Studio für Eclipse.
Wenn ihr auch ein paar kleine Tipps für PDT habt, dann nur her damit. Vielleicht habt ihr ja ein paar Plugins, die es sich lohnt mal vorzustellen. Von mir werdet ihr auf jeden Fall in nächster Zeit noch ein wenig über die Verwendung von Templates hören.
Ach ja, eigentlich hat die Geschichte nicht so viel mit PEAR zu tun. Das ganze guilt natürlich für jede third party Bilbliothek, die nicht im Projekt liegt. Ich fand den Titel aber so schöner.
Also ich benutze nicht „Projects“ um andere Bibliotheken einzubinden sondern „Libraries“ und gehe dann auf „Add External Source Folder“.
Welches von beiden nun schöner ist darüber kann man bestimmt streiten. 🙂
Zend Studio for Eclipse hat schon alles für PHPUnit integriert – da muss man nichts mehr dem Projekt hinzufügen 😉
Wenn ich es mir leisten könnte, würde ich auch auf Zend Studio umsteigen 🙂 Aber klappt das denn so einfach? Ich meine, da gibt es doch die unterschiedlichsten Versionen. Oder meinst du die Integration in die IDE mit grün und rot?
Ich hab mal ne ganz generelle Frage .. Eclipse auf Windows? Ich mein, ich hab definitiv schon mal Software gesehen die länger zum Starten braucht, aber kann man damit wirklich arbeiten?
Mir ist beim Testen mindestens dreimal der Kopf auf die Tischplatte geknallt – und das ist nun wirklich kein Spaß 🙂
@Steffkes: Also ich kann sehr gut mit arbeiten. Natürlich kann man mit 1GB Speicher nicht weit kommen, aber wer hat das schon. Ich habe PDT und eine VM Ware gleichzeitig laufen und bei mir läuft alles wunderbar.
Weiterer Vorteil: Die Bibliotheken lassen sich ganz bequem per VCS auschecken und updaten.
@Nils: Grün und Rot gibt’s da so nicht. Man kann direkt per Assisstenten von einer Klasse einen Test Case erstellen lassen (mit leeren Methoden) – mal so als Beispiel. Alle UnitTests kann man über die IDE direkt ausführen und auch die Auto Completion funktioniert tadellos mit ZSfE.
@Steffkes: bei mir zu Hause auf WinXP mit 1 GB Speicher läuft das super! Hier auf der Arbeit mit Debian Lenny und 4 GB Speicher ist das ZSfE 7.0 64Bit (Testversion) eher ne Krücke … Ich hab aber keine Ahnung, warum das so ist. ZFfE 6.1.x 32Bit (Vollversion) läuft dagegen annehmbar schnell, aber nicht so schnell wie unter Windows.
Wußte garnicht dass das mit Projekten geht, mache das auch immer via Library und External Source. Dann kann man auch Autovervollständigen, auf Methodennamen klicken usw. Das einzige was dann nicht geht ist Suchen.
Dadurch hält man sich auch die Liste der Projekte übersichtlich. Wenn ich mir das noch aufblähe mit PEAR, ZendFramework, Chart-Lib, ez und und und, wirds irgendwann sehr voll. Man könnte dann natürlich für jedes Projekt nen eigenen Workspace erstellen, aber das finde ich auch unpraktikabel.
Wieso bindet ihr die „Bibliotheken“ denn gesondert vom Projekt ein und stellt sie vor allem nicht unter Kontrolle eurer Versionsverwaltung?
Auf den ersten Blick mag bspw. ein Zend Framework ziemlich Overhead sein, gerade wenn das Projekt selbst kleiner als das Framework ist. Aber auf der anderen Seite ist die Anwendung doch gegen die spezielle Framework-Version gebaut. D.h. wir haben eine Abhängigkeit.
Das ein Update einer verwendeten Bibliothek meine Anwendung brechen lassen, ist euch ja bestimmt allen bekannt. 🙂
Indem die Bibliotheken kein Teil des Projektes sind, nimmt man sich die Möglichkeit einfache Deployments zu bauen. Denn ist eine Lib Bestandteil des Projekts, kann ich bspw. nach jedem Checkin automatisch ein Checkout auf dem Testsystem fahren, welches automatisch Trunk darstellt ect.
Also:
Weswegen trennt ihr zwischen dem eigentlichen Projekt und den verwendeten Bibliotheken?