103

私は複雑な Gradle スクリプトを持っています。これは、多数の NetBeans プロジェクトの構築と多数の環境への配備に関連する多数の機能をまとめたものです。

スクリプトは非常にうまく機能しますが、基本的には、プロジェクトと環境の情報を保持する 6 個のマップを介して構成されます。

単純なビルド ファイルでマップを簡単に定義し、他のファイルからタスクをインポートできるように、タスクを別のファイルに抽象化したいと考えています。このようにして、同じコア タスクを多数のプロジェクトに使用し、これらのプロジェクトを単純な一連のマップで構成できます。

Antのタスクと同様の方法で、あるGradleファイルを別のGradleファイルにインポートする方法を誰か教えてもらえますか? これまでのところ、Gradle のドキュメントを調べても役に立ちませんでした。

追加情報

以下のトムの回答の後、私は自分の言いたいことを正確に理解しようと思いました.

基本的に、いくつかのサブプロジェクトを実行する Gradle スクリプトがあります。ただし、サブプロジェクトはすべて NetBeans プロジェクトであり、独自の ant ビルド スクリプトが付属しているため、Gradle でこれらのそれぞれを呼び出すタスクがあります。

私の問題は、ファイルの先頭に次のような構成があることです。

projects = [
    [name:"MySubproject1", shortname: "sub1", env:"mainEnv", cvs_module="mod1"],
    [name:"MySubproject2", shortname: "sub2", env:"altEnv", cvs_module="mod2"]
]

次に、次のようなタスクを生成します。

projects.each({
    task "checkout_$it.shortname" << {
         // Code to for example check module out from cvs using config from 'it'.
    }
})

私はこの種のタスク生成スニペットをたくさん持っていますが、それらはすべて一般的なもので、プロジェクト リストの構成に完全に依存しています。

だから私が欲しいのは、これを別のスクリプトに入れて、次のような方法でインポートする方法です:

projects = [
    [name:"MySubproject1", shortname: "sub1", env:"mainEnv", cvs_module="mod1"],
    [name:"MySubproject2", shortname: "sub2", env:"altEnv", cvs_module="mod2"]
]

import("tasks.gradle") // This will import and run the script so that all tasks are generated for the projects given above.

したがって、この例では、tasks.gradle にすべての汎用タスク生成コードが含まれ、メインの build.gradle ファイルで定義されたプロジェクトに対して実行されます。このように、tasks.gradle は、NetBeans ant ビルド ファイルを含む多数のサブプロジェクトで構成されるすべての大規模プロジェクトで使用できるファイルです。

4

4 に答える 4

140

0.9 には新しい機能があります。コマンドを使用できますapply from: 'other.gradle'。

同じことについての私の質問を読んでください: Is there a way to split/factor out of common parts of Gradle build

于 2010-04-07T05:48:46.810 に答える
17

質問に対する答えは、プラグイン システムにあることが判明しました。このシステムでは、ディレクトリにあるグルーヴィーなファイルであるプラグインのセットに必要な機能を追加できますbuildSrc/src/main/groovy。試したことはありませんが、プラグインを Jar としてバンドルすることもできます。

詳細はこちら:カスタム プラグイン

于 2011-08-30T09:48:54.183 に答える
4

実際にビルド ファイルを確認しないと、何が最適かを判断するのは困難です。

環境をマルチプロジェクト ビルドとして設定すると、探している抽象化が提供されるはずです。

プロジェクト ルート build.gradleでは、すべてのドメイン固有のものと、すべてのサブプロジェクトに適用されるものを定義します。

repositories {
    add(new org.apache.ivy.plugins.resolver.FileSystemResolver()) {
        name = 'destRepo'
        addIvyPattern( file( project.properties['repo.dest.dir']).absolutePath + '/[organisation]/[module]/ivys/ivy(-[revision]).xml')
        addArtifactPattern( file( project.properties['repo.dest.dir']).absolutePath + '/[organisation]/[module]/[type]s/[artifact](-[revision]).[ext]')
        descriptor = 'optional'
        checkmodified = true
    }
    ...
}
...
subprojects {
    sourceCompatibility = 1.5
    targetCompatibility = 1.5
    group = 'my.group'
    version = '1.0'
    uploadArchives {
        uploadDescriptor = true
        repositories {
            add rootProject.repositories.destRepo
        }
    }
    apply{ type my.group.gradle.api.plugins.MyPlugin }
    ...
}

dependsOnChildren()

プロジェクトのルート ディレクトリにはgradle.properties、プロジェクトで使用するプロパティを定義するファイルが含まれている場合もあります。

buildDirName=staging
repo.dest.dir=/var/repo
...

次に、名前の付いたプロジェクトルートからの追加ファイルで、settings.gradle実際にサブプロジェクトを指します。

include 'my-first-component',
        'my-second-component'
...
project(':my-first-component').projectDir = new File(rootDir, 'path/to/first/component')
project(':my-second-component').projectDir = new File(rootDir, 'path/to/second/component')
...

各サブプロジェクト ディレクトリにはbuild.gradle、サブプロジェクト固有のもののみを含むファイルが含まれます。

gradleプロジェクト ルートまたはサブプロジェクト ディレクトリから呼び出す場合でも、gradle はさまざまなファイルで行われたすべての定義を自動的に考慮します。

また、ルート レベルでデフォルト プラグイン以外のプラグインをロードしない限り、プロジェクト ルートに対してコンパイル タスクが実行されないことにも注意してください。

于 2010-02-19T00:19:01.353 に答える