PINC-Blog » Trac

Trac-Themes

Rob — Thu, 28 Jan 2010 21:38:12 +0000

2 Jahre ist es jetzt in etwa her, dass ich einen Artikel über Eigene Templates in Trac geschrieben habe. Seitdem ist ein wenig passiert. Diesen Änderungen möchte ich hiermit Rechnung tragen. Ich habe das ganze Trac-Themes genannt, weil es weniger um Templating an sich gehen soll, sondern eher um eine Möglichkeit gemeinsame Styles festlegen zu können.

Leider ist es mit Trac immer noch nicht möglich unter einem Environment mehrere Projekte bzw. Repositories laufen zu lassen. Darum wird für jedes Projekt eine eigene Trac-Umgebung angelegt. Wichtig hierbei ist insbesondere für Firmen, dass alle Projekte zumindest in der Grundstruktur gleich aussehen und die Firmenfarben tragen.

“… was bisher geschah”

Wer zuerst probieren will, wie und was er alles anpassen kann, sollte sich das Verzeichnis templates unterhalb seiner Trac-Umgebung anschauen. Standardmäßig liegt dort die Datei site.html. Wenn man sie das erste Mal aufmacht, kommt sie sehr unscheinbar daher, denn wie man sieht, sieht man nichts. Nur einen html-Tag und ein paar unbekannt anmutende Python-Attribute.
Auf der Seite http://trac.edgewall.org/wiki/TracInterfaceCustomization ist glücklicherweise bereits ein Beispiel-Code für den Inhalt dieser Datei. Für jene, die gerne lieber mehrere Dateien nutzen wollen hier gleich die Anpassung mit Einbindung externer Dateien:



  
  
    ${select('*|comment()|text()')}
    
  

  
    
    
       
         
       
    

    ${select('*|text()')}

Interessanterweise funktioniert das einfache Anlegen einer site_header.cs und site_footer.cs nicht immer – bzw. bei mir hat das noch nie funktioniert -, wie es auf manchen Seiten beschrieben wird.
Mit diesem Grundgerüst ausgestattet lässt sich schon anfangen herumzuspielen. Für weiterführende Informationen zu Genshi und Clearsilver – den Engines im Hintergrund – sei auf folgende Seiten verwiesen:

Neue und alte Freunde

Ein altbekannter Helfer beim Erstellen von Templates ist auch in der Version 0.11.5 noch vorhanden. Der Konfigurationsparameter template_dir.

[inherit]
template_dir=

Mit diesem Parameter lässt sich das Verzeichnis für die Templates festlegen und wodurch verschiedene Seiten mit ein und demselben Template ausgestattet werden können.

Daneben ist ein neuer Freund dazugekommen der Parameter htdocs_location. Mit diesem Parameter werden alle internen URLs, die mit “common/” beginnen in die URL umgeschrieben, die als Wert angegeben wurde.

[trac]
htdocs_location=http://localhost/mytemplate

Führt, dazu, dass aus

folgendes wird

Achtung! Leider hat die Sache einen Haken. Eigene Links aus der site.html werden nicht übersetzt. Der folgende Code

${href.chrome('common/style.css')}

wird nur in "/trac/templating/chrome/common/style.css" umgewandelt, aber nicht weiter.

Wichtig ist außerdem zu beachten, dass htdocs_location nur für statische Inhalte, wie Bilder, JavaScript- und CSS-Dateien gedacht ist. Templates werden nicht automatisch von dort erkannt. Diese müssen explizit über template_dir konfiguriert werden. Leider ist es hier nur möglich lokale Verzeichnisse zu setzen. Wer z.B. versucht eine Internetadresse anzugeben, bekommt zwar keine Fehlermeldung, wird aber mit einem Standard-Template “belohnt”.

Abschließend möchte ich sagen, dass – gefühlt – wesentlich mehr über die trac.ini konfigurierbar ist, als es noch vor 2 Jahren der Fall war. Das macht definitiv Lust auf mehr, aber dennoch bleibt das ein oder andere noch zu tun.

Und plötzlich war alles dunkel …

Rob — Sat, 14 Nov 2009 09:40:03 +0000

Ich weiss nicht, was passiert ist, aber nach dem Upgrade von Ubuntu auf 9.10 wurden diverse Entwickler-Tools unbenutzbar. Dabei handelt es sich insbesondere um Anwendungen, die nicht direkt aus dem Ubuntu-Repository stammen. Im Folgenden will ich auf Eclipse und Trac eingehen.

Eclipse 3.5

