2016-07-19 13 views
1

親プロジェクトからビルドディレクトリにいくつかのソースファイルをコピーし、コピーしたファイルの1つにトークンを上書きしようとするマルチプロジェクトgradleビルドがあります。すべて正常に実行されますが、ファイルは空になります。ここで交換するテンプレートを使用してファイルの抜粋です:Gradleコピーで空のファイルが作成される

--- 
# file: clients.yaml 
#properties shared by all client machines 

jmeter_version: "${jmeterVersion}" 

はここgradle.propertiesの抜粋です:

jmeterVersion=3.0 

そしてここでは、トリックを行うと仮定2つのタスクが

/** This task copies files from pdo-shared */ 
task copyFromCommonProject(type:Copy, dependsOn: configurations.commonProjectContent){ 
    from configurations.commonProjectContent.collect{ zipTree(it) } 
    into "$buildDir" 
    /*doLast { 
     updateAnsibleTokens.execute() 
    }*/ 
} 

task updateAnsibleTokens(type: Copy, dependsOn: copyFromCommonProject) { 
    from "$buildDir/commons/ansible/group_vars/clients.yml" 
    into "$buildDir/commons/ansible/group_vars/" 
    expand(jmeterVersion: "$jmeterVersion") 
} 

いる私はこれを親プロジェクトから実行します。gradle clean :tpcds-benchmark:updateAnsibleTokens

最初のタスクはすべてコピーします。ファイルはどこにあるのか期待どおりに動作しない2番目のタスクです

doLastセクションにコメントしてください。私はclient.ymlが完全に空

P.S.を終了doLastセクションのコメントを解除し、両方の場合において、第2のタスク

からdependsOn: copyFromCommonProjectを除去することによってgradle clean :tpcds-benchmark:copyFromCommonProjectように、これらの2つのタスクを実行しようとしましたexpand(jmeterVersion: "$jmeterVersion")行を無効にしても空のファイルが表示されます。いくつかのテストでは、ファイル自体をコピーすると空のファイルが生成されるため、おそらく私は間違っているようです。私が持っている同じコードは、目的地のディレクトリだけを変更すると動作します

+0

それは(同じファイルに、ソースとターゲット点として)それ自身の上にファイルをコピーしようとするかのように、第2のタスクが見えます。それは意図されていますか? –

+0

はい。元のファイルには、2番目のタスクの結果として更新する必要があるトークンが含まれています。 – Bostone

+0

@NikitaSkvortsov P.S.を参照してください。元の投稿で – Bostone

答えて

1

基本的に私はreread this manual sectionにライフサイクルをよく理解していなければなりませんでした。

私の元の例に続いて、意図した通りに動作する2つのタスクがあります。私が疑い始めた問題は、ソースからの実際のコピーが起きる前に、コンフィギュレーションサイクルでclient.ymlがコピーアンド変更しようとしていたということでした。追加なぜ第二のタスクの<<を追加するには、元のファイルが

/** This task copies files from pdo-shared */ 
task copyFromCommonProject(type:Copy, dependsOn: configurations.commonProjectContent){ 
    from configurations.commonProjectContent.collect{ zipTree(it) } 
    into "$buildDir" 
} 

task updateAnsibleTokens(type: Copy, dependsOn: copyFromCommonProject) << { 
    from "$buildDir/commons/ansible/group_vars/clients.yml" 
    into "$buildDir/commons/ansible/group_vars/" 
    expand(jmeterVersion: "$jmeterVersion") 
} 
+0

この場合、 'updateAnsibleTokens'タスクに' << 'は必要ありません。このタスクは 'Copy'タイプであるので、' from'と 'into'は設定フェーズで実行されます。 – Opal

+0

<<をスキップして空のファイルを取得した場合は、その質問を読みましたか? – Bostone

+0

次に、このタスクに 'Copy'型を割り当てるのは意味がありません。プロジェクトインスタンスで呼び出された' copy {} 'メソッドを使う方がはるかに良いでしょう。また、1つのタスクで十分であると思われます。 – Opal

0

をコピーした後の変更は、実行サイクルで起こっていた私は確認していないことを保証し、<<を助けました。それにも関わらず、解凍アーカイブは、はるかに自然な感じながら展開すること:

task copyFromCommonProject(type:Copy, dependsOn: configurations.commonProjectContent) { 
    from configurations.commonProjectContent.collect { 
     zipTree(it) 
    } 
    exclude "commons/ansible/group_vars/clients.yml" 
    with copySpec { 
     from configurations.commonProjectContent.collect { 
       zipTree(it) 
     } 
     include "commons/ansible/group_vars/clients.yml" 
     expand(jmeterVersion: "$jmeterVersion") 
    } 
    into "$buildDir" 
} 
+0

今試しました。空のgroup_varsフォルダで終了しました – Bostone

+0

'<<'は、2番目のコピーが同じ設定段階で実際のファイルがディスクにコピーされる前に実行されるため、動作します。それを実行ステージにプッシュすることによって、最初のコピーが完了した後に2番目のコピーが実行されることを保証するだけです。 – Bostone

+0

私は、評価ステージでコピーが行われず、コピータスクの設定を変更する_after_コピーはすでに完了している –

関連する問題