多数のnetbeansプロジェクトを構築して多数の環境にデプロイすることに関する機能の負荷をまとめる複雑なgradleスクリプトがあります。
このスクリプトは非常にうまく機能しますが、本質的にはすべて、プロジェクトと環境の情報を保持している半ダースのマップで構成されています。
タスクを別のファイルに抽象化し、単純なビルドファイルでマップを簡単に定義し、他のファイルからタスクをインポートできるようにします。このようにして、多くのプロジェクトで同じコアタスクを使用し、それらのプロジェクトを単純なマップセットで構成できます。
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ビルドファイルを含む多数のサブプロジェクトで構成されるすべての大きなプロジェクトで使用できるファイルです。
質問への答えはプラグインシステムにあることが判明しました。プラグインシステムでは、ディレクトリbuildSrc/src/main/groovy
。プラグインはJarとしてバンドルすることもできますが、私はこれを試していません。
詳細はこちら: カスタムプラグイン
0.9には新しい機能があります。 apply from: 'other.gradle'
コマンドを使用できます。
同じことに関する私の質問を読んでください: Gradleビルドの一般的な部分を分割/ファクタリングする方法があります
まあ、実際にビルドファイルを確認せずに、何があなたに最も役立つかを伝えるのは難しいです。
マルチプロジェクトビルドとして環境を整えることで、あなたが探している抽象化を提供できるはずです。
プロジェクトルートbuild.gradle
で、すべてのドメイン固有のものと、allサブプロジェクトに適用されるものを定義します。
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はさまざまなファイルで行われたすべての定義を自動的に考慮します。
また、ルートレベルでデフォルトプラグイン以外のプラグインをロードしない限り、プロジェクトルートに対してコンパイルタスクは実行されません。