MicroAbstract4: Software-Entwicklung mit Eclipse

Software-Entwickler und -Produzenten sind in Zeiten von verteilter Entwicklung, beispielsweise durch Outsourcing ins Ausland oder durch Multi-Plattform-Projekte auf ein zuverlässiges und durchdachtes Entwicklungs-Instrument angewiesen. Für zahlreiche lokalen Tests und Produktionen sind Aufgaben wie Syntax-Highlighting und konfigurierbare Compiler von großem Interesse. Es sind zahlreiche Applikationen realisiert worden, die jedoch einzeln für sich gewartet, aktualisiert und den lokalen Gegebenheiten angepasst werden müssen. Diese Einzelaufgaben werden von sogenannten Integrated Development Environments, als (Applikations-) integrierten Entwicklungs-Umgebungen zusammengefasst und dem Entwickler als eine eigenständige Applikation zur Verfügung gestellt. Damit steht dem Software-Entwickler eine individuelle Umgebung zur Verfügung, in der Tests, Kompilierungen und zusätzliche Aufgaben durchführbar sind.

Die Firma International Business Machines Corporation (IBM) beschloss im November 2001 ihren Quellcode für den damaligen Nachfolger des IBM-eigenen Visual Age for Java freizugeben und für Entwickler zugänglich zu machen. Es folgte die Weiterentwicklung dieser Plattform, welche heute als Eclipse in der Version 3.4 vorliegt. Besondere Features von Eclipse als IDE sind sowohl die software-produzierenden, als auch die software-verwaltenden Sub-Applikationen. Zu den ersteren zählen diverse Editoren, die sich durch Syntax-Highlighting und Code-Folding beim Schreiben des Quellcodes als hilfreich erweisen. Hierbei wurde durch stetige Weiterentwicklung die Möglichkeit geschaffen, fast alle Programmiersprachen in Eclipse abzubilden. Desweiteren sind die Views und ein weiterer Grund für die weite Verbreitung und Annahme durch Entwicklerteams. Bei den Views handelt es sich um Oberflächen-Fenster, die per Drag-and-Drop an die persönlichen Vorlieben des Entwicklers angepasst werden können und somit ein individuelles Gestalten der Arbeitsfläche ermöglichen. Perspektives sind vollständige Benutzer-Konfigurationen einzelner Views zu einer Gesamt-Arbeitsfläche, die erstellt, gespeichert und wiederverwendet werden können. Zu den software-verwaltenden Sub-Modulen gehören die umfangreichen Plug-In-Bibliotheken, die dank der Architektur und des Open Source-Charakters der Eclipse-Plattform stetig größer werden. Darunter zählen Compiler für diverse Programmiersprachen, passende Interpreter und Präprozessor-Anbindungen. Code-Coverage steht dabei als neuer Schwerpunkt in der verteilten Software-Produktion, bei dem, trotz multipler Programmier-Stile und –Ansätze, eine einheitliche Test-Abdeckung und Code-Formatierung realisiert werden kann. Neben diesen Build-Modulen sind vor allem infrastruktur-spezifische Module, wie Views für Repositorys zur Anbindung an CVS- oder SVN-Proxys frei verfügbar. Implementierungen für Jira- und andere Ticketing-Systeme sind ebenso unterstützend für die Software-Entwicklung einsetzbar, wie Anbindungen an komplexe Build-Systeme wie Maven oder Ant.

Zusammenfassen lässt sich sagen, dass eine vollintegrierte Entwicklungsumgebung die Grundlage für eine Software-Entwicklung und -Produktion darstellt. Dabei stellen die individuellen Anpassungs-Möglichkeiten der Oberfläche ein wichtiges Kriterium neben funktionsintegrierten Modulen und Plugins dar. Die quelloffene Architektur ermöglicht eine Realsierung von eigenen Projekten auf Basis von Eclipse und des zugrunde liegenden OSCGi-Frameworks. Plugins und individuelle Erweiterungen sind dadurch uneingeschränkt programmier- und implementierbar.

MicroAbstract3: Software-Recyling und zentrales Management durch Repositorys

