Зависимости транзитных проектов не найдены

Question

У меня есть плоская иерархия проектов с 4 проектами. Давайте называть их B, C, D, M, и они имеют следующие линейные зависимости:

B -> C -> M -> D

-> = "зависит от"

Проекты B, C и M имеют build.gradle и settings.gradle. Настройки.gradle всегда включает includeFlat для всех зависимых проектов. В случае B это будет includeFlat ('D', 'M', 'C'). build.gradle определяет, что всегда определяет зависимость от проекта, от которого он зависит. В случае B, который будет компилировать проект ('C').

Если я пытаюсь создать проект BI столкнуться с проблемой, что после разбора B, Gradle пытается разобрать build.gradle из C и терпит неудачу, потому что не могу найти М.

* What went wrong: 
A problem occurred evaluating project ':C'. 
> Project with path 'M' could not be found in project ':C'. 

Я думаю соответствующая часть отладочной:

Included projects: [root project 'B', project ':C', project ':D', project ':M'] 

кажется Gradle сортирует включают в алфавитном порядке, несмотря на то, что определено в других settings.gradle файлах и в зависимости build.gradle.

Когда я создал C, я также задавался вопросом, почему мне нужно включить D в настройки includeFlat. Но там он работает, потому что он заказывает включение в D, M.

Единственное «решение», которое я сейчас вижу, это то, что я удаляю зависимости проекта в B и зависит от сборки jar C. Но у этого есть огромный недостаток (нарушение игры), что, когда я что-то меняю в DI, нужно полная сборка, публикация и цикл «обновления от нексуса» до тех пор, пока изменения не будут видны. Поскольку C, M и D все еще находятся в активной разработке, это не вариант.

Чтобы исправить это, мне нужно будет сообщить плагину eclipse, что когда он обнаруживает зависимость jar, которая также является проектом, он добавляет зависимость проекта к пути к классам вместо зависимости jar.

Answer 1

У вас, кажется, есть некоторые заблуждения о том, как работают многопроектные сборки Gradle. Вот некоторые факты, которые могли бы помочь вам понять, что происходит:

• У Gradle build может быть только один settings.gradle.
• Порядок include утверждений в settings.gradle не имеет значения.
• Зависимости выполнения всегда между задачами, а не между проектами. Например, в зависимости от project(":M") это сокращение в зависимости от конфигурации default этого проекта. Gradle переводит это в зависимость от тех задач в M, которые отвечают за построение артефактов его конфигурации default.Обратите внимание, что в зависимости от проекта не означает, что все задачи в этом проекте будут выполняться перед любой задачей в зависимом проекте.
• Многопроектная сборка имеет логический иерархия проекта. ":M" - Абсолютный Путь к проекту (: обозначает корневой проект), тогда как "M" является родственником путь проекта. Относительные пути интерпретируются как относительно текущего проекта.

Чтобы получить более глубокое понимание нескольких проектов сборки, я рекомендую изучить «мульти-проект строит» глава в Gradle User Guide и несколько проектов создания образцов в полном распределении Gradle.

Answer 2

Весь беспорядок был вызван отсутствующим «:». Кажется, что Gradle проводит различие между compile project('M') и compile project(':M'), когда проект (в данном случае строка находится на C) входит в другой проект. Просто здание C отлично работает с обеими версиями. gradle projects возвращает одно и то же дерево для проекта C в обоих случаях.

Я не могу объяснить, в чем именно заключается разница, и я надеюсь, что кто-то может объяснить это мне.