Pořádek v multi-module buildu
Mám rád v dílně pořádek. Všechno má své místo, na které se musí vracet. Nářadí nesmíte dlouze hledat či o něj dokonce zakopávat. Nejlépe je uklízet hned a málo, než později a hodně, protože se vám do toho nebude chtít. Stejně to mám rád při programování. Mohl bych psát o víc sexy nástrojích jako Gradle, ale nejde si nevšimnout, že mnozí programátoři (ať už z nezájmu nebo nedostatku kázně) mají herberk i v hojně rozšířeném Mavenu. Chtěl bych ukázat, jak lze mít uklizeno v multi-module buildu. Jestli to zrovna vy nepotřebujete, tím lépe.
Multi-module build
Nebudu popisovat, co to multi-module build je. Zaměřím se na několik nešvarů, se kterými jsem se setkal.
Předně v modulu nemusíte uvádět groupId ani verzi, převezme se z parenta, stačí pouze artifactId. Pochopitelně je můžete překrýt, ale máte k tomu důvod? Dost si takhle usnadníte třeba release.
Veškeré závislosti uvádějte v parentu v dependencyManagementu a ne rovnou v dependencies, ať se vám nerozjedou verze. Potřebuje-li pak nějaký modul konkrétní závislost, uvede v dependencies pouze groupId a artifactId. Verzi řídí parent pro všechny moduly.
Stejně jako lze mít uklizeno v dependencies, lze uklidit i v pluginech. Ukažme si to na příkladu compiler pluginu. Pro určité packagingy tam je automaticky namapovaný, ale nejspíš budete potřebovat změnit target a source na něco vyššího než 1.5 Bylo by, když ne chybou, tak určitě neelegantní, definovat plugin přímo v parentu a nutit ho tak všem modulům, i těm, které ho vzhledem ke svému packagingu nepotřebují. Lze to vylepšit tak, že plugin definujete v pluginManagementu podobně jako závislosti v dependencyManagementu.
Ve všech těch parentech a transitivních závislostech se člověk snadno ztratí, takže můžete nakonec ověřit konfiguraci modulu pomocí mvn help:effective-pom
BOM (bill of materials) a releasování si nechám na příště.
Ukázka
Celý miniprojekt na githubu.
