Chris Nygaard (by-nc-nd 2.0)

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 progra­mování. Mohl bych psát o víc sexy nástrojích jako Gradle, ale nejde si nevšim­nout, ž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-mo­dule buildu. Jestli to zrovna vy nepotře­bu­jete, tím lépe.

Multi-module build

Nebudu popiso­vat, co to multi-mo­dule 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. Pocho­pi­telně je můžete překrýt, ale máte k tomu důvod? Dost si takhle usnad­níte třeba release.

Veškeré závis­losti uvádějte v parentu v dependencyManagementu a ne rovnou v dependencies, ať se vám neroz­jedou verze. Potře­bu­je-li pak nějaký modul konkrétní závis­lost, uvede v dependencies pouze groupId a artifactId. Verzi řídí parent pro všechny moduly.

Stejně jako lze mít uklizeno v depen­den­cies, lze uklidit i v plugi­nech. Ukažme si to na příkladu compiler pluginu. Pro určité packagingy tam je automa­ticky namapo­vaný, ale nejspíš budete potře­bovat změnit target a source na něco vyššího než 1.5 Bylo by, když ne chybou, tak určitě neele­gantní, 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ře­bují. Lze to vylepšit tak, že plugin definu­jete v pluginManagementu podobně jako závis­losti v dependencyManagementu.

Ve všech těch paren­tech a trans­i­tiv­ních závis­los­tech se člověk snadno ztratí, takže můžete nakonec ověřit konfi­gu­raci modulu pomocí mvn help:effective-pom

BOM (bill of materials) a relea­sování si nechám na příště.

Ukázka

Celý minip­ro­jekt na githubu.

Anketa

Související