Auf Github gehört es zum guten Ton, im Wurzelverzeichnis des Projekts eine README-Datei abzulegen. Darin beschreibt man wozu das Projekt gut ist, wie man es baut,  nutzt, u.s.w. In der Regel heißt die Datei README.md . Die Dateiendung .md sagt aus dass es sich um eine Markdown-Datei handelt.

Mehr

Eine der vielen Funktionen des Spring-Frameworks ist die Fähigkeit, Ressourcen beim Herunterfahren der Anwendung automatisch aufräumen zu lassen. Dieser Artikel verschafft einen Überblick über die Möglichkeiten die es gibt, und wie man diese nutzt.

Mehr

Da diese Woche Java 11 erschienen ist (wie kürzlich hier berichtet), konnte ich es nicht lassen, ein klein wenig damit herumzuspielen.

Insbesondere war ich neugierig auf JEP-330, also der Möglichkeit, Java-Dateien direkt auszuführen zu können, ohne sie vorher kompilieren zu müssen. Voraussetzung ist, dass sich das komplette Programm innerhalb einer einzigen Java-Datei befindet.Mehr

Am gestrigen Dienstag, den 25.09.2018 war es soweit: ein halbes Jahr nach Erscheinen der Vorversion hat Java 11 den Meilenstein „GA“ – das heißt „General Availability“ – erreicht und ist somit öffentlich verfügbar.Mehr

In einem Maven-Projekt mit mehreren Modulen hatte ich kürzlich dass Problem, dass unter bestimmten Umständen die Ausführung des Befehls mvn clean fehlschlug. Laut Fehlermeldung konnten gewisse Dependencies nicht aufgelöst werden:

Bei den Dependencies aus der Fehlermeldung handelte es sich um Module des Projekts, das mit clean gesäubert werden sollte. Der Fehler trat während der Ausführung von clean in module-one auf, das wiederum module-two als Abhängigkeit hat.

Voraussetzung für den Fehler war, dass die genannten Module noch nie mit mvn install gebaut worden waren, d.h. die Module sich noch nicht im lokalen Maven-Repository befanden. Das kommt beispielsweise vor nachdem die Versionsnummer  geändert wurde, oder wenn das Projekt noch gar nie gebaut worden ist.

Nun sollte man denken, dass bei einem mvn clean die Abhängigkeiten keine Rolle spielen. Tun sie in der Regel auch nicht. Wie sich jedoch herausstellte, gab es in module-one eine Konfiguration des maven-antrun-plugin, die an die clean-Phase gebunden war (Zeile 8):

Beim Ausführen von mvn clean wurde also nicht nur das Projekt aufgeräumt, sondern auch das maven-antrun-plugin ausgeführt. Das Plugin setzt wiederum das Vorhandensein aller Abhängigkeiten des Moduls voraus.

Die Lösung war, das Antrun-Plugin an eine andere Phase zu binden. Wieso es an der clean-Phase hing konnte ich nicht mehr herausfinden (der Kollege von dem die Konfiguration stammte hatte das Unternehmen mittlerweile verlassen). Jedenfalls bietet der Maven Default Lifecycle eine große Auswahl an alternativen Phasen: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy.

Nach Auswahl und Konfiguration einer Phase die zum ausgeführten Ant-Task passt (in diesem Fall process-sources) lief der mvn clean-Befehl fehlerfrei durch.

In Oracles Java-Runtimes bis einschließlich Version 1.8.0_151 ist es standardmäßig nicht möglich, die Java Cryptography Extension (JCE) mit starker Verschlüsselung zu verwenden. Demnach dürfen beispielsweise Verschlüsselungen mit dem AES-Algorithmus nur Schlüssel mit einer maximale Länge von 128 bit benutzen. Alle Versuche, einen längeren Schlüssel zu verwenden werden mit folgender Exception geahndet:

Um mit längeren Schlüsseln arbeiten zu dürfen war es vor Java-Versionen vor 1.8.0_151 notwendig, die Java Runtime mit entsprechenden Unlimited Strength Cryptography Policy Files auszustatten (für Java 8 hier erhältlich). In Java 1.8.0_151 müssen diese Policy Files nicht mehr extra installiert werden. Stattdessen kann dort die starke Kryptografie durch setzen der Security Property crypto.policy=unlimited aktiviert werden.

Seit Version 1.8.0_161 ist die Unlimited Strength Cryptography standardmäßig aktiviert. Die Security Property muss also nicht mehr extra gesetzt werden. Soll keine starke Kryptografie erlaubt sein, kann diese mit crypto.policy=limited wieder auf kleine Schlüssellängen begrenzt werden.Mehr

JaCoCo ist ein sehr nützliches Tool für die Messung der Code Coverage, also der Abdeckung von Produktivcode durch automatisierte Tests, sowie zur Erstellung von Code Coverage Reports. An sich ist das Einbinden des JaCoCo-Maven-Plugins nicht schwierig. Hat man allerdings in einem Maven-Projekt mehrere Module, ist die Konfiguration nicht mehr ganz so trivial. Denn standardmäßig werden Coverage-Reports nur für die einzelnen Module generiert. Um einen aggregierten Report über alle Module hinweg zu erhalten, der die Gesamttestabdeckung des Projekts zeigt, und dabei außerdem zwischen Unit- und Integrations-Tests unterscheiden soll, ist schon etwas mehr Aufwand nötig. Leider gibt es kaum funktionierende Beispiele im Internet. Zudem ist die Dokumentation etwas dürftig, so dass man schon mal eine ganze Weile beschäftigt sein kann bis alles wie gewünscht funktioniert.

Daher haben wir ein funktionsfähiges Beispielprojekt mit drei Modulen erstellt, das als Vorlage für Projekte dienen kann.

Mehr