Was wollen wir?

An ein firmeneigenes Repository — oder auch: corporate repository — gelten besondere Anforderungen. Diese können bei einem “einfach privat-eigenen” verändert werden, aber man kommt meistens auf folgende Punkte:

1. Ein Repository soll den Entwicklern zum Deployen der eigenen Artifakte und Module zur Verfügung gestellt werden. Wahlweise übernimmt dies auch ein automatischer Build-Agent wie Hudson, TeamCity und haste-nicht-gesehen.
2. Ein Repositorymanager soll als proxy fungieren. In einer Firma spart dies nicht nur einfache Bandbreite. Da ein solcher Manager in der Regel im lokalen Netz steht, sind die Interaktionszeiten um ein Vielfaches besser.
3. Ein so genanntes third party pepository für die Abhängigkeiten, die unbedingt notwendig sind und wovon es keine Maven-Abhängigkeiten gibt.

Für Punkt zwei spricht auch eine wesentlich einfachere Konfiguration der Clients (Entwicklerprofile), da nur noch ein Repository eingetragen werden muss. Alle “bekannten” Repositories werden zentral gebündelt, damit schwindet natürlich gleichzeitig die “Freiheit” des einzelnen Entwicklers, andere “unbekannte” Repositories zu verwenden. Dies ist jedoch vernachlässigbar, weil: Diese “Freiheit” schränkt im Endeffekt den Buildprozess und auch die Wiederverwendbarkeit ein. Das Hinzufügen von weiteren Repositories in die POM ist aus Gründen der Versionisierung und Nachhaltigkeit auch keine optimale Lösung. Dennoch, alles nur eine Sache der Konfigurations der Clients.

Was brauchen wir?

Es gibt eine Reihe von Repository-Managern, die allesamt viel können. Die Wahl auf Nexus fällt hier aus folgenden Gründen:

• der Footprint ist mit 30 Megabyte wesentlich kleiner als bspw. Artifactory
• die interne Verzeichnisstruktur entspricht mehr oder weniger 1:1 der realen Organisationsstruktur eines Maven-Repositorys (im Vergleich: Artifactory speichert ein eigenes Datenbankstruktur ähnliches Layout)
• Nexus und das Eclipse-Plugin m2eclipse sind vom gleichen Hersteller Sonatype und ergänzen sich; nach dem Umstellen bemerkt der Entwickler keinen Unterschied in der Suche, Auto-Discovery, o.ä.

Eine umfangreiche Online-Dokumentation ist auf der Nexus-Seite zu finden.

Installation

Nexus wird unter anderem als WAR ausgeliefert, insofern die Installation in einen Tomcat ein leichtes ist. Beachtenswert ist dabei nur, dass Nexus ein Verzeichnis ~/sonatype-work erstellt. Da sich dort unter Umständen viele Nutzdaten ansammeln, kann ein Verschieben (symbolischer Link?) nicht verkehrt sein. Da sich mit der Laufe der Zeit einiges an Daten ansammeln kann, sollte der Platz nicht zu sparsam vermessen sein.

Umfang

Nachdem Tomcat bzw. Nexus gestartet ist, kann man sich mit dem Default-Daten admin/admin123 anmelden (analog  mit den Daten der anderen beiden Benutzern!).

Nexus kommt bereits mit einer Reihen von vorkonfigurierten, eigenen hosted repositories einher.

• releases sammelt alle Release-Artifakte der Firma
• snapshots sammelt alle Snapshot-Artifakte der Firma
• third-party sammelt alle Release-Artifakte externer Quellen, wofür es keine Maven-Repositories gibt (oder wo man jenes Repository nicht generell zur Verfügung stellen will), gutes Beispiel ist ein (aktueller) Oracle-JDBC-Treiber

Daneben gibt es so genannte proxy repositories, die praktisch gesehen nur aus einem Index bestehen. Wie ein Proxy hängen sie sich zwischen dem Client und dem tatsächlichen Repository und cachen alle Artifakte lokal. Selbst der Index ist mehrere Megabytes groß, das sollte man nicht vernachlässigen. Voreingetragene proxy repositories sind Apache Snapshots, Codehaus Snapshots, Central Maven Repository (Maven1/Maven2-Repository-Konverter sind in Nexus vorhanden a.k.a. virtual repositories).

Die grouped repositories sind auch rein virtuelle Gruppierungen von verschiedenen Repositories. Das Standard Repository “Public” ist in der einfachsten Konfiguration eine Sammlung aller (aktivierten) Repositories auf dem Manager — also sowohl der externen Spiegel, der Third-Parties als auch den eigenen Artifakten.

Konfiguration

Die Aktivierung und Verwaltung von (neuen) Repositories ist abhängig der eigenen Bedürfnisse. Meistens sinnvoll ist es jedoch, bei den drei großen Spiegeln (proxy repositories) in dem Konfigurationstab das Indizieren (Download Remote Indexes) zu aktivieren. Je nach Belieben kann man in der Gruppe Administration auch das Aktualisierungsverhalten steuern.

Konfiguration: Deployment

