Gradle 5.0: como corrigir recursos obsoletos e atualizar projeto Kotlin

Por que o Gradle grita "Recursos obsoletos" e o que fazer com isso?

Você já executou a compilação de um projeto Kotlin e viu a mensagem assustadora: Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0? Se sim — você não está sozinho. Esta pergunta acumulou milhares de visualizações no Stack Overflow, e hoje vamos analisá-la de ponta a ponta.

Imagine: você escreve em Kotlin, tudo funciona, mas o Gradle de repente começa a reclamar. Ele diz: "Ei, você está usando recursos antigos que removerei na versão 5.0!". É como se sua cafeteira favorita avisasse que amanhã não aceitará mais xícaras antigas. Desagradável, mas solucionável.

Neste artigo, não vamos apenas mostrar como remover o erro. Vamos comparar três abordagens de solução: desde o rápido "remendo" até a refatoração profissional. Você descobrirá por que o Gradle considera seu código obsoleto e como reescrevê-lo de forma moderna.

O que são recursos obsoletos no Gradle?

Funções obsoletas (deprecated) são aquelas partes da API que os desenvolvedores do Gradle planejam remover no futuro. Elas foram mantidas para compatibilidade reversa, mas não é mais recomendado usá-las. Quando você vê este aviso, o Gradle está literalmente dizendo: "Seu projeto será compilado agora, mas após a atualização para a versão 5.0 — não".

Na maioria das vezes, o problema está em:

\n
• Plugins desatualizados (por exemplo, versões antigas do kotlin-gradle-plugin)
\n
• Dependências implícitas (uso de compile em vez de implementation)
\n
• Scripts em Groovy que não foram adaptados para Kotlin DSL
\n
• Chamadas diretas a métodos obsoletos no build.gradle
\n

Abordagem 1: Solução rápida — suprimir avisos

O caminho mais simples (mas não o mais correto) é simplesmente dizer ao Gradle: "Cale a boca e funcione". É como tampar a luz do Check Engine com fita adesiva. O carro anda, mas os problemas permanecem.

Adicione no build.gradle.kts (Kotlin DSL) o seguinte bloco:

tasks.withType<Wrapper> {\n    gradleVersion = "4.10.3" // congelar versão\n}\n\n// Ou suprimir o aviso\nallprojects {\n    tasks.withType<AbstractCompile> {\n        options.isDeprecation = false\n    }\n}

Prós: rápido, não requer alterações no código, a compilação funciona.

Contras: você não resolve o problema, apenas o adia. Ao migrar para Gradle 5.0+, o projeto quebrará. Além disso, você perde importantes melhorias de desempenho e segurança.

Quando usar: apenas se precisar compilar o projeto com urgência e não houver tempo para refatoração. Mas agende uma solução adequada.

Abordagem 2: Migração para configurações modernas

Este é o "meio-termo". Você não apenas tapa o erro, mas organiza o projeto. Vamos analisar problemas típicos usando um exemplo de projeto Kotlin.

Substituir compile por implementation/api

A forma antiga de declarar dependências — compile — foi descontinuada desde o Gradle 3.0. Em vez dela, use implementation e api.

Antes (Groovy):

dependencies {\n    compile 'org.jetbrains.kotlin:kotlin-stdlib:1.3.72'\n    compile 'com.squareup.retrofit2:retrofit:2.9.0'\n}

Agora (Kotlin DSL):

dependencies {\n    implementation("org.jetbrains.kotlin:kotlin-stdlib:1.9.0")\n    implementation("com.squareup.retrofit2:retrofit:2.9.0")\n}

A diferença é simples: implementation oculta a dependência dos consumidores do módulo, acelerando a compilação. api a torna visível, como o antigo compile.

Atualizar o plugin Kotlin

Versões antigas do kotlin-gradle-plugin frequentemente usam APIs obsoletas do Gradle. Verifique a versão atual em kotlinlang.org e atu