Use of code that is deprecated in Gradle 8.X and will be removed in Gradle 9 about axion-release-plugin HOT 6 OPEN

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.

from axion-release-plugin.

It probably concerns this line:

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

from axion-release-plugin.

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

from axion-release-plugin.

@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: gradle/gradle#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?

from axion-release-plugin.

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.

from axion-release-plugin.

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.

from axion-release-plugin.