mepeisen

Zur Kommunikation hatte ich das bereits im Blick. Generell natürlich das eigene eMail-Konto, aber auch öffentlich verfügbare eMail-Konten. Dan könnte man beispielsweise einfach seine eigene InBox und IMAP-Ordner einblenden. Und ist die eMail von öffentlichem Wert, zieht man sie in einen IMAP-Ordner unterhalb des Projektes bzw. einer Version, welches mit dem öffentlichen Konto verknüpft ist. Damit wird es logischerweise öffentlich verfügbar. Nur als Beispiel-Realisierung. Wie das ein Plugin löst, sei mal dahin gestellt.

Was mir just durch deinen Post durch den Kopf geht, Nikosch: Das Ableiten von Aufgaben/Tätigkeiten (sei es Bugs oder was weiß ich) aus ebend jenen eMails. Oder allgemeiner gesprochen: Ableiten von Aufgaben aus einem Objekt heraus. Da muss ich mal schauen, was Maven alles ermöglicht.

Natürlich bleibt da die gesamte Kommunikation ausserhalb eMails noch offen. Chat-Sessions, Skype-Sessions usw. Idealerweise sollte das auch in der Projektakte dokumentiert werden, also aufgezeichnet werden. Gespräche im Büro am besten auch. Big Brother JUHU Ich zapfe die Matrix an

Nachtrag: Im Ernst. Als Fallbeispiel denke ich ernsthaft daran, alles an Kommunikation auszuzeichnen und in der Projektakte abzulegen. Wie das in der Praxis durch welche Tools geschieht, sei mal offen. Nicht für jedes Planbeispiel werde ich automatisch ein Plugin schreiben.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Mister Ad

mepeisen

Hier mal meinen aktuellen Ansatz, weil ich irgendwo einsteigen muss. Ich male das demnächst auch in UML auf, dass es etwas klarer wird.

