2011-10-10 15 views
10

Chiaramente non capisco cosa sta succedendo qui.Cercando di capire le proprietà del progetto gradle

Suppongo che non sia possibile accedere a prop2 e prop3 perché sono variabili anziché "proprietà del progetto".

La domanda è nata perché vorrei che le variabili prop2 e prop3 fossero visibili all'interno del metodo "doTheThing()", ma non voglio doverle passare. Voglio che le variabili siano accessibili a livello globale a compiti, metodi e classi (ma solo all'interno dello script di compilazione stesso) - e voglio che vengano digitati (ecco perché la definizione di prop1 non è accettabile).

In realtà, tuttavia, credo che ciò che sto chiedendo sia un po 'di aiuto per capire che cosa sia una proprietà del progetto Gradle e quale sia la sintassi "prop1 =" blah "" in realtà.

Ho letto la guida utente Gradle e anche Gradle in Action - se già spiegano questo concetto, per piacere indicatemi la sezione giusta (forse l'ho sorvolato al momento non capendo cosa stia dicendo).

prop1 = "blah" 
String prop2 = "bleah" 
def prop3 = "blargh" 

task testPropAccess << { 
    println "1: $prop1" 
    println "2: $prop2" 
    println "3: $prop3" 
    doTheThing() 
} 

private void doTheThing(){ 
    println "4: $prop1" 
    println "5: $prop2" // error: Could not find property 'prop2' on root project 'script' 
    println "6: $prop3" // error: Could not find property 'prop3' on root project 'script' 
} 
+0

Questo dovrebbe anche aiutare: http://groovy.codehaus.org/Scoping+and+the+Semantics+of+%22def%22 – rodion

+0

@Rodion - quel collegamento è stato molto utile, grazie. Credo di aver bisogno di fare qualche altra ricerca orientata Groovy. – Shorn

+0

Per chi cerca di fare qualcosa di simile, la mia soluzione attuale per ottenere la funzionalità che voglio è definire le mie proprietà build-script wide in una classe come questa: 'class StaticProps { static String prop4 = System.getProperty (" prop4 " , "ciccio") } ' E poi li usano come questo: System.getProperty ("prop4"', StaticProps.prop4) '' Perché – Shorn

risposta

19

Quando si dichiara una variabile al livello più esterno (come nel vostro secondo e terzo economico), diventa una variabile locale del metodo dello script run. Questo è solo un comportamento Groovy e nulla che Gradle possa facilmente cambiare.

Se si desidera l'equivalente di una variabile globale, è sufficiente assegnare un valore a una variabile non associata (come nella prima istruzione). Questo aggiunge una proprietà dinamica all'oggetto Project di Gradle, che è visibile in tutto lo script di build (a meno che non sia in ombra). In altre parole, prop1 = "blah" equivale a project.prop1 = "blah".

Se si desidera l'equivalente di una variabile globale tipizzata, è necessario attendere fino a che Gradle non si aggiorna a Groovy 1.8, il che lo rende possibile con l'annotazione @Field. Oppure scrivi un plugin che combina un oggetto con convenzione nell'oggetto Project (ma non è adatto per gli script ad-hoc).

+16

Per tutti coloro che si imbattono in questo, è ora raccomandato che quando si fa ciò che Peter suggerisce si scrive invece' ext.prop1 = "blah" '. La vecchia tecnica funziona ancora ma è deprecata e genera un avvertimento. L'utilizzo di ext è solo un modo carino per affermare esplicitamente che si intende creare una nuova proprietà. Se pensi di usare una proprietà esistente e involontariamente ne stai facendo una nuova può essere terribilmente frustrante, quindi questo è probabilmente un bel cambiamento. –

+0

Ciao di nuovo Peter. Domanda veloce, ho creato una variabile 'ext.blah = 'foobar'' nel file build.gradle di livello superiore ma non è in scope per' buildscript', qualche idea sul perché? – Bob

+0

Questa dovrebbe essere una domanda separata (se non esiste già). –

Problemi correlati