Транзитная зависимость дополнительного транзистора подпроекта должна быть разрешена к существующему подпроекту

Question

, предположим, что следующий проект. мастер проект является мульти-проект, однако каждая часть более крупного проекта могут быть разработаны по отдельности или в смеси в:

/master/build.gradle 
/m1/build.gradle 
/m2/build.gradle 
/m3/build.gradle 

предположим, что m3 использует m2 и m2 использует m1 (m1 <- m2 <- m3)

присутствие m2 является факультативно многопроект со следующим расположением также разумно

/master/build.gradle 
/m1/build.gradle 
/m3/build.gradle 

но в этом случае m2 будет втянут из хранилища артефактов, что прекрасно ... однако m1 был транзитивной зависимостью m2, что хорошо, но как я могу сказать, что град использовать локальную версию m1 вместо испеченного артефакта?

Я застрял в этом, каждое место у меня есть, чтобы переопределить эту вещь. Gradle дает мне «просто» ModuleVersionSelector уровень доступа, как я могу добавить DefaultProjectDependency в соответствии с загруженными переходными зависимостями артефакта?

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

EDIT:

лучшее, что я придумал использует фильтр, используя resolutionStrategy, я создал пример путем дальнейшего развития проекта «Великий упруго-DEPS»

https://github.com/kgyrtkirk/elastic-deps

Answer 1

Планируемая функция - работа с динамическим подмножеством сборки Gradle. В то же время лучшим решением, которое я придумал, является введение новой нотации зависимостей, которая динамически сопоставляется либо с зависимостью проекта, либо от внешней зависимости. Вы можете найти здесь концептуальную концепцию: https://github.com/pniederw/elastic-deps

PS: Прежде чем приступать к реализации этой функции самостоятельно, передумайте, если она вам действительно нужна в этот момент. Вы можете сэкономить себе головную боль, ожидая, пока она официально не будет поддержана.

Answer 2

Начиная с elastic-deps и с помощью this answer (также от Peter) Я придумал трюк ниже.

В build.gradle верхнего уровня():

// make sure we've parsed the subproject dependencies 
evaluationDependsOnChildren() 

def subprojectsByName = subprojects.collectEntries { it -> [it.name, it] } 

subprojects.each { p -> 
    def hacks = [] // list of changes we're going to make 
    p.configurations.each { c -> 
    c.dependencies.each { d -> 
     if (d.group.startsWith("my.group.prefix")) { 
     def sub = subprojectsByName[d.name] 
     if (sub != null) { 
      hacks.add({ 
      // can't do this immediately or we'll get ConcurrentModificationExceptions 
      c.dependencies.remove(d) 
      p.dependencies.add(c.name, sub) 
      }) 
     } 
     } 
    } 
    } 
    // Now we can safely apply the changes 
    for (hack in hacks) { 
    hack() 
    } 
} 

Хорошая вещь о том, что в отличие от elastic-deps вы не должны изменять подпроектов.

У этой проблемы по-прежнему возникает проблема, что, как только вы попадаете в бинарную зависимость, любые чисто транзитивные зависимости разрешаются как двоичные. Например., Скажем, у меня есть проект cyan, который напрямую зависит от green и blue и транзитивно, через green, на yellow:

compile - Compile classpath for source set 'main'. 
+--- my.shared:blue:+ -> 2.0-SNAPSHOT 
+--- my.shared:green:+ -> 2.0-SNAPSHOT 
| +--- my.shared:yellow:+ -> 2.0-SNAPSHOT 
| \--- my.shared:blue:+ -> 2.0-SNAPSHOT 

Теперь, если я добавлю blue и yellow к моей мульти-модуль проекта, но не green, я получаю :

compile - Compile classpath for source set 'main'. 
+--- com.iii.shared:green:+ -> 2.0-SNAPSHOT 
| +--- com.iii.shared:yellow:+ -> 2.0-SNAPSHOT 
| \--- com.iii.shared:blue:+ -> project :blue 
\--- project :blue 

Обратите внимание, что blue правильно решен в проекте, даже если это транзитивно, но yellow нет.

Лично я считаю, что это функция, а не ошибка - она ​​отражает то, что на самом деле произойдет во время распространения. Я могу внести все изменения в yellow. Я хочу, но если я не положу новый артефакт yellow в свой репозиторий, а также обновленный green с обновленной зависимостью, тогда фактический выпуск не получит эти изменения.