Вирішення залежностей Maven (конфлікт)

Question 1

Скажімо, у мене є чотири проекти:

Проект A (має залежність від B і D)
Проект B (має залежність від D)
Проект C (має залежність від D)
Проект D

У цьому випадку, якщо я запускаю проект A, Maven правильно вирішить залежність до D. Якщо я це правильно розумію, Maven завжди приймає залежність із найкоротшим шляхом. Оскільки D - пряма залежність від A, вона буде використовуватися швидше, ніж D, яка вказана в межах B.

А тепер припустимо таку структуру:

Проект A (має залежність від B і C)
Проект B (має залежність від D)
Проект C (має залежність від D)
Проект D

У цьому випадку шляхи до вирішення D мають однакову глибину. Що трапляється, що у Мейвен буде конфлікт. Я знаю, що можна сказати Мейвену, що він повинен виключити залежності. Але моє питання полягає в тому, як вирішити такі проблеми. Я маю на увазі, що в реальному світі у вас багато залежностей і, можливо, багато конфліктів.

Чи справді найкращим практичним рішенням є виключення матеріалів чи існують інші можливі рішення для цього? Мені дуже важко мати справу, коли я раптом отримую виняток ClassNotFound, оскільки деякі версії змінилися, що змусило Maven взяти іншу залежність. Звичайно, знаючи цей факт, трохи легше здогадатися, що проблема полягає в конфлікті залежностей.

Я використовую maven 2.1-SNAPSHOT.

Question 2

Основний спосіб вирішення подібних ситуацій полягає у включенні <dependencyManagement>розділу в кореневу пам'ять вашого проекту, де ви вказуєте, яка версія якої бібліотеки буде використана.

РЕДАГУВАТИ:

<dependencyManagement>
  <dependencies>
    <dependency>
        <groupId>foo</groupId>
        <artifactId>bar</artifactId>
        <version>1.2.3</version>
    </dependency>
   </dependencies>
</dependencyManagement>

Тепер незалежно від того, яку версію бібліотеки foo: bar запитує залежність, для цього проекту та всіх підпроектів завжди буде використана версія 1.2.3.

Довідково:

Управління залежностями

Question 3

Maven може впоратися з обома ситуаціями без будь-яких конфліктів. Конфлікти будуть існувати, коли потрібні дві версії транзитивної залежності. ClassNotFoundExceptionВи охарактеризували результати з програми (або залежності) намагається використовувати клас не доступний у версії конфліктної залежності , яка на самому ділі звикає. Існує кілька способів вирішити проблему.

Оновіть версії використовуваних вами бібліотек, які залежать від конфліктної залежності, так що всі вони залежать від однієї версії цієї залежності
Оголосіть конфліктну залежність як пряму залежність вашого проекту з версією, яку ви хочете включити (у прикладі, ту, що містить відсутній клас)
Вкажіть, яку версію конфліктної залежності використовувати транзитивні залежності, за допомогою <dependencyManagement>розділу POM
Явно виключіть небажані версії конфліктної залежності від включення до залежностей, які покладаються на них за допомогою <exclusion>

Question 4

Це принципово не проблема maven, а проблема Java. Якщо Project B і Project C потребують двох несумісних версій проекту D, то ви не можете використовувати їх обидві в Project A.

Спосіб вирішення подібних конфліктів Мейвен, на жаль, як ви вже знаєте, вибрати, які з них виключити.

Використання mvn dependency:analyzeта mvn dependency:treeдопомога у виявленні конфліктів.

Question 5

Ви можете застосувати послідовні залежності в цілому проекті за допомогою правила збіжності залежностей .

 <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-enforcer-plugin</artifactId>
     <version>1.3.1</version>
     <executions>
        <execution>
           <id>enforce</id>
           <configuration>
              <rules>
                 <DependencyConvergence/>
              </rules>
           </configuration>
           <goals>
              <goal>enforce</goal>
           </goals>
        </execution>
     </executions>
  </plugin>

Question 6

Однією з можливих стратегій є визначення для основного проекту, яку версію D використовувати (найновішу fg). Однак, якщо бібліотека D не сумісна із зворотною функцією, у вас виникла проблема, як зазначив kukudas - неможливо використовувати обидві бібліотеки у своєму проекті.

У такій ситуації може знадобитися використовувати B або C у старшій версії, щоб обидва залежали від сумісних версій D.