Consider introducing a lazy API to set repository URL for PublishToRepository task

[mlopatkin]

Expected Behavior

It should be possible to set a URL of a repository in a configuration-cache compatible lazy manner.

Current Behavior

The existing Maven/IvyArtifactRepository.setUrl(Object) method is not lazy, the URL is eagerly evaluated when stored to the configuration cache.

Context

The lazy API will allow tweaking the publishing URL without invalidating the configuration cache, e.g. by wiring an environment variable provider.

There's also a more complex scenario, though it isn't obvious how widespread it is. The "publishing credentials" sample needs something to become fully configuration-cache compatible. The sample starts a bundled web server that works as a maven repository and then publishes libraries into the server. The URL of the server (the port part) may change between runs and can only be obtained after the server is started.

The current implementation starts the server in doFirst action and reconfigures the publishing repository. This isn't compatible with the configuration cache, because repository object is not restored from the cache fully.

A configuration cache-compatible implementation can be the following:

1. The web server is implemented as a shared build service with a getUrl accessor/provider
2. This URL provider is wired into the URL of publishing task repository with the new lazy API.

[gabrielittner]

We have one of the more complex scenarios in the vanniktech/gradle-maven-publish-plugin. We have a task that makes an API call to Sonatype OSS to create a staging repository to upload to. The repository url is then derived from that plus 2 other properties that are set through our extension. We currently use a provider for the url to make this possible.

This is the configuration code
https://github.com/vanniktech/gradle-maven-publish-plugin/blob/main/plugin/src/main/kotlin/com/vanniktech/maven/publish/MavenPublishBaseExtension.kt#L64-L71

[TWiStErRob]

Gradle Nexus Publish Plugin would use this facility to support configuration cache. The value is set via provider already, but when Configuration Cache is enabled, the serialization eagerly resolves the provider too early before the task that would set the value executes.

See point 3) at gradle-nexus/publish-plugin#221 (comment)

[mlopatkin]

Nevermind, I have to use the --no-configuration-cache CLI option instead.

Either this or -Dorg.gradle.configuration-cache=false. -P sets the project property and is not suitable for most of the Gradle configuration.

[sschuberth]

Either this or -Dorg.gradle.configuration-cache=false. -P sets the project property and is not suitable for most of the Gradle configuration.

I've never really understood the difference TBH. I thought that everything that can go to gradle.properties is also overridable via -P, and -D is to set Java system properties instead of Gradle properties.