Wiederverwendbarkeit ist ein zentrales Thema in der Software-Entwicklung. Die Produktion von Quellcode ist ein wesentlicher Faktor bei der zeitlichen Planung eines Software-Projektes. Im Bereich Wartung und Fehlersuche wird ebenfalls deutlich, wie wichtig ein erreichbares Archiv für Software-Module wird. Desweiteren wird durch eine zentrale Verwaltung eine redundante Verteilung vermieden. Somit können Anpassungen einfacher und mit kürzeren Wartungszeiten durchgeführt werden. Gerade in größeren Software-Projekten mit mehreren Subprojekten und dazugehörigen Entwickler-Teams eignet sich ein lokales Repository auch als Proxy, welcher die Anbindung an einen entfernten Proxy verwaltet und im lokalen Cache häufig benötigte Code-Komponenten und Bibliotheken bereitstellt, sodass diese in kürzeren Zeiten von der Entwicklungsumgebungen eingebunden werden können. Das ist vor allem bei öffentlichen Repositorys unabwendbar, denn Entwicklung folgen in den meisten Fällen einem Zeitplan, der keine Verzögerungen durch häufig unzuverlässige öffentliche Proxys zulässt. Maven-Proxy ist ein Produkt der Firma Codehaus und wird in den meisten aktuellen Software-Projekten eingesetzt. Hauptaufgabe ist es, Software-Komponenten innerhalb eines Caches bereitzustellen. Sind diese im lokalen Cache nicht vorhanden, importiert Maven-Proxy die fehlenden Komponenten inklusive ihrer transistiven Abhängigkeiten von vorgelagerten Proxys. Sind diese dort auch nicht vorhanden, werden wieder die vorgelagerten Proxys konsultiert, bis die entsprechende Komponente gefunden ist, oder festgestellt wird, dass es sie nicht gibt. Maven-Proxy arbeitet als Stellvertreter für die lokalen Entwicklungsumgebungen und bietet somit auch die Möglichkeit einer Proxy-Kette für verteilte Umgebungen, wodurch Warte- und Anfrage-Zeiten wesentlich verkürzt werden.

Die Firma JFrog entwickelt aufgrund wachsender Anforderungen das System Artifactory, welches speziell für die Eigenschaften des Maven2-Buildsystems optimiert wurde. Es bietet hierfür drei wichtige Kriterien: Verbesserte Proxy-Anbindung an öffentliche Maven-Java-Repositorys gegenüber anderen Repositorys, optimiertes und verteilbares Caching und verbesserte Sicherheitsoptionen für das Deployment und die Webverwaltung. Ziel von Artifactory ist hierbei die Realisierung einer unabhängigen und robusten Umgebung für Maven2-Entwicklungen. Es greift dabei auf ein Java Content Repository zurück, welches ein vollindiziertes Repository erstellt. Die ajax-basierte Webverwaltung ermöglicht ohne Probleme den Import und Export aus und in andere Maven-Archive wie beispielsweise Maven-Proxy, was zu einer schnellen Verbreitung von Artifactory als Haupt- oder Backup-Repository in bestehende Entwicklungsumgebungen führte. Desweiteren unterstützt Artifactory multiple lokale Repositorys und kann mit Hilfe von LDAP auch in Domänen-basierten Computer-Pools mit einem Single-Sign-On eingesetzt werden. Die administrativen Rechte werden zentral über das Webinterface vergeben.

Ziel und Zweck eines Archivs für eine Software-Produktion ist die Bereitstellung von Komponenten. Das impliziert auch die Möglichkeit, eigene Komponenten in das Repository zu deployen. Somit wird es jedem Entwickler, sobald er in Artifactory mit den notwendigen Rechten administriert wurde, ermöglicht, Software an einem zentralen Punkt bereitzustellen, zu warten und zu erweitern. Benötigt anschließend ein anderer Entwickler die entsprechende Komponente, kann er sie beim zentralen Repository anfordern.

MicroAbstract2: Continous Integration in der Software-Entwicklung mit Continuum