Nachdem auf GTK+ 2.18 aktualisiert wurde, funktionieren diverse Buttons in Eclipse nicht mehr. Schnell wird man dank Google auf der Suche nach einem Fix bzw. Workaround fündig (Migrating to client-side windows). Offensichtlich ist die Umgebungsvariable GDK_NATIVE_WINDOWS für das Problem verantwortlich. Diese muss auf den Wert true gesetzt werden, damit SWT-basierte Java-Oberflächen (Anmerkung: auch andere Java-Applikationen mit SWT haben das Problem) wieder in altem Glanz erstrahlen.

#!/bin/bash
env GDK_NATIVE_WINDOWS=true /eclipse

(Den Pfad bitte an das jeweilige Installationsverzeichnis von Eclipse anpassen.)

Leider ist dies nur ein bescheidener Workaround, denn sobald man Eclipse aus sich heraus neu startet (z.B. nach Upgrades oder Plugin-Installationen) existiert das alte Problem wieder. Genauso, wenn man den Workspace versucht zu wechseln, da sich Eclipse auch hier herunterfährt und neu startet.

Ein richtiger Fix ist für die Version 3.5.2 angedacht bzw. soll in der 3.6 schon integriert sein, welche für die SDK-Variante bereits existiert. Nur für JEE-Developer wird es wohl noch etwas dauern.

Von einem globalen Umsetzen der Variable GDK_NATIVE_WINDOWS wird an diversen Stellen explizit abgeraten. Hier sei aber anzumerken, dass die Eclipse-Installation aus den Ubuntu-Repositories genau das macht. Für alle, die etwas “wagemutiger” sind hier das Startskript mit export.

#!/bin/sh

# work around e#290395 / LP: #458703
export GDK_NATIVE_WINDOWS=true

xuldir=/usr/lib/xulrunner-$(/usr/bin/xulrunner-1.9.1 --gre-version)
LD_LIBRARY_PATH=$xuldir${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} /eclipse
 "$@"

(Den Pfad bitte an das jeweilige Installationsverzeichnis von Eclipse anpassen.)

Dieses Skript am besten unter /usr/local/bin als eclipse ablegen und alle Links, die vorher direkt auf die Eclipse-Startdatei gegangen sind auf dieses Skript umbiegen.

Trac

Interessanterweise – was die primäre Motivation für diesen Kurzkommentar war – hat es auch das Bugtracking-Tool Trac erwischt. Zum Glück nicht so “heftig” wie Eclipse, aber dafür umso unverständlicher.

Ich habe lokal Trac mittels easy_install installiert gehabt. Nach dem Upgrade auf Ubuntu 9.10 erhielt ich plötzlich auf allen Trac-Seiten einen 500-Fehler. Nach kurzem Suchen fand ich in der error.log-Datei von Apache (Pfad unter Ubuntu: /var/log/apache2/error.log) folgenden Eintrag:

... [error] [client 127.0.0.1] ImportError: No module named genshi, ...

Warum das Modul plötzlich nicht mehr vorhanden war kann ich zum aktuellen Zeitpunkt nicht erklären, aber das war noch nicht das Ende.

Just in dem Moment wo ich mit

sudo easy_install Genshi

das entsprechende Modul installieren wollte, quittierte mir Ubuntu die Nachricht, dass easy_install nicht existiert. Ein kurzer Blick in Synaptic unter python-setuptools bestätigte die Vermutung, dass das Paket nicht installiert war. Ich möchte an dieser Stelle nicht ausschließen, dass es beim Upgrade in der Liste der zu deinstallierenden Pakete dabei war, aber dennoch ärgerlich. Also war auch hier nachinstallieren angesagt.

Zum Glück fügte sich dann alles sehr schnell. Das Genshi-Modul installierte sich ohne Probleme.