Zunächst als Einstiegspunkt das Projekt-Repository. Das legt im Prinzip bereits das Set aus Plugins fest, das zur weiteren Verwaltung benötigt wird. Das Repository wird formal über einen String identifiziert. Beispielsweise könnte ein rein auf SVN basierendes Repository der normale SVN-Connection-String sein (svn://......).

Jedes Projekt wird anhand einer ID identifiziert und kann vom Projekt-Repository aufgelöst werden. Das SVN-Repository würde dazu beispielsweise einfach nach einem Verzeichnis suchen, das so heisst. Bei der ID tendiere ich nach der Mimik von Maven, also <group-id>:<artifact-id>:<version>
Beispiel: org.mycompany:myproject:1.0.5
Es gibt ein Root-Projekt, sozusagen der formale Einstiegspunkt, was auch per Definition immer die Version 1 ist (fachliche Definition, keine technische Restriktion). Dennoch kann jedes Projekt als Einstiegspunkt verwendet werden und "ausgecheckt" werden. Auschecken meint zunächst nur das Einhängen des Projektes in einen Eclipse Navigationsbaum, um sich die Projektstruktur anzuschauen.
Ein reiner Entwickler interessiert sich evtl. nur für ein konkretes Projekt. Ein Release-Manager eines aus mehreren Projekten bestehendes Software-Produkt hat einen höheren Einstiegspunkt.

Jedes Projekt beinhaltet n Projektelemente. Projektelemente können normale Elemente aus Sicht eines Dateisystems sein oder auch Kind-Projekte oder Kind-Versionen.
Versionen können die Eigenschaft "gefroren" haben, was man bei festen Versionen (=Tags, tote/erledigte Branches) nehmen würde. Aktive Versionen sind Weiterentwicklungen, Branches usw.
Theoretisch könnte ein Projekt-Repository auch Elemente einführen, die nicht in die obige Auswahl passt. Beispielsweise eMails von einem eMail-Konto. Jedes Plugin muss damit zurecht kommen, dass es auch auf unbekannte Elemente treffen könnte.

An jedem Projektelement gibt es Features. Dies sind über eine ID und einen Config-String verwaltete "Teile". Im Prinzip soll dies ein allgemeingültiger Weg sein, Optionen zu realisieren oder Templates. Wenn beispielsweise ein eMail-Plugin in ein Projekt gehangen wird, muss es dem Eclipse auch mitteilen, dass nun die eMails im Baum anzuzeigen sind. Dazu wird das Basis-Plugin nun beispielsweise alle Features abfragen, ob diese gerne für Eclipse Elemente in den Projekt-Baum hängen wollen. Wenn Ja, kann dann das Plugin die eMails einhängen.
Über diesen Weg lassen sich weitere Dinge sehr gut realisieren. So kann beispielsweise beim Anlegen eines Kind-Projektes das Eclipse die Features durchgehen und findet eines, was sich zuständig fühlt und was in diesem Zug beispielsweise einen Bugtracker konfiguriert.

Jetzt wird auch klar, wie ich das Wunsch-Verzeichnislayout oder das Einbinden von neuen Optionen planen will. Das habe ich bereits am eMail-Beispiel erklärt oder am Beispiel des Bugtrackers. Weiteres Beispiel. Gerne genommen sind Templates für Word-Dokumente o.ä. (Pflichtenheft, Fachkonzept, Rechnung, was weiß ich). Nun kann das Basis-Plugin die Features abklopfen und fragen: Habt ihr eine Option für das "Neue-Datei Menü" auf diesem Verzeichnis, das angeklickt wurde. Eines der Features erklärt sich zuständig und bietet an "Neue Rechnung erstellen". Klickt der User drauf, wird das Feature dann tätig. Wo auch immer es die Vorlage hernimmt und was auch immer es dann tut.
Ein weiteres Beispiel: Ein Feature hat nur die Aufgabe einen Link zu einem Web-Forum anzubieten. Es bindet nun einen Eintrag in den Projektbaum an, bei dem einfach ein Web-Icon mit Beschriftung "Forum" angezeigt wird. Als einziges Menü gibt es öffnen, was dann ein Browser-Fenster öffnet und die korrekte URL dabei nutzt.

Das bedeutet im Umkehrschluss: Es muss neben der technischen Unterstützung in Eclipse auch Möglichkeiten geben, über Features Standard-Aktionen anzupassen. Das ist mein aktuelles Problem, vor dem ich noch etwas stehe. Ich muss also die einzelnen Anwendungsfälle so umsetzen, dass sie in der Oberfläche reinpassen und ich muss sie so umsetzen, dass es nicht überfrachtet wird. Zwei Arten von Features sind dann relevant: Ein Typ, der die Oberfläche um neue Aktionen bereichert (Siehe Beispiel "Neue Rechnung"). Kriterium wann es das tut ist das Element, an denen das Feature konfiguriert wurde. Und ein Feature, was die Aktion anpasst und ggf. steuert (Siehe Beispiel Bugtracker zum Release einer Version).

Die Aufgabe des Eclipse-Plugins ist nun, einen Provider anzubieten, der dafür sorgt, Features wieder als Objekte zu erstellen (anhand des Config-Strings beispielsweise das eMail-Konto und den verwendeten IMAP-Folder wieder herstellen). So kann man allgemeine APIs anbieten, die Features konfigurieren und persistent im Repository pro Datei/Verzeichnis/Version/Projekt einbinden. Die Implementierung der Features und die Implementierung der Repositories ist damit so weit wie möglich unsichtbar. Und auch die Frage, wie kommt ein Feature an ein Objekt, ist unsichtbar. Entweder das Repository tut dies einfach (eine entsprechend spezialisierte Web-Lösung beispielsweise), weil sie ein Template verwendet. Oder ein Plugin bietet ein Command an, was dies dann tut.

Auch ein weiterer Anwendungsfall ist damit möglich: Das strukturelle Verändern des Projektes. Ein Feature könnte sich zuständig fühlen, einen Versions-Build durchzuführen. Es ist so implementiert, dass es dazu ein PHP-Script aufruft und die Änderungen anschließend commited. Klingt einfach. Aber das PHP-Script ist Teil eines komplexen bereits existierenden Build-Systems, was die Versionsnummer in eine Config-Datei schreibt, eine ZIP-Datei erstellt und per FTP auf den Webserver des Unternehmens lädt und was die Release-Notes per Newsletter verschickt.


Ich halte das System für relativ flexibel. Es lässt beliebige Schachtelungen von Projekt/Version zu, um so den fachlich gewünschten Ansatz zu unterstützen. Es hat eine klare Schnittstelle für Eclipse (die Features und das Projekt-Repository) und es kapselt alle Funktionalitäten. Bisher habe in der Tat keinen Anwendungsfall und kein Projektlayout gefunden, was sich damit nicht umsetzen ließe. Es ist nichtmal auf PHP beschränkt. Natürlich steckt der Aufwand darin, erst einmal die verschiedenen Komponenten, die in so einem Projekt stecken, als Feature zu realisieren. Also die Anbindung an Maven und Mylyn, an den BugTracker, eines, was vorbereitete PHP-Scripte bei Aktionen ausführt usw.

Die Frage ist nun, wieviel Logik ziehe ich in die Standard-Realisierung und wieviel in Features.

Im Extremfall kann das Basis-Plugin exakt nichts. Und jeder kleiner Befehl (Anlage eines Unterprojektes) ist eine Aktion, die per Feature realisiert werden muss und dazu die Api nutzt. Das hat den Vorteil, dass diese Ecken im Extremfall komplett austauschbar sind. Des weiteren hat es den Vorteil, dass alle Features, die nur auf solche Aktionen horchen, auf nahezu jede Aktion horchen können und sich einklinken können. Auch hier habe ich Anwendungsbeispiele: Ein Feature macht nichts anderes als vor der Projektanlage eine Namenskonvention zu prüfen. Ist diese verletzt, wird ein Veto geworfen.
Klingt einfach, ist aber bei vielen Unternehmen gang und gäbe, solche Restriktionen formal einzuführen.


So, genug geschrieben für heute, ich werde bis zum Wochenende nochmal meine Gedanken hierbei sortieren

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih