Вопрос не только в том, какие цели связаны с какими фазами жизненного цикла проектов POM. Если бы это было так, то связывание цели «пакета» решило бы проблему.
При создании многомодульного проекта Maven считывает POM всех модулей, чтобы определить зависимости между модулями, чтобы он мог построить зависимые модули перед зависимыми модулями. Это может быть достигнуто даже при выполнении цели «package» (такой, что зависимые модули еще не находятся в локальном хранилище).
Следовательно, код, который создает путь к классам для сборок, должен управлять несколькими случаями, в частности:
- зависимость JAR вне проекта, где он ищет POM в локальном хранилище, обрабатывает его зависимости и добавляет JAR-файл POM в classpath
- внепроектная зависимость pom, где она ищет POM в локальном хранилище и обрабатывает свои зависимости
- внутрипроектная зависимость jar, где она ищет POM в дереве проекта, обрабатывает его зависимости и добавляет папку target / classes этого модуля в classpath
- внутрипроектная зависимость pom, когда по какой-то причине она не ищет POM в дереве проекта и поэтому не обрабатывает свои зависимости.
Обратите внимание на асимметрию в двух последних случаях по сравнению с первыми двумя.
Я вижу два решения вашей проблемы. Один из них - подать отчет об ошибке, или, скорее, запрос на изменение поведения (поскольку он явно преднамеренный), возможно, только в случае внутрипроектных зависимостей от многомодульных проектов. Или действительно предложить патч. Но так как поведение является преднамеренным, вы можете встретить отказ. В лучшем случае вас ждет долгое ожидание. (Хотя я бы проголосовал за ваше сообщение об ошибке - меня ужалило то же поведение в другом контексте.)
Другое решение - просто запустить установку в вашем проекте. Я не очень понимаю, почему вам не нужен проект POM в вашем репозитории: при необходимости вы можете использовать репозиторий моментальных снимков, где не важно, часто ли что-то меняется, чтобы избежать загрязнения вашего основного репозитория.