Traumtyp Phing
Kommentare

Den Task das Laufen lehren
Eine Buildfile (Listing 4) läuft jetzt zwar schon fehlerfrei, jedoch müssen wir unseren Task noch mit Leben füllen. Das geschieht in der main-Methode, die selbstverständlich

Den Task das Laufen lehren

Eine Buildfile (Listing 4) läuft jetzt zwar schon fehlerfrei, jedoch müssen wir unseren Task noch mit Leben füllen. Das geschieht in der main-Methode, die selbstverständlich public ist. Sie wird immer aufgerufen, wenn der Task ausgeführt werden soll. Innerhalb der main-Methode wird zuerst überprüft, ob ein executeable gesetzt ist und ob entsprechende FileSets angelegt wurden. Ist das nicht der Fall, so werfen wir eine BuildException mit einer entsprechenden Fehlermeldung aus. BuildExceptions führen zu einem sofortigen Abbruch des Builds und einer Ausgabe der entsprechenden Fehlermeldung. Selbiges lässt sich auch durch den Fail-Task innerhalb der Buildfile erreichen. Nachdem wir somit sichergestellt haben, dass alle wichtigen Werte gesetzt sind, bauen wir unser Kommando anhand des gesetzten executeable und der Argumente zusammen, über die wir iterieren und deren Werte wir uns zurückgeben lassen. Komplizierter ist es über die FileSets zu iterieren: Jedes FileSet steht hier für ein Set von Regeln, um Dateistrukturen abzubilden – also muss jedes auch separat behandelt werden. Für jedes wird ein DirectoryScanner geholt, wobei eine Referenz auf das aktuelle Projekt übergeben wird. Anhand dieser Referenz werden Verweise auf schon bestehende FileSets aufgelöst. Von diesem DirectoryScanner können nun mit der Methode getIncludedFiles alle hinzugefügten Dateien geholt werden. Für uns an dieser Stelle nicht wichtig, jedoch im Hinterkopf zu behalten, ist die Methode getExcludedFiles, die alle nicht ausgefilterten Dateien zurück gibt. Als Letztes beschaffen wir uns noch das Verzeichnis als absoluten Pfad, in dem wir gerade aktiv sind, wobei wir auch hier wieder eine Referenz auf das Projekt übergeben. Nun sind alle Voraussetzungen erfüllt, um über die vorher geholten Dateien zu iterieren und auf jeder das zusammengebaute Kommando auszuführen.

Unser Task lernt sprechen

Da der Informationsgehalt, welche Datei gerade bearbeitet wird, für den Nutzer gegen Null geht, kümmern wir uns um zusätzliche Ausgaben, wenn der Parameter verbose gesetzt ist. Das geschieht mithilfe der log-Methode, die jeder Projektkomponente eigen ist. Hier wird neben der Nachricht, die geloggt werden soll, der Typ angegeben. In unserem Fall ist das der Parameter MSG_VERBOSE. Weitere Möglichkeiten sind MSG_DEBUG, MSG_INFO, MSG_WARN und MSG_ERR, die verschiedene Ausgaben ermöglichen. So können zum Beispiel Ausgaben vom Typ MSG_DEBUG nur angezeigt werden, wenn die Buildfile mit dem Kommandozeilenparameter -debug aufgerufen wird. Jede Rückgabe, die wir von einem ausgeführten Kommando erhalten, hängen wir an die Klassenvariable output an, sodass wir später alle Rückgaben aggregiert zurückgeben können.

Genau das tun wir, jedoch nicht per Kommandozeilenausgabe; es dient uns nur als Fallback. Der noch ungenutzte Parameter für den Apply-Task ist die returnProperty. Sie enthält einen Variablennamen, in dem die Ausgabe gespeichert werden soll. Zu diesem Zweck kann im Projekt, erreichbar über die vererbte Klassenvariable project, mit setProperty eine Variable gesetzt werden, die als ersten Parameter den Variablennamen und als zweiten dessen Wert enthält. Als Wert übergeben wir einen String, der alle Ausgaben als durch Semikolon getrennte Liste enthält. Über eine solche Liste kann mit dem foreach-Task innerhalb der Buildfile iteriert werden. Auf die soeben gesetzte Variable kann nun innerhalb der Buildfile beliebig zugegriffen werden, etwa um deren Inhalt mittels des echo-Tasks auszugeben, wie in Listing 4 zu sehen ist.

Listing 4
${cat.results}

Ein letzter Schritt, um für unsere Mühen belohnt zu werden, fehlt jedoch noch: Innerhalb der Buildfile muss der eigene Task bekannt gemacht werden. Dafür kann es notwendig sein, den includepath um den Ablageort der eigenen Tasks zu erweitern (Listing 4, Zeile 3). Die darauf folgende Zeile bedient sich des taskdefinition-Task, um den eigenen Task innerhalb der Buildfile bekannt zu machen. Von nun an kann er ohne Umstände verwendet werden.

Fazit

Phing lässt sich extrem schnell erweitern, jedoch mangelt es an Dokumentation, wie man eine solche Erweiterung implementiert. Dieser Artikel erleichtert hoffentlich den Einstieg in eben jene Erweiterung von Phing, die es für PHP-Entwickler, die sich nicht extra mit Java beschäftigen wollen, gegenüber Ant auszeichnet. Neben den hier angerissenen Themen gibt es für den interessierten Phing-Fan noch einiges zu entdecken. So können eigene Mapper implementiert werden, um Dateien während eines Kopiervorgangs zu transformieren, mit Filtern werden Ersetzungen in ganzen Dateistrukturen ermöglicht. Langeweile dürfte bei der Beschäftigung mit dem Phing-Framework also kaum aufkommen.

Alberto Assmann ist seit 2010 Auszubildender zum Fachinformatiker für Anwendungsentwicklung bei der Mayflower GmbH. Aus persönlichem Interesse heraus kann er bereits auf eine fünfjährige Erfahrung mit PHP zurückgreifen. Der Einsatz von Tools zur Optimierung der täglichen Arbeit ist ihm ein besonders Anliegen.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -