2012-05-11 20 views
14

Avere un estratto https://github.com/gradle/gradle/blob/master/build.gradle:Configurazione personalizzata condizionale per il progetto Gradle

ext { 
    isDevBuild = { 
    gradle.taskGraph.hasTask(developerBuild) 
    } 
} 

task developerBuild { 
    description = 'Builds distributions and runs pre-checkin checks' 
    group = 'build' 
    dependsOn testedDists 
} 

Quando ho usato questo metodo per creare configurazione personalizzata nel mio progetto ho scoperto che:

isDevBuild === true 

cioè è sempre vero perché task 'developerBuild' è all'interno del mio progetto build.gradle, e quindi nel grafico. Hanno un paio di configurazioni "diverse" (isCIBuild, isCommitBuild, isFinalReleaseBuild, ...) quindi suppongo di avere qualcosa di sbagliato qui.

Qualcuno può spiegare come rendere condizionale questa configurazione in base a qualche parametro esterno?

risposta

35

taskGraph.hasTask() indica se un'attività è nell'attività esecuzione grafico, cioè se verrà eseguito. Perché il grafico esecuzione dell'attività viene creato solo dopo la fase di configurazione, questo metodo deve essere chiamato da un whenReady callback (o in fase di esecuzione):

gradle.taskGraph.whenReady { graph -> 
    if (graph.hasTask(developerBuild)) { 
     // do conditional configuration 
    } 
} 

per renderlo più leggibile, possiamo introdurre un nuovo metodo :

def onlyFor(task, config) { 
    gradle.taskGraph.whenReady { graph -> 
     if (graph.hasTask(task)) { 
      project.configure(project, config) 
     } 
    } 
} 

Ora possiamo scrivere:

onlyFor(developerBuild) { ... } 
onlyFor(ciBuild) { ... } 

altro, modo più semplice per risolvere questo problema è quello di verificare se un particolare nome attività è contenuto in gradle.startParameter.taskNames. Tuttavia, questo ha due limitazioni: in primo luogo, confronta il compito nomi, che può fare la differenza nelle versioni multiprogetto. In secondo luogo, troverà solo le attività che sono state specificate direttamente (ad es. Sulla riga di comando), ma non le sue dipendenze.

PS .: Nel codice, isDevBuild è sempre valido poiché una chiusura (non nulla) è true in base alla verità di Groovy. (A differenza di isDevBuild(), isDevBuild non chiamerà la chiusura.)

+0

Tornando all'asserzione dal libro "Building and Testing with Gradle": la conoscenza di Groovy non è completa: è un must iniziare a lavorare con Gradle. Grazie per l'aiuto. Verificherò più tardi oggi. –

+1

Non direi che è necessario per iniziare, ma è necessario implementare soluzioni avanzate come questa. (Un'alternativa semplice che richiede meno conoscenza di Groovy è quella di passare da una configurazione all'altra in base a una proprietà di sistema.) Di nuovo, molto di questo codice potrebbe essere scritto in stile Java (con classi interne anonime e simili), o letteralmente in Java se si spostato in un plug-in. La vera sfida in questo caso particolare è capire il lato gradle delle cose: l'API del grafico delle attività, la fase di configurazione e di esecuzione, ecc. –

+0

La tua soluzione funziona bene. Molte grazie. Per la nota che hai inserito in P.S. : Non posso chiamare direttamente 'isDevBuild()' quando eseguo Gradle build con 'ciBuild jar' per esempio (e non posso usare entrambe le configurazioni nello stesso tempo) - anche se hai dimostrato che posso chiamare la chiusura solo per scopi didattici. –

Problemi correlati