Konflikt tranzitivních závislostí

Pochopitelně není možné znát do hloubky všechny nástroje a frameworky, se kterými denně přicházíme do styku. Na druhou stranu, pragmatický programátor se snaží pochopit alespoň principy, obzvláště u klíčových technologií. Tentokrát bych chtěl vysvětlit konflikt tranzitivních závislostí v Mavenu (ukážu i alternativu v Gradlu).

Zadání

Máme projekt s hromadou závislostí a ty s sebou nesou další tranzitivní závislosti. Ale co se stane, zavlečeme-li si do projektu stejný artefakt jiné verze?

Maven

Co na to Maven? Projekt možná nakrásně zkompilujete, ale za běhu se můžou dít věci… najednou na vás vyskočí ClassNotFoundException či NoSuchMethodError, ačkoliv tam patřičnou třídu přeci máte, ne? Nejspíš máte, ale třeba binárně nekompatibilní. Problém je v tom, že při konfliktu tranzitivních závislostí Maven nekřičí, ani nevezme nejvyšší verzi (jak byste nejspíš čekali), ale zvolí tu nejbližší ve stromě závislostí. Více v dokumentaci Introduction to the Dependency Mechanism.

Pojďme si to ukázat na následujícím příkladu. Jistě, v takto jednoduchém případě byste měli vybrat stejné verze Springu, ale v komplikovanějším projektu se vám závislosti zavlečou, ani nevíte odkud.

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>cz.zvestov.mvn</groupId> <artifactId>transitive-dependencies</artifactId> <version>1.0.0-SNAPSHOT</version> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>3.2.4.RELEASE</version> </dependency> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-web</artifactId> <version>3.1.4.RELEASE</version> </dependency> </dependencies> </project>

Nechme si vypsat seznam závislostí pomocí příkazu mvn dependency:list

Hm, vidíme spring-aop 3.0.7, zkontrolujme "proč" a to pomocí příkazu mvn dependency:tree -Dverbose

Teď, když už víme proč, můžeme danou závislost exludovat, případně explicitně definovat, čímž verzi přebijeme.

Všimněte si, že spring-web se vybral ve vyšší verzi, ovšem nikoliv proto, že je novější, ani proto, že je v tranzitivní závislosti blíž. V tranzitivní závislosti je ve stejné vzdálenosti, ale je v pomu definovaný dříve.

Gradle

Koluje takový vtip:

Jaký je rozdíl mezi autory Mavenu a Antu? Autoři Antu už se omluvili.

A co na to Gradle? Mějme ekvivalentní konfiguraci předchozímu maven příkladu.

apply plugin: 'java' repositories { mavenLocal() } configurations.all { //TODO comment out to result in a build failure //resolutionStrategy.failOnVersionConflict() } dependencies { compile "org.springframework:spring-webmvc:3.2.4.RELEASE" compile "org.springframework.security:spring-security-web:3.1.4.RELEASE" }

Nechme si vypsat závislosti pomocí příkazu gradle dependencies

Všimněte si, že jsou všude použity nejvyšší verze, což je výchozí chování Gradlu. Můžete být ovšem přísnější a v případě konfliktu nechat build selhat, čehož docílíte použitím failOnVersionConflict() (odkomentujte TODO ve skriptu výše).

V tom případě musíte verzi vynutit pomocí force. Více v dokumentaci Resolve version conflicts a v javadocu ResolutionStrategy.

Zadání

Maven

Gradle

Související