In elke editie zal Robert Scholte een probleem voorleggen en deze oplossen met behulp van Apache Maven om meer inzicht te geven in Maven zelf en de vele beschikbare plugins.
In maart 2015 werd de nieuwste versie van Apache Maven gereleased: 3.3.1. De vorige versie was 3.2.5, dus dat doet vermoeden dat deze release meer bevat dan alleen buxfixes. En dat klopt. Eén van de meest invloedrijke wijzigingen is dat met deze Maven versie minstens een Java Runtime Environment versie 7 vereist is. We hebben het hier alleen over de runtime: plugins kunnen nog steeds gebruik maken van een oudere JDK, bijvoorbeeld voor het compileren van de java sources. De kans is dus aanwezig dat de JAVA_HOME voor Maven niet meer wijst naar het gewenste compilerpad. Sinds Maven 2.0.9 is daarvoor al een oplossing beschikbaar waarmee je beter overweg kunt met verschillende JDK versies: Toolchains. Vandaar dat we deze way-of-work meer willen promoten en hebben we voor Toolchains een aantal verbeteringen doorgevoerd in deze versie van Maven.
Laat ik allereerst het concept even proberen uit te leggen: met Toolchains kun je ervoor zorgen dat binnen een Maven project verschillende plugins dezelfde versie van een tool gebruiken. Denk bijvoorbeeld aan JDK, die gebruikt wordt door onder andere de maven-compiler-plugin, maven-surefire-plugin, maven-jarsigner-plugin en maven-javadoc-plugin.
Om je project gebruik te laten maken van Toolchains, moeten er twee acties gedaan worden. Ten eerste moet er een toolchains.xml aangemaakt worden. Tot voorheen moest deze in de ${user.home}/.m2-map staan, maar sinds Maven-3.3.1 mag deze ook in de conf-map van de Maven installatie staan. In het laatste geval worden de beide toolchains.xml gemerged, net zoals dat met de settings.xml gebeurt. Ten tweede neem je de maven-toolchains-plugin op in je project, waarin je aangeeft welke tool gebruikt moet worden in dit project. (De voorbeelden vind je op guide-using-toolchains).
Een belangrijk voordeel van deze opzet is dat systeem-specifieke paden niet in je pom.xml opgenomen hoeven te worden. De toolchains.xml biedt ruimte voor meerdere versies van dezelfde tool. Sterker nog, je kunt zelfs gelijke versies opnemen, maar dan voor verschillende vendors. Uiteindelijk zal de maven-toolchains-plugin door de gedefinieerde tools lopen en de eerste matchende tool op basis van zijn configuratie selecteren.
Je kunt de locatie van de toolchains.xml ook via de commandline sturen.
-t, --toolchains <arg> Alternative path for the user toolchains file
-gt, --global-toolchains <arg> Alternative path for the global toolchains file
Het mag voor zich spreken, dat deze laatste optie met Maven-3.3.1 is toegevoegd.
Voor Maven-plugin ontwikkelaars is de toegang tot de Toolchains sterk verbeterd. Het is mogelijk geworden om tools te selecteren zonder aanwezigheid van de maven-toolchains-plugin. Dit is handig voor plugins, die juist af moeten wijken van de keten van plugins. Concreet voorbeeld is de maven-jdeps-plugin (is nog in ontwikkeling) welke minimaal JDK8 vereist, maar prima werkt met via eerdere JDK gecompileerde classes. Deze optie biedt ook optimalisatiemogelijkheden voor al bestaande plugins. Zo kijk ik nog naar de impact om plugins al automatisch een JDK tool te selecteren op basis van de source/target waarde van de compiler. Tot nu toe wordt altijd teruggevallen op de JAVA_HOME als er geen maven-toolchains-plugin is geconfigureerd, maar als er toch een toolchains.xml is, zou ik die eerst nog willen controleren op een matchende tool. Daarmee krijgt de term “chain” een extra dimensie: het gaat niet alleen om een keten van plugins die dezelfde tool gebruiken, maar ook om het ketenen van een tool aan een plugin.
Een groeiende lijst van toolchains-aware Maven plugins kan gevonden worden op guide-using-toolchains.
Links
http://maven.apache.org/guides/mini/guide-using-toolchains.html