ConfigureUtil deprecation warning

[ben-manes]

fyi I noticed this in a build scan,

The org.gradle.util.ConfigureUtil type has been deprecated.
This is scheduled to be removed in Gradle 9.0.
Documentation

publish-plugin/src/main/kotlin/io/github/gradlenexus/publishplugin/DefaultNexusRepositoryContainer.kt

Line 32 in 0aea955

return sonatype(ConfigureUtil.configureUsing(closure))

[erichaagdev]

I've also started seeing this after upgrading to Gradle 7.6.

Build Scan: https://scans.gradle.com/s/ongbkxs4wvvba/deprecations?expanded=WyIzIl0&expanded-stacktrace=WyI1Il0&focused-stack-frame=0-0-2

[remal]

Looks like Project.configure() method should be used instead of ConfigureUtil.configureUsing()

[dili91]

I've also noticed the same since I bumped the wrapper to 7.6 inside one of my company's project 👀

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

If useful, here the build.gradle file

[nedtwigg]

8.0-rc-1 is out now. This issue will become a blocker pretty soon.

[TWiStErRob]

There's another callsite in the same file (curtesy of Mockito using this plugin):

The org.gradle.util.ConfigureUtil type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: https://docs.gradle.org/7.6/userguide/upgrading_version_7.html#org_gradle_util_reports_deprecations
        at org.gradle.util.ConfigureUtil.logDeprecation(ConfigureUtil.java:216)
        at org.gradle.util.ConfigureUtil.configureSelf(ConfigureUtil.java:192)
        at io.github.gradlenexus.publishplugin.DefaultNexusRepositoryContainer.configure(DefaultNexusRepositoryContainer.kt:42)
        at io.github.gradlenexus.publishplugin.DefaultNexusRepositoryContainer.configure(DefaultNexusRepositoryContainer.kt:27)
        at org.gradle.util.internal.ConfigureUtil.configure(ConfigureUtil.java:104)
        at org.gradle.util.internal.ConfigureUtil$WrappedConfigureAction.execute(ConfigureUtil.java:167)
        at io.github.gradlenexus.publishplugin.NexusPublishExtension.repositories(NexusPublishExtension.kt:57)
        at shipkit_91h1hqg1wr0a5t608js79f84t$_run_closure3.doCall(P:\projects\contrib\github-mockito\gradle\shipkit.gradle:22)
        at shipkit_91h1hqg1wr0a5t608js79f84t.run(P:\projects\contrib\github-mockito\gradle\shipkit.gradle:21)
        at build_e6jjcbuu9ezmj4rzb0cym1acv.run(P:\projects\contrib\github-mockito\build.gradle:35)

[TWiStErRob]

Note: Gradle recommends to work around the need for ConfigureUtil by following this approach: https://docs.gradle.org/7.6/javadoc/org/gradle/util/ConfigureUtil.html

[szpak]

8.0-rc-1 is out now. This issue will become a blocker pretty soon.

Luckily, they seem to postpone the removal to 9.0 ;-).

The org.gradle.util.ConfigureUtil type has been deprecated. This is scheduled to be removed in Gradle 9.0.

Anyway (from #157, part full-faced by me):

... because #152 is important and easy to fix and is remaining unfixed.

@nedtwigg If you provide a simple and elegant solution, preferably keeping Gradle 6+ compatibility, I will do my best to review your PR in a timely manner :-).

Key places in code:

publish-plugin/src/main/kotlin/io/github/gradlenexus/publishplugin/NexusPublishExtension.kt

Line 53 in ab77ce3