Um ein Deployment zu gewährleisten, muss man nebst Kenntnis der Repository-URL (eben die URL) nur wissen, ob der anonyme Zugriff erlaubt sein soll, oder ob man einen Deployment-Benutzer einrichten und nutzen willst. Falls eine Richtlinie vorschreiben sollte, dass dies nur ein Build-Agent machen darf, ist ein (geheimes) Passwort oder Schlüssel unabdingbar.

Konfiguration: Client

Nehmen wir an, der Nexus-Manager ist auf dem Host 192.168.0.10:8080/nexus installiert. In der einfachen Installation und Konfiguration sammeln sich im public repository praktisch alle relevanten Artifakte (sowohl Releases als auch Snapshots).

<settings>
<mirrors>
<mirror>
<id>corporate</id>
<name>Corporate Repository</name>
<url>http://192.168.0.10:8080/nexus/content/groups/public</url>
<mirrorOf>*</mirrorOf>
</mirror>
</mirrors>
</settings>

Der Deployment-User benötigt ggf. Zugangsdaten für das entsprechende Repository.

Ein Client wie m2eclipse sollte danach einen kompletten Rebuild des Index machen.

Als erstes fügt man ein externes Webapp-Modul ein, der Suchpfad ist “${catalina_home}/webapp/manager”. Dabei sollte man beachten, dass scheinbar der Pfad ausgeschrieben werden muss (bzw. eine gültige Catalina-Home-Variable). Dieser Schritt hat der server.xml eine Zeile (meist gaaaanz unten) wie folgt hinzugefügt:

<Context docBase="YOURPATH/webapps/manager" path="/manager" reloadable="false"/>

Wie man sich gerne überzeugen lassen kann, funktioniert die Anwendung jedoch noch nicht. Der Grund: Der Tomcatmanager muss im priviligierten Modus gestartet werden, welcher zusätzlich eine Benutzerkennung erwartet. Zunächst muss die o.g. eingefügt Zeile wie folgt angepasst werden (hier wichtig: privileged=true).

<Context antiJARLocking="false" antiResourceLocking="false" docBase="YOURPATH/webapps/manager" path="/manager" privileged="true" reloadable="false"/>

Wie bereits erwähnt, erwartet der Manager einen authentifizierten Benutzer. Man kann sich das Leben aber einfach machen, und die vorgefertige tomcat-users.xml nutzen. Man kann die Einträge auskommentieren; wichtig ist jedoch, das mindestens ein Benutzer existiert, dem die Rollen admin und manager zugewiesen sind. Beispielsweise:

<user username="manager" password="manager" roles="admin,manager"/>

Soweit, so gut. Nicht vergessen sollte man jedoch das (Re)Publish des Servers, denn sonst deployt Eclipse die neuen Einstellungen nicht in das interne Tomcat-Home-Verzeichnis.

Der Manager findet sich dann – bei einer Standardinstallation – unter der Adresse http://localhost:8080/manager/html

Der Updatevorgang via UpdateSite funktionierte leider nicht; aber das manuelle Herunterladen der entsprechenden Plugindatei dagegen schon. Es ist eine Jar-Datei, welche einfach in den plugins-Ordner geschubst wird.

Anschließend (nach einem Neustart Eclipse’) muss in den Projekteinstellungen “Metrics” zunächst aktiviert werden; danach lässt sich via Export->Metrics eine entsprechende umfangreihe Statistik generieren. Aber eine beherzte Warnung: Ohne Vorkenntnisse kommt man nur bedingt weit.

Was etwa eine zyklomatische Zahl oder was etwa “Feature Envy” ist, sollte man entweder wissen oder sich das Wissen zeitnah aneignen. Eine spontane Suche ergab diese kleine Arbeit, sollte für den Anfang reichen.

Stand der Diplomarbeit: Knapp 17 KLOC. Refactoring noch nicht abgeschlossen.

Joa, es ist wieder Zeit für einen Artikel in der Java/DA-Reihe.

Als erstes und sehr einfach zu testendes Kriterium gilt beim Testen die Code Coverage. Eigentlich sehr simpel, denn es quantifiziert nur die Code-Coverage, also von wie vielen Zeilen Code (Instructions) tatsächlich wie viele (bzw. welche) auch ausgeführt werden. Da man dies natürlich gerne automatisiert machen möchte, sind Tests wie mit jUnit ideal. Aber, auch normale Anwendungen sind mitzutracen und den Codecoverage ist zu ermitteln.

Für Eclipse gibt es dazu ein prima Plugin namens EclEmma. Und auch schnell über die Update-URL im Manager installiert. EclEmma dient dabei als eine Art Wrapper für verschiedene Launchtypen – also beispielsweise als normale Applikation oder einen jUnit-Test bzw eine ganze Suite (Plugins). Das Ergebnis wird nach Beendigung des Programms/Tests innerhalb von Eclipse in einer Baumstruktur dargestellt; sehr schön ist auch die grafische Hervorhebung direkt im Sourcecode. Alternativ kann man sich das Ergebnis auch als HTML exportieren lassen.

at EclEmma – Java Code Coverage for Eclipse.

Ernüchterned ist es ja schon irgendwie, wenn man sein Fehler- und Warnungsfreie Projekt (Eclipse Compiler läßt grüßen) damit checkt und vor Hunderten Fehlern steht..