1

次のプロジェクトを想定します。マスター プロジェクトはマルチ プロジェクトですが、より大きなプロジェクトのすべての部分は、個別に開発することも、混合して開発することもできます。

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

usesとuses ( m3_m2m2m1m1 <- m2 <- m3 )

の存在m2はオプションですが、次のレイアウトのマルチプロジェクトも合理的です

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

しかし、この場合m2、アーティファクト リポジトリからプルされますが、これは問題ありません...ただしm1、推移的な依存関係は良好ですが、ベイクされたアーティファクトの代わりにm2ローカル バージョンを使用するように gradle に指示するにはどうすればよいですか?m1

私はこれにこだわっています.gradleをオーバーライドするためにアクセスできるすべての場所は、「ちょうど」ModuleVersionSelectorレベルのアクセスを提供DefaultProjectDependencyします.ダウンロードしたアーティファクトの推移的な依存関係に従って、どのように追加できますか?

アーカイブされたアーティファクトの完全な依存関係グラフにアクセスし、いくつかのオーバーライド/除外を入れることができれば、代替手段があるかもしれません。

編集：

私が思いついた最善の方法は、resolutionStrategy を使用してフィルターを使用することです。「elastic-deps」プロジェクトをさらに開発して例を作成しました

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

4

2 に答える 2

2

elastic-depsから始めて、この回答(ピーターからも)の助けを借りて、以下のトリックを思いつきました。

最上位の 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-depとは異なり、サブプロジェクトを変更する必要がないことです。

これには、バイナリ依存関係にヒットすると、純粋に推移的な依存関係がバイナリとして解決されるという問題がまだあります。たとえば、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とを追加し、を追加しないと、次のようになります。yellowgreen

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、更新された依存関係で更新されていない場合、 の実際のリリースでcyanはそれらの変更が反映されません。

于 2014-05-09T22:28:26.073 に答える
1

Gradle ビルドの動的サブセットの操作は、計画されている機能です。それまでの間、私が思いついた最善の解決策は、プロジェクトの依存関係または外部の依存関係に動的にマップされる新しい依存関係の表記法を導入することです。ここで概念実証を見つけることができます: https://github.com/pniederw/elastic-deps

PS: この機能を独自に実装する前に、この時点で本当に必要かどうかを再検討してください。公式にサポートされるまで待つことで、頭の痛い問題を解決できるかもしれません。

于 2014-01-20T17:30:49.670 に答える