Я нашел решение вышеуказанной проблемы. Хотя лучшая практика, как также предложили Ferrybig и Mureinik в своих ответах, заключается в применении в проектах стандартов имен пакетов в нижнем регистре, но поскольку в моем случае это было невозможно, я придерживался следующего подхода.
Коротко:
В Windows плагин Shade объединял папки COM с com , потому что Windows обрабатывает их без учета регистра, поэтому, если пакет com уже создан, это только добавит содержимое COM вместо создания нового.
Решение:
В моем плагине shade я создал 2 jar-файла uber - один содержит COM-пакеты в верхнем регистре, а второй - со всеми другими зависимостями. Это решило проблему, потому что не было конфликта с com в первом банке, поскольку он содержал только COM .
Конфигурация, которую я использовал, была взята из этого поста.
В основном в первом блоке выполнения я включил артефакты, содержащие COM-пакеты, и исключил их из второго блока выполнения:
Блок исполнения 1:
<include><artifact_name_with_COM_package></include>
Блок исполнения 2:
<exclude><artifact_name_with_COM_package></exclude>
ПРИМЕЧАНИЕ: Еще раз, первый выбор должен заключаться в обеспечении соблюдения стандартов именования в пакетах. Но если вам нужен быстрый обходной путь, вы можете попробовать это.