0

マルチプロジェクトセットアップ（ProjectB-> ProjectA）があり、flatDirを使用して各プロジェクトに単一のlibディレクトリを指定しています。

ProjectA：

repositories {
    flatDir name: 'localRepository', dirs: 'lib'
}

dependencies {
    compile group: 'com.google.guava', name: 'guava', version: 'r08'
    compile group: 'com.miglayout', name: 'miglayout', version: '3.7.4'
    testCompile group: 'junit', name: 'junit', version: '4.+'
    testCompile group: 'org.easymock', name: 'easymock', version: '2.5.2'
}

ProjectB：

repositories {
    flatDir name: 'localRepository', dirs: 'lib'
}

dependencies {
    compile group: 'yan', name: 'yan', version: '5.0.2'
    runtime group: 'yan', name: 'jfunutil', version: '5.0.2'
    compile project(':ProjectA')
    testCompile group: 'junit', name: 'junit', version: '4.+'
    testCompile group: 'org.easymock', name: 'easymock', version: '2.5.2'

}

ProjectBに使用するgradle dependenciesと、正しい依存関係リストが生成され、ProjectAからの推移的な依存関係が示されます（例：guava-r08）。ただし、Iの場合gradle build、javacに使用される実際のクラスパスには、ProjectBの直接の依存関係と、ProjectAのビルドによって生成されたjarのみが含まれます。

もう1つの厄介な点は、testCompileのようです。ProjectBのjunitへの依存関係を再宣言する必要があります。そうgradle dependenciesしないと、成功しません。

どんなポインタも大歓迎です-私はGradleを初めて使用します。

4

3 に答える 3

1

プロジェクト構造について...

プロジェクトごとに 1 つではなく、単一の lib フォルダーを作成することをお勧めします。

ディレクトリ構造は次のようになります。

project/settings.gradle
project/ProjectA/lib
project/ProjectA/src
project/ProjectB/lib
project/ProjectB/src

サブプロジェクトごとに lib フォルダーが必要な特定の理由はありますか? これはより良いアイデアのようです：

project/settings.gradle
project/lib
project/ProjectA/src
project/ProjectB/src

以下を含むプロジェクトのルート (project/build.gradle) に build.gradle を作成できます。

subprojects{
   apply plugin: 'java'
   repositories {
        flatDir name: 'localRepository', dirs: "$rootProject.projectDir/lib"
   }
}

このようにして、すべての依存関係を project/lib にドロップできます。

テストの依存関係について...

testCompile の依存関係をこのルートの build.gradle ファイルに配置することもできます。あれは。。。になる：

subprojects{
   apply plugin: 'java'
   repositories {
        flatDir name: 'localRepository', dirs: "$rootProject.projectDir/lib"
   }
   dependencies{
        testCompile group: 'junit', name: 'junit', version: '4.+'
        testCompile group: 'org.easymock', name: 'easymock', version: '2.5.2'
   }
}

この方法では、各サブプロジェクトの build.gradle ファイルで testCompile 依存関係を指定する必要はありません。

ただし、ビルドをgradleすると、javacに使用される実際のクラスパスには、ProjectBの直接の依存関係と、ProjectAのビルドによって生成されたjarのみが含まれます。

ProjectB をコンパイルするには、ProjectA のみが必要です。ProjectA のみがコンパイルの依存関係です。ProjectA のコンパイル依存関係は、ProjectB の推移的な依存関係になります。

于 2011-05-17T01:01:54.737 に答える
0

前の回答に同意します。何度か試行した後、同じ構造が得られました

> shared
 - build.gradle
 - gradle.properties
 - settings.gradle
> project-a 
 - gradle.properties
 - settings.gradle
> project-b 
 - gradle.properties
 - settings.gradle

Shared にはすべての共通コードがあり、この場合、チェックイン、モジュールのデプロイ、コード品質 (cobertura)、コンパイルなどを処理します。 Shared は、サブプロジェクトによって継承されるクラスパスも定義し、サブプロジェクトによって追加の依存関係を追加できます。

あなたの問題について：

プロジェクト A で以下を定義しましたか?

settings.gradle includeFlat('Project B')

プロジェクト B で以下を定義しましたか?

settings.gradle includeFlat('Project A')

于 2011-05-19T12:29:16.060 に答える
0

元の投稿のビルド スクリプトは問題ありません。推移的な依存関係の解決が機能しない理由は、プロジェクトがその構成を解決するために独自のリポジトリのみを使用するためです。したがって、問題を解決する 1 つの方法は、lib ディレクトリを 1 つだけにすることです。もう 1 つの解決策は、A の lib ディレクトリを指す B の 2 番目のリポジトリを宣言することです。

別の煩わしさは、testCompile のようです。ProjectB の junit への依存関係を再宣言する必要があります。そうしないと、gradle の依存関係が成功しません。

ここであなたが何を言っているのかわかりませんが、上で説明したことの結果かもしれません。次の情報も役立つかもしれませtestCompileんtestRuntime。JUnit を必要とするプロジェクトごとに JUnit を宣言する必要があることが予想されます。繰り返しを避けるために、構成インジェクションを使用して、プロジェクト間の共通点を宣言できます。以前の回答では、これに関する具体的な例が既に示されています (例: subprojects { ... })。

于 2012-05-17T10:07:22.080 に答える