Warning: mkdir(): No space left on device in /var/www/group-telegram/post.php on line 37

Warning: file_put_contents(aCache/aDaily/post/rareilly/--): Failed to open stream: No such file or directory in /var/www/group-telegram/post.php on line 50
Ra'Reilly - Заметки про Android и не только | Telegram Webview: rareilly/183 -
Telegram Group & Telegram Channel
Пробежавшись по постам за год я понял, что безнадёжно отстаю от трендов. Во-первых я ни разу не поругал дядюшку Боба, а во-вторых ни разу не бомбил про Gradle (предупреждение о сломанном релизе не в счёт). Негоже уходить в новый год с такими пробелами, поэтому буду исправляться. Хотя бы частично.

С дядюшкой Бобом и без меня неплохо справляются, я бы мог разве что на его стороне выступить, но это не модно. А про Gradle мне есть что сказать. Если у вас в этот момент возникла мысль "прочитаю лучше после праздников", подумайте, хотите ли вы начинать год с Gradle.

Существует много причин не любить Gradle, но меня больше всего раздражает его "хрупкость". Есть много способов сделать одно и то же, но только один из них правильный, а остальные приведут к замедлению конфигурации проекта, несовместимости с configuration cache или проект вообще перестанет собираться.

Речь, конечно, про lazy API. Это прям штука про которую нужно знать сразу, как только начинаешь делать в Gradle что-то сложнее чем объявление зависимостей. Но не стоит терять бдительность после прочтения документации. Допустим, ты знаешь, что нужно использовать tasks.named("javadoc") , а tasks.getByName("javadoc") в большинстве случаев не нужно, так как этот вызов создаёт запрошенный таск на месте вместо того чтобы возвращать ленивый провайдер. Но что если нужно сразу сконфигурировать этот таск? Вроде всё просто:
tasks.named("javadoc") { enabled = false }


А если хотим сконфигурировать все таски определённого типа? Можно написать так:
tasks.withType<Javadoc> { enabled = false }

И это будет ошибка. Если в withType передать лямбду, то под капотом вызывается withType<T>().all(configure), а all в моменте создаёт все таски в коллекции. Правильно будет делать так:
tasks.withType<Javadoc>()
.configureEach { enabled = false }


Хорошо, а если хотим выключать таски по какому-то условию? Например, по флажку в gradle.properties:
tasks.withType<Javadoc>().configureEach {
enabled = properties["tasks.javadoc"].toBoolean()
}

Ой-ой, опять ошибка! Нужно использовать findProperty("..."). Почему? Посмотрите документацию к getProperties... а, погодите, там ничего полезного не написано... тогда документацию к Project (скриншот снизу). Этот метод ищет "свойства" в более широком смысле — смотрит на поля convention'ов, Gradle-экстеншены, поля внутри Project, все таски, extras, причём не только для текущего проекта, но и для всех родительских. И все это собирается в одну большую Map'у. Привести это может к довольно неожиданным проблемам.

Так что в новом году желаю вам выбирать всегда правильные APIшки (и не только в Gradle). С Рождеством и Новым Годом :)

#gradle



group-telegram.com/rareilly/183
Create:
Last Update:

Пробежавшись по постам за год я понял, что безнадёжно отстаю от трендов. Во-первых я ни разу не поругал дядюшку Боба, а во-вторых ни разу не бомбил про Gradle (предупреждение о сломанном релизе не в счёт). Негоже уходить в новый год с такими пробелами, поэтому буду исправляться. Хотя бы частично.

С дядюшкой Бобом и без меня неплохо справляются, я бы мог разве что на его стороне выступить, но это не модно. А про Gradle мне есть что сказать. Если у вас в этот момент возникла мысль "прочитаю лучше после праздников", подумайте, хотите ли вы начинать год с Gradle.

Существует много причин не любить Gradle, но меня больше всего раздражает его "хрупкость". Есть много способов сделать одно и то же, но только один из них правильный, а остальные приведут к замедлению конфигурации проекта, несовместимости с configuration cache или проект вообще перестанет собираться.

Речь, конечно, про lazy API. Это прям штука про которую нужно знать сразу, как только начинаешь делать в Gradle что-то сложнее чем объявление зависимостей. Но не стоит терять бдительность после прочтения документации. Допустим, ты знаешь, что нужно использовать tasks.named("javadoc") , а tasks.getByName("javadoc") в большинстве случаев не нужно, так как этот вызов создаёт запрошенный таск на месте вместо того чтобы возвращать ленивый провайдер. Но что если нужно сразу сконфигурировать этот таск? Вроде всё просто:

tasks.named("javadoc") { enabled = false }


А если хотим сконфигурировать все таски определённого типа? Можно написать так:
tasks.withType<Javadoc> { enabled = false }

И это будет ошибка. Если в withType передать лямбду, то под капотом вызывается withType<T>().all(configure), а all в моменте создаёт все таски в коллекции. Правильно будет делать так:
tasks.withType<Javadoc>()
.configureEach { enabled = false }


Хорошо, а если хотим выключать таски по какому-то условию? Например, по флажку в gradle.properties:
tasks.withType<Javadoc>().configureEach {
enabled = properties["tasks.javadoc"].toBoolean()
}

Ой-ой, опять ошибка! Нужно использовать findProperty("..."). Почему? Посмотрите документацию к getProperties... а, погодите, там ничего полезного не написано... тогда документацию к Project (скриншот снизу). Этот метод ищет "свойства" в более широком смысле — смотрит на поля convention'ов, Gradle-экстеншены, поля внутри Project, все таски, extras, причём не только для текущего проекта, но и для всех родительских. И все это собирается в одну большую Map'у. Привести это может к довольно неожиданным проблемам.

Так что в новом году желаю вам выбирать всегда правильные APIшки (и не только в Gradle). С Рождеством и Новым Годом :)

#gradle

BY Ra'Reilly - Заметки про Android и не только




Share with your friend now:
group-telegram.com/rareilly/183

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

Markets continued to grapple with the economic and corporate earnings implications relating to the Russia-Ukraine conflict. “We have a ton of uncertainty right now,” said Stephanie Link, chief investment strategist and portfolio manager at Hightower Advisors. “We’re dealing with a war, we’re dealing with inflation. We don’t know what it means to earnings.” These entities are reportedly operating nine Telegram channels with more than five million subscribers to whom they were making recommendations on selected listed scrips. Such recommendations induced the investors to deal in the said scrips, thereby creating artificial volume and price rise. He said that since his platform does not have the capacity to check all channels, it may restrict some in Russia and Ukraine "for the duration of the conflict," but then reversed course hours later after many users complained that Telegram was an important source of information. Since its launch in 2013, Telegram has grown from a simple messaging app to a broadcast network. Its user base isn’t as vast as WhatsApp’s, and its broadcast platform is a fraction the size of Twitter, but it’s nonetheless showing its use. While Telegram has been embroiled in controversy for much of its life, it has become a vital source of communication during the invasion of Ukraine. But, if all of this is new to you, let us explain, dear friends, what on Earth a Telegram is meant to be, and why you should, or should not, need to care. Anastasia Vlasova/Getty Images
from sa


Telegram Ra'Reilly - Заметки про Android и не только
FROM American