„Je öfter, umso besser.“ Das ist der Grundgedanke von Continous Integration. Verbunden ist damit der Build aus den Quell-Dateien und das anschließende Deployen auf Integrations- und Testumgebungen. In den Strukturen heutiger Software-Projekte ist eine fortlaufende Produktion und damit ein geschlossener Build-Zyklus ein wichtiges Kriterium für die Auswahl der Entwicklungsumgebungen. Neben den Aufgaben des Software-Architekten, sind vor allem die Konzeptionierer, Programmierer und Tester auf einen geschlossenen Kreislauf der Software-Entwicklung angewiesen. Geschlossene Software-Entwicklung bedeutet in diesem Zusammenhang, den Build eines Software-Projektes anzustoßen, sobald die Entwickler ihre Änderungen eingecheckt haben. Permanente und zeitnahe Integration basiert dabei zu großen Teilen auf dem Vorhandensein eines Versionierungs- und Repository-Systems, das von den Entwicklern für das Projekt (und die Subprojekte) benutzt wird. Im Gegensatz zum oft noch eingesetzten „Nightly Build“ ist Continous Integration nicht auf die Nachtstunden angewiesen, wenn alle Programmierer ihren Code in das Repository eingecheckt haben. Der Vorteil von permanenten und zyklischen Build- und Test-Prozessen besteht in der Früherkennung von Software-Fehlern und Integrationsschwierigkeiten von Subkomponenten und Projekt-Modulen. Somit werden Fehler unmittelbar nach dem Einchecken des Programmierers beim Build deutlich und können zeitnah behoben werden.

Die Apache Software Foundation (ASF) bietet Entwicklern mit dem Open Source System Continuum eine Plattform für Continous Integration. Es handelt sich dabei um eine Serversoftware, die für Enterprise-Lösungen konzipiert und optimiert ist. Neben den zweckgebundenen Aufgaben von Continous Integration, wie automatisierte Builds, einem Release-Management und rollenbasierter Webverwaltung, bietet es vor allem eine Integrations-Möglichkeit für die verbreiteten Build-Tools Apache Ant und Apache Maven1/Maven2, sowie eine Unterstützung für Shell-Scripts. Continuum bietet sowohl kleinen, als auch großen Teams wichtige Komponenten, wie zum Beispiel Build-Notifications und External-Access. Bei der Konfiguration der Prozesse werden die Builds anhand von Templates und Queues in das System eingepflegt und verwaltet. Bei direktem Zugriff auf ein Maven-Repository ist es zum Beispiel möglich, die pom.xml-Dateien in den Build-Prozess einzubinden und mit einem konfigurierbaren Intervall von Continuum bauen zu lassen. Fehler bei JUnit-Tests oder Integrations-Probleme, die auftreten, werden dem Programmierer direkt per eMail, Jabber,IRC oder GoogleTalk mitgeteilt. Bei größeren Projekten, die Abhängigkeiten zu anderen Modulen haben, werden alle Abhängigkeiten berücksichtigt und mittels Queue-Verfahren nacheinander gebaut. Mit dem integrierten Release-Management und einem der verbreiteten Versionierungs-Systeme im Backend können Tags, Branches und Trunks verwaltet werden. Continuous Integration ist ein wichtiges Werkzeug in der Software-Entwicklung.

Gerade heute wird es für Software-Architekten und –Tester zunehmend wichtiger, möglichst unabhängig von Programmierern zu arbeiten. Eine kontinuierliche (Neu-)Bereitstellung der Software auf Integrationsumgebungen spart Zeit und Kommunikation. Die Basis dafür ist das Continuum-System der ASF, das durch seine Open Source Gemeinde zunehmend an Bedeutung gewinnt. Diese Bedeutung spiegelt sich auch in den zahlreichen Enterprise-Projekten wider, die mit Hilfe von Continuum realisiert werden.

MicroAbstract1: Standardisierung der Software-Entwicklung mit Maven2

In der Software-Entwicklung wird mit wachsender Projekt-Größe die Notwendigkeit stukturierter Arbeit deutlich. Je größer ein Software-Projekt wird, desto mehr Entwickler bearbeiten die gemeinsame Code-Basis. Einheitliche Kompilierungen und Tests werden zu einem zentralen Kriterium für gemeinsames Arbeiten und zur Vermeidung von Fehlern. Diese Punkte lassen sich zum einen mit strukturierter Arbeitsaufteilung und zum anderen mit entsprechenden Build- und Repository-Tools lösen, beziehungsweise vermeiden. Der Einsatz eines effektiven Build-Tools wird damit zum Kernpunkt einer Software-Entwicklung.

