Многомодульный проект Maven и использование моджо агрегатного типа ⇐ JAVA

[Anonymous]

Не уверен, является ли это ошибкой maven или неспособностью с нашей стороны использовать maven по назначению, поэтому сначала спрашиваю здесь, вместо того, чтобы переходить непосредственно к apache jira. Касается maven v.3.9.0, но, похоже, это произошло также с v.3.9.6 и последней версией 4.0.0-alpha-13.
В нашем проекте мы используем настройку многомодульной сборки maven. (100+ модулей). Полная сборка всех модулей занимает более часа, поэтому мы используем плагин maven gitflow-incremental-builder для создания подмножества, подходящего для разных этапов процесса разработки. Например, PR-сборка собирает только измененные модули + зависящие от них. В CI у нас есть конвейер, который после успешной сборки PR с использованием maven-release-plugin создает jar-файл выпуска только из измененных модулей и развертывает их в Azure Artifacts.
Одно. Здесь следует отметить, что мы широко используем диапазоны, чтобы зависеть от созданных нами jar-файлов. Кажется, в сообществе существуют давние разногласия по поводу того, как должны соотноситься диапазоны и снимки. Так что, возможно, это тоже часть проблемы.
Путь к классам PR-сборки состоит из jar-файлов моментальных снимков, запеченных во время одной и той же многомодульной сборки, а также последних версий выпусков из нашего удаленного репозитория в Azure для модулей, отсутствующих в подмножество модулей сборки PR. Некоторое время назад мы начали сталкиваться с сбоями сборки PR из-за того, что диапазоны зависимостей не разрешались в моментальном снимке, созданном ранее во время той же сборки, а вместо этого получали последнюю версию выпуска из удаленного репозитория. Это произошло даже несмотря на то, что моментальный снимок находился в локальном репозитории, и версию моментального снимка (например, 1.2.3-SNAPSHOT) следует считать более поздней, чем предыдущая версия выпуска (например, 1.2.2). После некоторой отладки на maven я заметил, что выполнение моджо агрегатного типа (в нашем случае serenity-maven-pluginsагрегат-цель) приводит к разрешению зависимостей для всех модулей/проектов, которые на тот момент еще этого не сделали. Это происходит в середине модулей, и в дальнейшем использованные диапазоны не будут повторно разрешаться, а отсутствующие jar-файлы снимков еще предстоит создать позже во время этой сборки.
Код Maven, похоже, требует поворот на неправильный путь на org.apache.maven.lifecycle.internal.Mojoexcutor.java:252

Код: Выделить всё

public void ensureDependenciesAreResolved(MojoDescriptor mojoDescriptor, MavenSession session, DependencyContext dependencyContext) throws LifecycleExecutionException {
MavenProject project = dependencyContext.getProject();
boolean aggregating = mojoDescriptor.isAggregator();
Collection scopesToCollect;
Collection scopesToResolve;
if (dependencyContext.isResolutionRequiredForCurrentProject()) {
scopesToCollect = dependencyContext.getScopesToCollectForCurrentProject();
scopesToResolve = dependencyContext.getScopesToResolveForCurrentProject();
this.lifeCycleDependencyResolver.resolveProjectDependencies(project, scopesToCollect, scopesToResolve, session, aggregating, Collections.emptySet());
dependencyContext.synchronizeWithProjectState();
}

Iterator var8;
MavenProject aggregatedProject;
if (aggregating) {
scopesToCollect = this.toScopes(mojoDescriptor.getDependencyCollectionRequired());
scopesToResolve = this.toScopes(mojoDescriptor.getDependencyResolutionRequired());
if (dependencyContext.isResolutionRequiredForAggregatedProjects(scopesToCollect, scopesToResolve)) {
var8 = session.getProjects().iterator();

while(var8.hasNext()) {
aggregatedProject = (MavenProject)var8.next();
if (aggregatedProject != project) {
// !!!! Starts resolving all projects in current maven session !!!!
this.lifeCycleDependencyResolver.resolveProjectDependencies(aggregatedProject, scopesToCollect, scopesToResolve, session, aggregating, Collections.emptySet());
}
}
}
}

Рассматриваемый Mojo просто создает кучу целевых html-файлов отчетов, касающихся некоторых тестов Cucumber, поэтому мы просто решили пока его отключить, но я хотел бы сообщить об этом поведении в В случае, если это не просто ошибка пользователя (что вполне может быть). Любая информация приветствуется.
Ожидается: диапазоны зависимостей в модулях не должны быть преобразованы в фактическую версию до сборки самого модуля.

Подробнее здесь: https://stackoverflow.com/questions/784 ... e-of-mojos