Abschließend musste noch der Workaround für einen Bug (http://trac.edgewall.org/ticket/7526) eingebaut werden. Einfach die compat.py im functional/tests-Ordner in testcompat.py
umbenennen und die compat.pyc in compat.pyc.old umbenennen oder gleich löschen.

Hudson und Grails am heimischen Herd

Rob — Wed, 12 Aug 2009 22:01:52 +0000

Nachdem sich verschiedene Projekte bei mir angesammelt haben und ich für jedes in der Regel ein entsprechendes Trac-Projekt angelegt habe, fehlte mir immer mehr die projektübergreifende Oberfläche.

Mit den Wochen und Monaten schwängerte sich mein Geist mit dem Gedanken sich an Trac “zu vergreifen” und selbst so eine Oberfläche zu schreiben. Zum Glück kam mir eine neue Anforderung in den Weg, die mir die Arbeit teilweise abnahm: der Wunsch eines Continuous Integration Systems – kurz CI.

Da ich schon gute Erfahrungen mit Hudson gemacht hatte, war die Entscheidung schnell getroffen das System auch für mich einzusetzen. Die Vorteile:

einfache Installation
Open Source
kostenfrei

Allerdings musste gewährleistet werden, dass man damit Grails-Projekte bauen kann. Schaut man in die Plugin-Liste schreit es einen förmlich an: “Hier bin ich. Ist total easy-schneasy. Machs einfach!”

Aber wie so oft bei so offensichtlichen Aktionen liegt die Tücke im Detail. Leider hören – wie so oft – die Tutorials im Netz bei der Hälfte auf und vermitteln einem das Gefühl, dass man zu doof für die IT-Welt ist. Deshalb möchte ich hier einfach meine Erfahrungen bei der Einrichtung von Hudson mit den Grails- und Trac-Plugin auf einem Ubuntu-System vorstellen.

System

Ubuntu 09.04
Tomcat 6 (aus den Ubuntu-Repository)
Trac (manuell installiert)
Grails 1.1.1

Anmerkung
Ob Trac jetzt manuell oder aus dem Repository installiert wurde, ist eigentlich egal.

Hudson

Als erstes ging es darum Hudson zu installieren. Zwar bietet Ubuntu auch hier an über eine kleine Erweiterung der Repositories Hudson als Daemon zu installieren, allerdings bin ich persönlich kein großer Freund davon. Deshalb Alternative: war-File downloaden und einfach im Tomcat deployen.

Achtung!!! Wenn man das macht, sollte man vorsichtig beim Neustart aus Hudson heraus sein. Die Applikation fährt interessanterweise den Tomcat runter, bekommt ihn aber danach nicht mehr gestartet.

Zwei Dinge muss man dabei beachten, die aber auch auf der Hudson-Seite dokumentiert sind.

die Variable HUDSON_HOME muss gesetzt sein – habe ich bei mir direkt in das Tomcat-Startskript geschrieben (Faulheit siegt)
Es müssen teilweise noch Verzeichnis-Rechte angepasst werden, damit Hudson korrekt läuft

Nachdem Hudson nun endlich sein Pracht im Browser präsentiert geht es weiter mit dem Grails-Plugin.

Grails

Die Installation von Plugins ist in Hudson sehr simpel – oder wie manch Web 2.0-Entwickler sagen würde: “kissy” (von KISS – Keep it stupid simple). Einfach Häkchen setzen und auf “Installieren” klicken. Wie schon erwähnt, kann es hierbei dazu kommen, dass Hudson den kompletten Tomcat versucht neu zu starten, was zumindest bei mir nicht funktioniert hat. Ggf. einfach den Tomcat manuell neu starten.

Nachdem das Plugin installiert ist, müssen noch einige Konfigurationen durchgeführt werden. Als erstes muss der “Grails Builder” in der globalen Konfiguration von Hudson angelegt werden. Hier kann man verschiedene Grails-Installationen angeben, was insbesondere durch die teilweise Inkompatibilität der Versionen von großem Vorteil ist. Da die Sache in zwei Textboxen geregelt wird, verzichte ich mal auf den obligatorischen Screenshot.
Hat man jetzt die notwendigen Installationen angegeben kann man sich gütlich an die Konfiguration des Jobs machen. Hier muss ich vorausschicken, dass ich bereits einige Jobs angelegt hatte.

Unter dem Punkt “Build Verfahren” kann man über den Button “Build-Schritt hinzufügen” ein “Build with Grails” anlegen. Dabei lassen sich verschieden Werte konfigurieren. Nach einigem Herumprobieren waren aber nur drei relevant:

Grails Installation (wurde eben in der globalen Konfiguration angelegt)
Targets
grails.work.dir

Die Targets kann sich jeder selbst aussuchen aus der Liste, die “grails help” ausgibt. Bei mir sind das "test-app -unit --non-interactive" war doc.
Wichtig ist allerdings vor allem der Parameter grails.work.dir!

Das Grails-Plugin erwartet standardmäßig, dass es Zugriff auf das Verzeichnis /usr/share/tomcat6/.grails besitzt um auf den scriptCache zugreifen zu können. Da dieses Verzeichnis aber nicht zwingend freigegeben werden soll, muss ein alternatives Verzeichnis über grails.work.dir gesetzt werden. Andernfalls müssen die Zugriffsrechte mittels sudo chmod -R 777 /usr/share/tomcat6/.grails gesetzt werden.
Das Projekt-Verzeichnis hat noch eine weitere Bedeutung. Wenn man z.B. in Subversion seinen Code unter “trunk” eincheckt und keinen expliziten Modulpfad angelegt hat, wird automatisch trunk als Projektname auch in Hudson beim Bauen verwendet. Nun kann man sich vorstellen, dass bei mehreren Projekten, die alle in “trunk” liegen dies zu einer Überschneidung führt, die nicht unbedingt erwünscht ist.

Nichtsdestotrotz, bin ich hiermit bereits an das Ende meiner Vorstellung gekommen. Nach der Konfiguration des Jobs einfach auf “Jetzt bauen” klicken und schauen was passiert – ich hoffe mal es funktioniert. Ansonsten: bitte nicht hauen, bei mir läufts

Trac

Für alle, die jetzt fragend dastehen und wissen wollen: “aber er hat doch was von Trac erzählt”. Ja, das habe ich und ja, auch das geht sehr einfach. Nachdem man das Trac-Plugin installiert hat, erscheint ein Eingabefeld in der Job-Konfiguration, in dem man einen Link zum Trac-Projekt hinterlegen. Nachdem man diesen gespeichert hat, erscheint ein simpler Menüpunkt auf der Job-Seite “Trac”, der zu der entsprechenden Trac-Seite führt.

Projektübergreifende Templates in Trac

Rob — Fri, 21 Mar 2008 05:42:43 +0000

Im Beitrag http://www.pincservices.de/wordpress/eigene-templates-in-trac
habe ich bereits vorgestellt wie man projektspezifische Designanpassungen machen kann bzw. wie die Projektliste in Trac anpassbar ist. Damals habe ich geschrieben, dass es scheinbar keine Möglichkeit gibt projektübergreifende Templates zu erstellen. Nun die frohe Kunde: Es geht doch.

Leider bietet Trac keine Möglichkeit über eine globale Variable das allgemeine Templateverzeichnis zu definieren. Man muss hierfür die trac.ini im Verzeichnis conf der jeweiligen Projektumgebung anpassen. In dieser Datei gibt es folgenden Abschnitt:

[inherit]
plugins_dir =
templates_dir =

Hier kann man das eigene Templateverzeichnis angeben, welches als Default verwendet werden soll.
Im Fall des Beispiels aus dem obigen Beitrag würde man den Eintrag

templates_dir = /home/testUser/trac/templates

setzen.

Eigene Templates in Trac

Rob — Sun, 16 Mar 2008 13:23:03 +0000

Wer bereits ein größeres Programmierprojekt durchgeführt hat, wird die Erfahrung gemacht haben, dass man auf ein Bugtrackingsystem nicht wirklich verzichten kann.
Im Beitrag 1:0 im Kampf JIRA vs. Trac habe ich schon zwei solche Systeme angesprochen JIRA und Trac, wobei ich hier auf letzteres eingehen möchte.

Nachdem man sich mit diversen Funktionen und Plugins in Trac “angefreundet” hat, stellt sich meistens die grundlegende Frage: “Wie kann ich das Design von Trac so ändern, dass es zu meinem Projekt passt”. Das fängt beim Logo an und hört bei der Anzeige der Projektliste auf – insofern man mehrere Projekte hat.

Trac bietet hierfür auf der eigenen Projektseite auch ein Tutorial, deshalb möchte ich hier nur eine kurze Einführung geben und dann auf ein paar Fallstricke bei der Individualiserung des Layouts eingehen, die in dem Tutorial nicht auftauchen. Auf das Ein- bzw. Ausblenden von Navigationspunkten oder die entsprechenden Verlinkungen wird hier nicht eingegangen.

Das Templatingsystem von Trac basiert auf Genshi, einer Pythonbibliothek, die es erlaubt Text aus diversen Quellen für das Web aufzubereiten. Trac bedient sich hierbei vor allem des HTML-Parsers.

In dem Verzeichnis trac/templates unterhalb des Trac-Installationsverzeichnisses befinden sich alle html-Dateien für das Default-Template. Insbesondere die layout.html und die index.html sind hier relevant. Die layout.html bestimmt das Aussehen der projektspezifischen Seiten und die index.html die Seite für die Projektliste. Unter trac/htdocs befinden sich die Bilder, Javascript-Dateien und die CSS-Dateien.

Trac bietet pro Projekt diverse Stellen zur Individualisierung des Designs an. Eine eigene site.html im Verzeichnis templates und ein eigenes Verzeichnis htdocs, in der eine style.css angelegt werden kann.

Um das Layout der Projektliste anzupassen sollte man folgende Zeile in die Konfigurationsdatei vom Webserver (z.B. die default von Apache) schreiben

SetEnv TRAC_ENV_INDEX_TEMPLATE "/home/testUser/trac/templates/index.html"

beim Setzen der Variable TRAC_ENV_INDEX_TEMPLATE muss darauf geachtet werden, dass sich das Verzeichnis templates nicht unterhalb des Elternverzeichnisses der Umgebungen (Environments) liegt. Wenn z.B. folgendes definiert ist

SetEnv TRAC_ENV_PARENT_DIR "/home/testUser/trac/"

kommt es auf der Seite für die Projektliste (definiert durch die index.html) zu einer Fehlermeldung, dass die Datei VERSION für das Projekt templates fehlt. Aus diesem Grund sollte die Variable TRAC_ENV_PARENT_DIR auf ein anderes Verzeichnis zeigen. Z.B.

SetEnv TRAC_ENV_PARENT_DIR "/home/testUser/trac/projects"

Nachdem diese Vorbereitungen getroffen sind, kann man daran gehen, die eigenen Templates zu entwerfen und umzusetzen.

Für projektspezifische Templates kann, wie bereits gesagt, die site.html verwendet werden. In dieser Datei ist vor allem der Ausdruck

${select('*|text()')}

relevant. Dieser wird in Verbindung mit

py:match="body"

verwendet und bedeutet soviel wie: “Nimm alle Subtags und jeden Text unterhalb vom Body-Tag”. Wenn man jetzt aber auf einzelne Elemente zugreifen möchte, z.B. nur den Content- oder den Main-Bereich, dann kann man folgenden Ausdruck verwenden:

${select('div[@id="main"]|text()')}

bzw.

${select('div/div[@id="content"]|text()')}

Der Ausdruck in der Select-Anweisung ist eine Untermenge von XPath (siehe hierzu Genshi XPath).

~~Leider bietet Trac scheinbar noch kein projektübergreifendes Templating an.~~

[Update]

Es gibt doch eine Möglichkeit. Siehe hierzu diesen Beitrag.

Weitere Informationen zum dem Thema befinden sich auf der Seite http://trac.edgewall.org/wiki/TracInterfaceCustomization, sowie ein Beispiel auf ~~http://querdenker.kicks-ass.org/trac/querdenker/wiki/TracTemplating~~.

1:0 im Kampf JIRA vs. Trac

Rob — Tue, 11 Mar 2008 20:50:36 +0000

Mal wieder ist es geschehen, dass eine kommerzielle Software Ã¼ber die OpenSource-Variante siegt. In diesem Fall aber (leider) zu Recht.

Die Entwicklung von Spring IDE wurde lange Zeit ausschlieÃŸlich mittels Trac realisiert. Zu meinem Bedauern haben sich die Verantwortlichen nun doch unter die Leitung von SpringSource gefÃ¼gt und betreiben das Bugtracking mit JIRA. Erreichbar ist die Seite von Spring IDE zwar immer noch unter http://www.springide.org und auch wird dort noch Trac verwendet, aber nur noch der Blog und das Wiki. Geht man auf Tickets, landet man direkt auf der JIRA-Seite.

Dieser Schritt ist allerdings auch verstÃ¤ndlich, da sich dadurch alle Spring-Subprojekte unter einem “Dach” vereint finden lassen.

Ein anderer Grund fÃ¼r den Schritt kÃ¶nnte auch die fehlende AttraktivitÃ¤t von Trac sein. Ein produktiver Einsatz ist nur bedingt mÃ¶glich, da bestimmte Elemente noch nicht vorhanden sind. Z.B. ist eine Administration bis Version 0.10 nur von der Konsole aus mÃ¶glich gewesen oder nachdem man das Webadmin-Plugin explizit hinzugeladen hat. AuÃŸerdem ist die Rechteverwaltung fÃ¼r grÃ¶ÃŸere Projekte – mit mehreren Teams / Entwicklern – noch relativ rudimentÃ¤r gehalten. Zwar wurden einige dieser Probleme bereits in der Version 0.11 gefixt, aber leider existiert diese bis heute immer noch als Beta (http://trac.edgewall.org/wiki/TracDownload).

Dennoch wache ich mit einem Auge Ã¼ber die Entwicklung von Trac und hoffe, dass ich bald frohe Kunde verbreiten kann.