Die Apache Software Foundation (ASF) stellt mit Maven2 ein Open Source-Werkzeug zur Verfügung, welches die einheitliche und strukturierte Arbeit zwischen Entwicklern realisieren kann. Die ASF stellt dabei die Kriterien „Bereitstellung eines einheitlichen Build-Systems“ und „Vereinfachung des Build-Prozesses“ als die wichtigsten Ziele von Maven2 in den Mittelpunkt. Weitere Ziele sind „Qualifizierte Projekt-Informationen“ und „Best Practises“, sowie „transparente Migration neuer Features“. Maven2 wird für den Build und das Managing von (Java-basierten) Software-Projekten benutzt. Hierbei wird ein standardisierter Zyklus zur Software-Entwicklung und eine Projekt-Struktur entwickelt, sodass auch für neue Projekt-Mitglieder die Einbindung in das Projekt erleichtert werden kann. Die erste Stufe „Validate“ überprüft dabei die Ordner- und Dateistruktur des Projekts auf Gültigkeit. „Compile“, als zweite Stufe, kompiliert die Quell-Code-Dateien. „Test“ und „Package“ führen die Tests und das Packen des fertigen Projekts zu einem bzw. mehreren Datei-Archiven durch. „Integration-Test“ und „Verify“ überprüfen das Archiv auf die Ausführbarkeit und gültige Struktur auf einem Test-System. „Install“ stellt eine Funktion bereit, die in der modularen Software-Entwicklung benötigt wird. Dabei wird das entstandene Archiv in ein (lokales) Repository installiert, um es auch anderen Modulen zur Verfügung zu stellen. Die abschließende Phase „Deploy“ portiert das Produkt auf ein (entferntes) Repository, auf ein weiteres Testsystem oder auf das Zielsystem der Anwendung. Alle diese Phasen können durch Plugins an die jeweiligen Projekt-Bedürfnisse angepasst werden. Ein wesentlicher Unterschied zum bisher verbreiteten Einsatz von Ant (ebenfalls ein Build-Tool der ASF) stellt die Fähigkeit zur Auflösung transistiver Abhängigkeiten durch das Build-System Maven2 dar. Dabei werden auch die Abhängigkeiten der einzelnen Plugins durch Dependencies aufgelöst, und aktuell gehalten. Maven2 basiert dabei auf dem „Projekt Object Model“ (POM), welches nicht auf dem Prinzip „Wie soll etwas gemacht werde?“ sondern „Was soll gemacht werden?“ aufbaut . Die pom.xml wird dabei für jedes Projekt zentral für den Build, das Reporting und die Dokumentation konfiguriert.

Maven bedeutet im jiddischen „Wissensspeicher“ und war als Ansatz für die Vereinfachung von Build-Prozessen der ASF gedacht. Das Ergebnis ist ein umfangreiches und erweiterbares Build-System, welches durch eine wachsende Open Source-Gemeinde an Bedeutung gewinnt und von professionellen Entwickler-Teams vermehrt im Umfeld von Groß-Projekten Einsatz findet. Die Standardisierung wird zunehmend bei internationalen Software-Projekten als wichtiges Kriterium erkannt. Durch hohen Offshore- und Freelancer-Einsatz in heutigen und zukünftige Projekt-Strukturen müssen neue Projekt-Mitarbeiter in die aktuellen Entwicklungs-Strukturen eingearbeitet werden. Durch die Maven2-Standardisierung und das integrierte Repository-Konzept wird diese Einarbeitungszeit erheblich verkürzt und die Wiederverwendbarkeit von Software-Komponenten gesteigert.

commandline interface (cli) per Rechtsklick im Explorer öffnen (Windows)

Machmal kann es schon nervig sein, sich durch seine Unterverzeichnisse mit einer (dank Windows NT) Länge von 255 Zeichen via Kommandozeile durchzuhangeln. Hierbei sei der Wert der Tab-Taste zum Vervollständigen der Verzeichnisnamen nur ganz am Rande erwähnt. So ist es doch viel bequemer, mich per Maus durch die liebreizende Aero-Oberfläche meines besseren Windows 2000 zu klicken und dann ganz gezielt in einem Verzeichnis in die Kommandozeile zu hüpfen. Folgend nun ein kleiner Abstecher in die Registry, um das über einen Kontext-Eintrag zu ermöglichen :

1) per regedit die Registry zum bearbeiten öffnen.

2) zu HKEY_LOCAL_MACHINE\Software\Classes\Folder\Shell durchhangeln

3) neuen Schlüssel anlegen (Name : „cli“)

4) In den Schlüssel einen Unterschlüssel anlegen (Name : Command)

5) Standard-Schlüssel in „Command“ den Wert „cmd.exe /k pushd %L“ zuweisen