Lente met Maven BOM

1. Overzicht

In deze korte tutorial gaan we kijken hoe Maven, een tool gebaseerd op het concept van Project Object Model (POM), gebruik kan maken van een BOM of "Bill Of Materials".

Voor meer details over Maven, kun je ons artikel Apache Maven Tutorial raadplegen.

2. Concepten voor afhankelijkheidsbeheer

Om te begrijpen wat een stuklijst is en waarvoor we deze kunnen gebruiken, moeten we eerst basisconcepten leren.

2.1. Wat is Maven POM?

Maven POM is een XML-bestand dat informatie en configuraties (over het project) bevat die door Maven worden gebruikt om afhankelijkheden te importeren en om het project op te bouwen.

2.2. Wat is Maven BOM?

BOM staat voor Bill Of Materials. Een stuklijst is een speciaal soort POM dat wordt gebruikt om de versies van de afhankelijkheden van een project te beheren en een centrale plaats te bieden om die versies te definiëren en bij te werken.

BOM biedt de flexibiliteit om een afhankelijkheid aan onze module toe te voegen zonder ons zorgen te maken over de versie waarvan we afhankelijk zouden moeten zijn.

2.3. Overgankelijke afhankelijkheden

Maven kan de bibliotheken ontdekken die nodig zijn door onze eigen afhankelijkheden in ons pom.xml en neemt ze automatisch op. Er is geen limiet aan het aantal afhankelijkheidsniveaus waaruit de bibliotheken worden verzameld.

Het conflict komt hier wanneer 2 afhankelijkheden verwijzen naar verschillende versies van een specifiek artefact. Welke wordt door Maven opgenomen?

Het antwoord is hier de "dichtstbijzijnde definitie". Dit betekent dat de gebruikte versie het dichtst bij ons project zal zijn in de boom van afhankelijkheden. Dit wordt afhankelijkheidsbemiddeling genoemd.

Laten we het volgende voorbeeld bekijken om de afhankelijkheidsbemiddeling te verduidelijken:

A -> B -> C -> D 1.4 en A -> E -> D 1.0

Dit voorbeeld toont dat project EEN hangt af van B en E.B en E. hebben hun eigen afhankelijkheden die verschillende versies van het D artefact. Artefact D 1.0 zal worden gebruikt in de build van EEN project omdat het pad door E. is korter.

Er zijn verschillende technieken om te bepalen welke versie van de artefacten moet worden opgenomen:

We kunnen altijd een versie garanderen door deze expliciet te declareren in de POM van ons project. Om dat bijvoorbeeld te garanderen D 1.4 wordt gebruikt, moeten we het expliciet toevoegen als een afhankelijkheid in het pom.xml het dossier.
We kunnen de Afhankelijkheidsbeheer sectie om artefactversies te beheren, zoals we later in dit artikel zullen uitleggen.

2.4. Afhankelijkheidsbeheer

Simpel gezegd, Dependency Management is een mechanisme om de afhankelijkheidsinformatie te centraliseren.

Als we een set projecten hebben die een gemeenschappelijke ouder erven, kunnen we alle afhankelijkheidsinformatie in een gedeeld POM-bestand met de naam BOM plaatsen.

Hieronder volgt een voorbeeld van hoe u een stuklijstbestand schrijft:

 4.0.0 baeldung Baeldung-BOM 0.0.1-SNAPSHOT pom BaelDung-BOM ouder pom test a 1.2 test b 1.0 compileren test c 1.0 compileren

Zoals we kunnen zien, is de stuklijst een normaal POM-bestand met een afhankelijkheidsbeheer sectie waar we alle informatie en versies van een artefact kunnen opnemen.

2.5. Met behulp van het stuklijstbestand

Er zijn 2 manieren om het vorige stuklijstbestand in ons project te gebruiken en dan zijn we klaar om onze afhankelijkheden te declareren zonder ons zorgen te hoeven maken over versienummers.

We kunnen erven van de ouder:

 4.0.0 baeldung-test 0.0.1-SNAPSHOT pom-test baeldung Baeldung-BOM 0.0.1-SNAPSHOT

Zoals we kunnen zien, erft ons project Test de Baeldung-BOM.

We kunnen ook de stuklijst importeren.

Bij grotere projecten is de benadering van overerving niet efficiënt omdat het project slechts één ouder kan erven. Importeren is het alternatief, omdat we zoveel stuklijsten kunnen importeren als we nodig hebben.

Laten we eens kijken hoe we een stuklijstbestand kunnen importeren in ons project POM:

 4.0.0 baeldung-test 0.0.1-SNAPSHOT pom-test baeldung Baeldung-BOM 0.0.1-SNAPSHOT pom-import

2.6. BOM-afhankelijkheid overschrijven

De volgorde van prioriteit van de versie van het artefact is:

De versie van de directe verklaring van het artefact in ons project pom
De versie van het artefact in het bovenliggende project
De versie in de geïmporteerde pom, rekening houdend met de volgorde van het importeren van bestanden
afhankelijkheidsbemiddeling

We kunnen de versie van het artefact overschrijven door het artefact in de pom van ons project expliciet te definiëren met de gewenste versie
Als hetzelfde artefact is gedefinieerd met verschillende versies in 2 geïmporteerde stuklijsten, wint de versie in het stuklijstbestand die als eerste werd gedeclareerd

3. Lente stuklijst

We kunnen ontdekken dat een bibliotheek van een derde partij, of een ander Spring-project, een transitieve afhankelijkheid naar een oudere release trekt. Als we vergeten om expliciet een directe afhankelijkheid aan te geven, kunnen er onverwachte problemen ontstaan.

Om dergelijke problemen op te lossen, ondersteunt Maven het concept van stuklijstafhankelijkheid.

We kunnen het spring-framework-bom in onze afhankelijkheidsbeheer sectie om ervoor te zorgen dat alle Spring-afhankelijkheden dezelfde versie hebben:

   org.springframework spring-framework-bom 4.3.8.RELEASE pom import

We hoeven het versie attribuut wanneer we de Spring-artefacten gebruiken zoals in het volgende voorbeeld:

  org.springframework spring-context org.springframework spring-web

4. Conclusie

In dit korte artikel hebben we het Maven Bill-Of-Material Concept laten zien en hoe de informatie en versies van het artefact in een gemeenschappelijke POM kunnen worden gecentraliseerd.

Simpel gezegd, we kunnen het vervolgens erven of importeren om gebruik te maken van de BOM-voordelen.

De codevoorbeelden in het artikel zijn te vinden op GitHub.

streamalism.org