В чём заключается проблема зависимостей при создании теневого JAR (fat JAR)?

А, ну вот, классика жанра, подъехали! Теневой JAR, он же жирный, он же убер. Собрал в кучу всю свою хуйню и библиотеки соседские — красота! А потом бац — и пиздец. Приложение падает с такими ошибками, что волосы дыбом встают.

Слушай, а проблема-то в чём, собственно? А в том, что ты, как последний распиздяй, свалил в одну кучу все классы из всех зависимостей. И начинается весёлая жизнь.

Основные засады, куда можно влететь:

1. Классы-близнецы, ёпта: Один и тот же класс, но в разных банках (jar-файлах). JVM найдёт первого — и на том спасибо.
2. Версионный ад: Библиотека А хочет library-commons версии 1.0, а библиотека Б орёт, что ей нужна версия 2.0, и они между собой, блядь, несовместимы, как кошка с собакой.

И чем это аукнется? Да всем, чем угодно!

• NoSuchMethodError / NoSuchFieldError: Это когда JVM, такая хитрая жопа, загрузила класс из старой версии, а твой код лезет вызывать метод, который есть только в новой. Или наоборот. Короче, нихуя не получается.
• ClassNotFoundException: Класс вроде есть, а его вроде нет. Порядок загрузки по classpath'у — тёмный лес, ебать.
• LinkageError: Вообще пиздец, тут уже классозагрузчики друг другу мозги ебут, загрузив разные копии одного и того же.

Вот тебе наглядный пиздец в лицах:

Твоё приложение дружит с:
- library-commons v1.0 (там есть метод com.example.Utils.doSomething())
- library-client v2.0 (а она уже дружит с library-commons v2.0, где этот метод, сука, выкинули)

В твоём жирном JAR'е оказываются ОБА файла: и library-commons-1.0.jar, и library-commons-2.0.jar.
JVM, не долго думая, хватает класс `com.example.Utils` из первого попавшегося (допустим, v1.0).
А код из library-client v2.0 вызывает `Utils.doSomething()` и получает по ебалу — `NoSuchMethodError`!
Потому что в v2.0 этого метода уже нет, ядрёна вошь!

Ну и что делать, спросишь ты? Не паниковать, блядь!

• Сначала посмотри, что у тебя творится. Запусти mvn dependency:tree и изучай этот лес, как Шерлок Холмс. Ищи, где сидят эти ебучие дубликаты.
• Выкинь лишнее. В Maven'е в pom.xml можно указать <exclusions> для зависимости и сказать: «Эту подзависимость, суку, не тащи, она мне всю малину портит».
• Переименуй, если не выкинешь (Shading). Это мощный приём. Берешь конфликтующую библиотеку и, через maven-shade-plugin, переупаковываешь её классы в другой пакет. Типа, спрятал от всех.

  <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-shade-plugin</artifactId>
      <configuration>
          <relocations>
              <relocation>
                  <pattern>com.conflicting.library</pattern>
                  <shadedPattern>myapp.shaded.com.conflicting.library</shadedPattern>
              </relocation>
          </relocations>
      </configuration>
  </plugin>

  Теперь её классы живут в myapp.shaded.com.conflicting.library, и ни с кем не конфликтуют. Хитрая жопа!

• Если ты совсем крутой и проект нестарый, можно задуматься о модульной системе (JPMS). Это чтобы зависимости друг другу в глаза смотрели и чётко знали, кто кому что может. Жёстко, но справедливо.

Вот так вот, дружок. Собирать fat JAR — это не просто «упаковал и забыл». Это искусство баланса, ёпта. Иначе получишь не артефакт, а мину замедленного действия.