0

私のソースには、通常のソース コードに加えて、テストといくつかのテスト サポート コードの両方が含まれている状況があります。ソースとテスト サポートの両方を個別のアーティファクト (それぞれに独自の依存関係セットを持つ) として公開できるようにしたいのですが、明らかにテスト クラスは公開したくありません。

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

src/main/...
src/test/...
src/testsupport/...

いつものように、いくつかの依存関係を定義しています。

dependencies {
    compile 'com.sun.jersey:jersey-core:1.17.1'
    ... more compile dependencies...
    testCompile 'com.google.code.gson:gson:2.1'
    ... more testCompile dependencies...
}

テスト サポート sourceSet も必要です。

sourceSets {
    testSupport {
        java {
            srcDir 'src/testsupport/java'
        }
        resources {
            srcDir 'src/testsupport/resources'
        }
        compileClasspath += sourceSets.test.compileClasspath
        runtimeClasspath += sourceSets.test.runtimeClasspath
    }
}

testsupport コードには同じ依存関係があるため、テスト クラスパスを testSupport クラスパスに追加する必要があります。

最後に、アーティファクトを作成するために、次のものを用意しました。

task createTestSupportArtifact (type: Jar) {
    classifier = 'testsupport'
    from sourceSets.testSupport.output
}

artifacts {
    archives file: createTestSupportArtifact.archivePath, builtBy: createTestSupportArtifact
}

ただし、これらのアーティファクトに依存する私の他のリポジトリでは、testsupport アーティファクトの依存関係が取り込まれていません。理由についてはいくつかの理論があります (独自の POM がないか、スコープが実行時にテストされているかどうかがわかりません) が、具体的なものはありません。

これに対するより良いアプローチはありますか？configurations賢く使っているのではないでしょうか？

4

1 に答える 1

0

testSupport 構成で使用したいと思います。extendsFrom私は一連のテスト プロジェクトを作成しませんでしたが、コードが機能しているのに依存関係が機能していない場合、sourceSets ではなく構成に問題があることは論理的に理にかなっています。

新しい sourceSet を宣言すると、構成名に基づいて 2 つの新しい構成が自動的に取得されtestSupportCompileますtestSupportRuntime。以下を試して、通常の test deps を testSupport deps にリンクしてください。

configurations {
    testSupportCompile.extendsFrom testCompile
    testSupportRuntime.extendsFrom testRuntime
}

Gradle は公開時に構成を確実に使用します。testSupportXYZ 構成に明示的に何も追加しないため、後でサポート アーティファクトが必要になったときに解決する依存関係がないと判断されると思います。上記のコードは、ソースをリンクしたのと同じ方法で依存関係をリンクし、うまくいけば問題を解決するはずです。

于 2013-06-19T19:20:21.867 に答える