val repositories: NexusRepositoryContainer = DefaultNexusRepositoryContainer(

and:

publish-plugin/src/main/kotlin/io/github/gradlenexus/publishplugin/DefaultNexusRepositoryContainer.kt

Lines 27 to 43 in ab77ce3

	internal class DefaultNexusRepositoryContainer(delegate: NamedDomainObjectContainer<NexusRepository>) : NexusRepositoryContainer, NamedDomainObjectContainer<NexusRepository> by delegate {
	override fun sonatype(): NexusRepository = sonatype {}
	override fun sonatype(closure: Closure<*>): NexusRepository {
	return sonatype(ConfigureUtil.configureUsing(closure))
	}
	override fun sonatype(action: Action<in NexusRepository>): NexusRepository = create("sonatype") {
	nexusUrl.set(URI.create("https://oss.sonatype.org/service/local/"))
	snapshotRepositoryUrl.set(URI.create("https://oss.sonatype.org/content/repositories/snapshots/"))
	action.execute(this)
	}
	override fun configure(configureClosure: Closure<*>): NamedDomainObjectContainer<NexusRepository> =
	ConfigureUtil.configureSelf(configureClosure, this, NamedDomainObjectContainerConfigureDelegate(configureClosure, this))
	}

[TWiStErRob]

Luckily, they seem to postpone the removal to 9.0 ;-).

Do you know why? Because the plugin authors are not moving and Gradle don't want to break/overload end users. 😉

I also did a background investigation for a similar deprecated API which was quite a rollercoaster of commits. 😅

[nedtwigg]

@szpak Two options provided above! I would follow Gradle's recs and just remove the Closure interfaces (#161) but if you want to keep them I provided an option for that too in #160.

[szpak]

Thanks @nedtwigg. To be honest, before I wrote my comment, I've just removed the methods with Closure, but it broke functional tests (Gradle 6, AFAIR also 7).

As it is mentioned in the linked documentation:

Gradle automatically generates a Closure-taking method at runtime for each method with an Action as a single argument as long as the object is created with ObjectFactory.newInstance(Class, Object...).

which is nice, however, we create DefaultNexusRepositoryContainer manually. The ObjectFactory is there (project.objects), however, I am not familiar with the "recent" changes in the API (and my quick & dirty attempts failed), so maybe you could try to follow the recommended path to achieve that?

As you see in the CI build reports, both builds fail on CI :-/. To test it locally with functional tests, you can call ./gradlew compatTest with JDK 11 to cover lower Gradle version (btw, it is advised edit .shutter/java11.lock to keep there only 6.9.1 (or 6.0 if possible) and 7.6 to speed up testing - we can easily drop Gradle 5 support).

WDYT?

[ben-manes]

maybe you can use Groovy closures from Kotlin?

[vlsi]

maybe you can use Groovy closures from Kotlin?

There's no point in doing that.

Action<in T> should be enough for all the cases:

• It plays nicely in Kotlin
• It does specify the type of the receiver
• It works with Groovy as well (Gradle adds the needed overloads)

[TWiStErRob]

@nedtwigg @szpak using objects.newInstance is hard requirement for this to work "out of the box".

There are two issues here (two distinct usages of ConfigureUtil):

• Fixing configureUsing seems trivial, by way of newInstance. Raised Fix #152: remove usage of ConfigureUtil.configureUsing #162 to specifically fix this, this goes halfway in fixing this issue. Locally all tests passed for me on this with gradlew build -x spotlessKotlinCheck --console=verbose --continue.
• Fixing configureSelf seems like a bigger challenge. We essentially need to mimic how RepositoryHandler (Project.repositories), ArtifactHandler (Project.artifacts), ConfigurationContainer (Project.configurations) are created, but they're all using internal APIs. I have a feeling Fix deprecation warnings #160 (i.e. copy-paste) might be the only way. So far I've only faced failure trying to do this.

[TWiStErRob]

Raised gradle/gradle#23874 to maybe get help with removing configureSelf.

[szpak]

Thanks guys. I've merged #162 and will wait a while for any response in gradle/gradle#23874 before "copy-pasting" ConfigureUtil into our codebase (#160). Gradle 8.0 is out, but luckily, we have still some time for 9.0 ;-).

[TWiStErRob]

A quick update on this (and guidance for @szpak to navigate my contributions):

• ConfigureUtil.configureSelf doesn't seem to have a replacement gradle/gradle#23874
  no response from Gradle at the moment.
• Replace ConfigureUtil.configureSelf with configureEach #165
  raised by @vlsi is a potential fix,
  but it breaks existing Groovy users with non-idiomatic syntax, so @szpak is holding off on that.
• Workaround to "remove" the last usage of ConfigureUtil. TWiStErRob/nexus-publish-gradle-plugin#5
  a new (somewhat trivial) idea to "fix" this issue, or at least delay the problem for another year or two, @szpak / @vlsi / @nedtwigg thoughts?
