3

したがって、dbの削除タスクとdbの作成タスク、サーバーの開始タスクとrunqatestタスクがあり、

  1. 独立したタスクがあるので、gradle dropdbを単独で（または他のタスクも）呼び出すことができます
  2. runqatestをdropdb、createdb、populatedb、startserverに依存させます

上記の2番は明らかに注文する必要があります。そうしないと壊れてしまい、gradleはantのように注文に従わなくなります。これを達成する方法は？（私はこの投稿でこれについてたくさん読んだ

http://markmail.org/thread/wn6ifkng6k7os4qn#query:+page:1+mid:hxibzgim5yjdxl7q+state:results

ただし、1。eはcとdに依存し、2。cはb、aに依存します。3。dはa、bに依存します。

eはcが最初になると決定するので、ビルドはb、a、c、dを実行するので、完全に決定論的です。順序が重要な場合はcとdを並列に実行できないため、antのように順序がある場合はビルドの並列化がはるかに難しいことに同意します（ユーザーの観点からはさらに悪いことに、ほとんどの場合は重要ではありません）時間）。

彼らがdependsOnOrderedを追加するだけなら、どうしても必要なときに注文を行うことができます。

または、私たちがこれを行うことになっている方法を誰かが知っていますか？この問題は2009年にgradleに対して提出されました!!!! 必要なときに注文したものを実行する方法については、まだgradleにドキュメントがありません。

ディーン

4

2 に答える 2

5

これが1つの解決策です：

if (gradle.startParameter.taskNames.contains("qatest") {
    qatest.dependsOn startServer
    startServer.dependsOn populatedb
    populatedb.dependsOn createdb
    createdb.dependson dropdb 
}

このアプローチの制限はqatest、がコマンドラインで提供される初期タスクの一部である場合にのみ機能することです。これで十分な場合もあります。チェックを追加して、ユーザーが間違いを犯さないようにすることができます。

これがより頻繁に必要な場合は、そのようなワークフローの宣言を容易にする小さなヘルパーメソッドを追加できます。のようなものworkflow(qatest, dropdb, createdb, populatedb, startserver)。

別のアプローチは、タスクの「クローン」を作成し、クローン間にタスクの依存関係（のみ）を追加することです。繰り返しますが、これを少し抽象化して隠すことができます。たとえば、とタスクcreateWorkflowTask("startServer") { ... }の両方を作成して構成できます。startServerstartServerWorkflow

要約すると、Gradleのプログラム可能性により、「ワークフロー」がまだGradleのファーストクラスの概念ではないという問題を克服することができます。

于 2013-01-28T19:37:35.833 に答える
3

Gradle 1.6は別のソリューションを追加しましたが、まだインキュベーション中です：mustRunAfter。リリースノートを参照してください。

于 2013-05-10T15:36:26.620 に答える