Пытаюсь понять свойства проекта gradle

#gradle

#gradle

Вопрос:

Очевидно, я не понимаю, что здесь происходит.

Я думаю, что prop2 и prop3 недоступны, потому что они являются переменными, а не «свойствами проекта».

Вопрос возник потому, что я хотел бы, чтобы переменные prop2 и prop3 были видны из метода «doTheThing ()», но я не хочу их передавать. Я хочу, чтобы переменные были глобально доступны для задач, методов и классов (но только изнутри самого сценария сборки) — и я хочу, чтобы они были типизированы (именно поэтому определение prop1 неприемлемо).

На самом деле, я думаю, что я прошу о некоторой помощи в понимании того, что такое свойство проекта Gradle и что на самом деле делает синтаксис ‘prop1 = «blah»‘.

Я прочитал руководство пользователя Gradle, а также Gradle в действии — если они уже объясняют эту концепцию, пожалуйста, укажите мне на правильный раздел (возможно, я пропустил его в то время, не понимая, что он говорил).

 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'
}
  

Комментарии:

1. Это также должно помочь: groovy.codehaus.org/Scoping and the Semantics of «def»

2. @Rodion — эта ссылка была весьма полезной, спасибо. Думаю, мне нужно провести еще несколько исследований, ориентированных на Groovy.

3. Для тех, кто хочет сделать подобное, мой текущий обходной путь для получения нужной мне функциональности — определить мои свойства для всего скрипта сборки в классе, подобном этому: class StaticProps { static String prop4 = System.getProperty("prop4", "wibble") } И затем использовать их следующим образом: System.getProperty("prop4", StaticProps.prop4)

4. Почему System.getProperty() дважды?

5. @Peter — Ошибка копирования-вставки; должно быть println $BuildProps.prop4

Ответ №1:

Когда вы объявляете переменную на самом внешнем уровне (как во втором и третьем операторах), она становится локальной переменной метода скрипта run . На самом деле это просто заводное поведение, и ничего, что Gradle может легко изменить.

Если вам нужен эквивалент глобальной переменной, просто присвоите значение несвязанной переменной (как в вашем первом утверждении). Это добавляет динамическое свойство к Project объекту Gradle, который виден во всем сценарии сборки (если он не затенен). Другими словами, prop1 = "blah" эквивалентно project.prop1 = "blah" .

Если вам нужен эквивалент типизированной глобальной переменной, вам придется подождать, пока Gradle обновится до Groovy 1.8, что делает это возможным с @Field помощью аннотации. Или вы пишете плагин, который смешивает объект соглашения с Project объектом (но это не подходит для специальных сценариев).

Комментарии:

1. Для всех, кто натыкается на это, теперь рекомендуется, чтобы при выполнении того, что предлагает Питер, вы вместо этого писали ext.prop1 = "blah" . Более старая методика все еще работает, но устарела и выдает предупреждение. Использование ext — это просто хороший способ явно указать, что вы намерены создать новое свойство. Если вы думаете, что используете существующее свойство и невольно создаете новое, это может быть ужасно неприятно, так что это, вероятно, довольно хорошее изменение.

2. Еще раз привет, Питер. Быстрый вопрос, я создал ext.blah = 'foobar' переменную в файле build.gradle верхнего уровня, но она не входит в область действия buildscript , есть идеи, почему?

3. Это должен быть отдельный вопрос (если он еще не существует).

4. Хорошо, справедливо, я создам его 🙂

5. @Bob ссылка на этот вопрос? Мне тоже интересно по этому вопросу!