• Update from Gradle 6.9 to Gradle 8.0 #168
  a separate PR to upgrade the tooling of this project, because the fix above requires compiling this project with Gradle 7.1.

@szpak, also while doing the above I found a few other opportunities for reducing tech debt:

• Refresh Stutter Locks #164
  Test on the latest Gradle versions, doing this sooner might've uncovered this issue via automation.
• Bump all major versions of GitHub actions #166
  Unrelated, just saw a lot of warnings on CI while looking at builds of my branches.
• Bump testing library versions #169
  Unrelated, just saw that they're out of date when upgrading Gradle (gradlew dependencyUpdates)
• Upgrade Spotless minor version and reformat #167
  Originally triggered by Gradle 8 upgrade, but I think their fixes are not blockers to using Gradle 8 (a warning for configuration cache and a fix for composite builds, neither of those are applicable here).

[nedtwigg]

In my view, the best thing is to remove Closure from the API, and I think the fix from @vlsi in #165 is the best fit. If I was Gradle, I would triage gradle/gradle#23874 to a very low priority - they have been pretty clear that plugin authors should just move to Action.

If keeping Closure for pre-7.0 Groovy users is important to you, I think the fix in #160 is the best way. But definitely bumping the minimum to Gradle 7 and removing the Closure from API should happen someday.

[szpak]

I would prefer to release one more version supporting Gradle 6+. To do so, I would sway for #160 (copy paste ConfigurationUtil to our code and remove the deprecation warning), replaced (after the release) with TWiStErRob#5 with bumping the minimal required Gradle version to 7.1 (and removing copied ConfigurationUtil).
I like the hacky #165 by @vlsi and it could be next, but it is a non-backward compatible change requiring probably version bump to 2.0.0 (unless we are able to find a way to use sonatype() in the Groovy DSL), so I still hope to have some feedback from Gradle in gradle/gradle#23874 before making a decision.

WDYT about this plan?

[nedtwigg]

Works for me!

[TWiStErRob]

My latest invention is backwards and forwards compatible on all supported versions. It doesn't matter what Gradle the build is using, only the jar it produces. So using the internal API temporarily is a good stopgap to support any version range. So there's no need to copy-paste and then delete it. Note: I can make a quick fix out of this without needing Gradle 7/8 upgrade too, because the class/interface is well-known, so reflection is fine.

[TWiStErRob]

By the time this becomes an issue again, hopefully we'll get some response from Gradle, but we can always fall back to copy-paste.

[vlsi]

I would triage gradle/gradle#23874 to a very low priority

I would disagree here.
As @TWiStErRob says, the current API does not allow clients create type-safe entities that extend NamedDomain...
Even you one uses Action, there's just no way to do that, especially in Groovy DSL.

I incline that solution I propose in gradle/gradle#23874 (comment) is a low-hanging fruit. At the end of the day, they could expose getTarget() and use it. It sounds like a trivial change that helps the ones who use domain collections.

So using the internal API temporarily is a good stopgap to support any version range

+1
There's no need to copy the code, as we'll detect it quite fast as they happen to remove the method/class.

[szpak]

My latest invention is backwards and forwards compatible on all supported versions. It doesn't matter what Gradle the build is using, only the jar it produces.

Oh, I missed that fact that it requires 7.1, but should work also with 6.x. Nice.

I locally cherry-picked that change to master (and Gradle migration to 7.1) and from the regression tests, it works with Gradle 6.8+ [1], which is enough. However, I'm more a Groovy guy than a Kotlin one. Do you think, Gradle 7 and its migration to Kotlin 1.4 could affect 6.x users? Or we should rather use a reflection and still build that next release with Gradle 6.9?

---

[1] - FYI. For lower Gradle versions (<6.8) I had:

Execution failed for task ':closeSonatypeStagingRepository'.
'void kotlin.jvm.internal.PropertyReference1Impl.(java.lang.Class, java.lang.String, java.lang.String, int)'

and:

Execution failed for task ':closeSonatypeStagingRepository'.
Could not initialize class io.github.gradlenexus.publishplugin.AbstractTransitionNexusStagingRepositoryTask$transitionStagingRepo$retrier$1$1

