Use of code that is deprecated in Gradle 8.X and will be removed in Gradle 9

[adenhartog]

Reproduction scenario:

• Create a new (empty) Gradle project with Gradle 8.4 (for simplicity: without subprojects)
• Apply the Base Plugin in the plugins block (Gradle builtin plugin)
• Apply the latest version of the Axion Release Plugin in the plugins block
• Run ./gradlew build --warning-mode=all

Note: we apply the Base Plugin to have a build task. It is otherwise not relevant to the scenario.

Example plugins block in build.gradle.kts (kotlin script):

plugins {
    base
    id("pl.allegro.tech.build.axion-release") version "1.15.5"
}

Result:

> Configure project :
The Provider.forUseAtConfigurationTime method has been deprecated. This is scheduled to be removed in Gradle 9.0. Simply remove the call. Consult the upgrading guide for further information: https://docs.gradle.org/8.4/userguide/upgrading_version_7.html#for_use_at_configuration_time_deprecation

[adenhartog]

It probably concerns this line:

https://github.com/allegro/axion-release-plugin/blob/6f89fdd9e1807cea86ac5a86450e4f97101e1549/src/main/groovy/pl/allegro/tech/build/axion/release/domain/BaseExtension.groovy#L23

For ease of use, the gradle link from the warning message:

https://docs.gradle.org/8.4/userguide/upgrading_version_7.html#for_use_at_configuration_time_deprecation

[bgalek]

hi! @adenhartog want to try and fix it?:)

[adenhartog]

Sure. Judging from the comment above the linked line, the offending method call should be removed and then the unit tests should be fixed. I would guess the ideal fix would let the test use the lazy provider construction properly and/or fix a timing issue. If you have any other thoughts on the form of the desired fix, please let me know.

[adenhartog]

@bgalek

When removing the offending method call one example of the failing tests is RepositoryConfigFactoryTest with java.lang.IllegalStateException: Cannot obtain value from provider of Gradle property 'release.customKeyPassword' at configuration time. Use a provider returned by 'forUseAtConfigurationTime()' instead

The errormessage is a little different but it appears to be related to: https://github.com/gradle/gradle/issues/17638 which has not been fixed yet. Essentially, the test is trying to do something that is not supported by the Gradle ProjectBuilder yet.

I have tried to manipulate the project to be in the executed state but that doesn't work:

• ((ProjectInternal) project).evaluate()
• ((ProjectInternal) project).state.configured()

Since the relevant Extension in test is created by the Gradle Project (project.objects.newInstance(RepositoryConfig, ...)) it is difficult to inject a spy or mock. I don't see an easy fix. The relevant testcases could be moved to an integrationtest, but that seems like a lot of work to check a property.convention(providers.gradleProperty(...)) construction. Another option is to request that Gradle issue 17638 is resolved no later than the Gradle 9 release, but it currently does not seem to be high on the priorities list at Gradle. What do you think? Any other ideas?

[adenhartog]

Another option would be to not have a convention based on a Gradle property at all. This would mean the user would have to set the property in a buildscript extension and not in the gradle.properties file, or could set the extension property with their own Gradle property. For commandline arguments that are specific to certain tasks, task options could be used instead of Gradle properties. I haven't looked deeply into it, but on the surface it seems the RepositoryConfig properties could also be ReleaseTask/PushReleaseTask options.

[twbecker]

If there isn't a viable path to fixing this test in the short term, I'd humbly suggest disabling it, and releasing a version that does not produce warnings. For those of us that try to keep our builds warning-free, this is a major annoyance. Once you have one warning, it's easy for additional ones to creep in unnoticed.

[Ushiramaru]

Hello @bgalek, may I ask you do you have plan to fix or silence this warning in near feature?

[bgalek]

@Ushiramaru ultimately yes, but I don't know ETA, I'll be happy to accept a PR with a fix :)

[kkocel]

Fear no more @bgalek PR pending ;)

[bgalek]

will be fixed in next release :)