Mylar stoppt die Reizüberflutung in Eclipse, indem es

Mylar entstand als ein experimentelles Technologieprojekt der Eclipse Foundation. Mit der Release 1.0.0 im Dezember 2006 avanciert es zum beliebtesten Plugin auf EPIC (Eclipse Plugin Central, [1]). Näheres zur Geschichte weiß die Mylar-Webseite [2] zu berichten. Letztlich filtert Mylar Eclipse-Ansichten und zeigt dem Benutzer nur die Dinge, die er für sein Projekt benötigt, und hilft beim Wechseln zwischen Aufgaben. Die freie Software arbeitet bestens mit Bugtracking-Systemen zusammen.

Die zentrale Schaltstelle von Mylar ist die »Task List«-Ansicht (Abbildung 1). Hier gewinnt der Nutzer die Übersicht über seine Bugtracker-Queries samt Aufgaben und verwaltet sie. In Version 1.0.0 unterstützt Mylar Bugzilla [8] in den Versionen 2.18 bis 2.22, Jira [9] und Trac [10]. Für Web-basierte Bugtracker wie Sourceforge.net kennt Mylar eine generische Webschnittstelle, die mit Hilfe regulärer Ausdrücke Webseiten parst - Näheres dazu unter [11].

Abbildung 1: Die zentrale »Task List«-Ansicht, hier mit Queries für Bugzilla und Trac sowie einer lokalen Kategorie mit Aufgabe.

Drittanbieter stellen weitere Schnittstellen bereit. Alternativ lassen sich welche per Bugzilla beim Mylar-Team anfordern, eine Liste der geplanten Schnittstellen liefert Bugzilla unter [12]. Nach der Einrichtung des Bugtrackers kann der Benutzer neue Aufgaben aus Mylar heraus erzeugen und bestehende bearbeiten. Die verschiedenen Schnittstellen stellen ihre Aufgabeneditoren bereit, passend zum jeweiligen Bugtracker.

Fragestunde

Für den Abruf bestehender Aufgaben definiert der Benutzer über den Query-Wizard Abfragen für den Bugtracker. Abbildung 2 zeigt die Definition einer Query für Bugzilla. Die definierten Abfragen erscheinen als Kategorien in der Aufgabenliste, ein Kommando oder ein fester Zeitplan synchronisieren sie. Die einzelnen Aufgaben erscheinen als Unterpunkte der zugehörigen Kategorien. Aufgaben, die in keine bestehende Kategorie fallen, laufen entweder unter der Archivkategorie oder als Top-Level-Eintrag.

Abbildung 2: Definition einer Query über den Query Wizard für Bugzilla, um bestehende Aufgaben abzurufen.

Sobald der Nutzer eine Aufgabe aktiviert, zeichnet Mylar alle Benutzereingaben im Hintergrund auf, um darauf aufbauend die Oberfläche zu filtern. Aus diesen Eingaben berechnet Mylar eine Gewichtung für die angefassten Artefakte im Arbeitsbereich. Artefakte, die keine Gewichtung haben, blenden sich aus den Ansichten aus, solche mit einer starken Gewichtung hebt Mylar fett hervor. Die Gewichtung verringert sich im Laufe der Zeit, und Artefakte, die längere Zeit niemand angeklickt hat, verschwinden aus den Ansichten.

Abbildung 3 zeigt die Paket-Explorer-Ansicht während der Bearbeitung einer Aufgabe. Der Nutzer hat die Möglichkeit, Artefakte besonders zu gewichten, um sie in den Ansichten anzuzeigen. Mylar filtert standardmäßig die Paket-Explorer-Ansicht, die Navigator-, die Fehler-, die Gliederungs- und die Task-List-Ansicht. Der Benutzer kann die Filterung in diesen Ansichten je nach Bedarf an- und abschalten.

Abbildung 3: Die Paket-Explorer-Ansicht während der Bearbeitung einer Aufgabe. Die fett hervorgehobenen Klassen, Methoden und Felder haben eine starke Gewichtung, die schwächeren eine geringere. Artefakte ohne Gewichtung sind nicht zu sehen.

Immer der passende Editor

Neben den Ansichten verwaltet Mylar auch die Editoren. Beim Aktivieren einer Aufgabe öffnet Mylar die Editoren für die gewichteten Artefakte von sich aus. Steht ein Artefakt aufgrund seiner Gewichtung zum Ausblenden an, schließt Mylar den entsprechenden Editor automatisch. Schließt der Benutzer einen Editor, reduziert das die Gewichtung der darin angezeigten Artefakte. Besonders in großen Projekten macht sich das bezahlt. Denn der Benutzer sieht dann immer nur jene Artefakte, die der aktuellen Aufgabe entsprechen, und die gerade irrelevanten lenken ihn nicht ab.

Zur weiteren Verringerung der Informationsflut kann Mylar die Code-Komprimierung für die Editoren einschalten. Dann komprimiert Mylar alle gefilterten Codeblöcke und erweitert nur jene, die im aktuellen Kontext von Interesse sind. Damit Mylar weiß, welche Artefakte es wichten kann, müssen geeignete Resource-Bridges zur Verfügung stehen. Mylar enthält bereits Bridges für alle im Eclipse-SDK vorkommenden Typen: Java, JUnit, PDE- und Ant-XML.

Soll Mylar auch andere Artefakte filtern, benutzt es eine generische Resource-Bridge, die mit Files umgehen kann. Bei ihr beschränkt sich das Filtern allerdings auf das schlichte Ein- und Ausblenden der Dateien. Eine verfeinerte Filterung - wie beispielsweise bei Java auf Methoden- und Feldebene - gibt es nicht. Drittanbieter liefern hier bessere Resource-Bridges. Den Interessenten, die selber welche entwickeln möchten, sei [13] als Lektüre empfohlen. Eine Liste der geplanten Bridges kennt Bugzilla [14].