[remal]

Sorry if I got smth wrong, but what prevents you from using project.configure()? Doesn't this use ConfigureUtil internally?

[TWiStErRob]

I locally cherry-picked that change to master (and Gradle migration to 7.1)

Gradle migration to 7.1 is also non-trivial, you'll still need most of the changes in the Gradle 8 PR. Let's just merge that one and get through, @szpak.

FYI. For lower Gradle versions (<6.8) I had:

The PR (TWiStErRob#5) is against the Gradle 8 branch for a reason. The errors you've seen I went through and fixed each in the Gradle 8 PR.

Do you think, Gradle 7 and its migration to Kotlin 1.4 could affect 6.x users? Or we should rather use a reflection and still build that next release with Gradle 6.9?

If you merge the Gradle 8 PR, this project will build with Gradle 8, but it'll be compatible with all the Gradle 5-8 versions with all their Kotlin 1.3-1.8 range (it's similar to building with Java 17, but also targetCompatibility = 1.8). There's no need to drop support for anything to get it in. See the CI and manual QA on that PR, it's all good. @vlsi could you also have a look?

but what prevents you from using project.configure()?

Re @remal, actually I'll have to recheck, because I might've looked on Gradle 6.9 APIs, which could be missing an overload we need (that was added in Gradle 7.1), but Gradle 8 PR will still be necessary to be able to at least conditionally call the replacement API, if it exists.

[TWiStErRob]

@szpak re errors, have a read of the individual commit messages in the Gradle 8 PR, I tried to list all the problems and solutions I encountered.

[remal]

@TWiStErRob, as I can see, Project.configure(Object, Closure) has been there "forever". This method exists even in Gradle 1.0 (proof).

I've written a bunch of Gradle plugins but never used Kotlin's by delegate. Probably, because of that I'm missing something. I haven't used this method because Gradle API is evolving, and I don't want to depend on it by delegating in compile-time. For such cases, I have reflection-based proxies that do such delegation.

[TWiStErRob]

@remal I've tried to use Project.configure, you can see here: https://github.com/TWiStErRob/nexus-publish-gradle-plugin/commits/fix152_configureUsing_configureSelf, but now I realize I was calling the wrong overload, there's Project.configure(Iterable, Closure) which wins over (Object, Closure), because this thing is a NamedDomainObjectCollection. Now, I tried the "right" overload too, but it's a StackOverflowError, which makes sense, because this magical configure function we're overriding is called by the configuration mechanism. The problem is that NamedDomainObjectContainer implements Configurable, and that exception exists inside ConfigureUtil.configure (not configureSelf) called by Project.configure.

Do you have an example where you've written a repositories-like block as described in gradle/gradle#23874 ?

[vlsi]

@remal , project.configure does not work since it is implemented as follows:
https://github.com/gradle/gradle/blob/master/subprojects/model-core/src/main/java/org/gradle/util/ConfigureUtil.java#L147-L154

In other words, if the target object "implements Configurable", then Gradle uses the implemented configure method.
Apparently NamedDomainObjectContainer implements Configurable interface since it wants exposing custom behavior like "converting abc to create("abc")".
Unfortunately, NamedDomainObjectContainer.configure is hard-coded, and it does not allow plugin authors augmenting the behavior (see gradle/gradle#23874 (comment) )

[szpak]

@TWiStErRob Could you rebase TWiStErRob#5 and create it as a regular PR (in this repo)? WE could merge it next (as #168 is done).

[TWiStErRob]

Raised #172 as rebase of TWiStErRob#5 + fix for #164's ignore. (no testing locally, I'll let the CI do the honors)

Edit: too confident 😅, investigating.

[TWiStErRob]

Fixed, how good that we merged #164, huh? 😁

[szpak]

Hopefully, the deprecation warning is addressed for the time being. I still hope to get some response from the Gradle team about gradle/gradle#23874, with #165 as a non backward compatible idea as a fallback.

Big thanks to @TWiStErRob @vlsi @nedtwigg for theirs PRs and the others for suggestions and nagging ;).

Btw, I enabled Discussions for the project which would a probably a better place to discuss different things, also related with the incoming release of 1.2.0.