This message was deleted.

Something like this fall-through chain of providers? Yes, this works with configuration caching.

/**
 * Looks up the specified property from the following sources, in order:
 *
 * -Gradle property
 * -System property
 * -Environment variable (with name transformed to uppercase, '.' replaced with '_'
 */
public fun ProviderFactory.property(name: Provider<String>): Provider<String> {
    return gradleProperty(name)
        .orElse(systemProperty(name))
        .orElse(environmentVariable(name.map { it.uppercase().replace(".", "_") }))
        .forUseAtConfigurationTime()
}

I saw that for use with is now deprecated

correct

So I was just using the normal property access. Has property and property

yes. the resolution of properties should be deferred until execution time (when the property values are needed).

Does it actually matter if all that property does is get set for the purpose of it being passed to the test?

it does in the sense of configuration and task caching; if the property value changes caches are invalidated.

Okay

most common things are, if you are using Properties/Providers.

Do I actually need to have the function there? And is it then just a matter of calling the function directly inside of my tasks.test?

that function was for reuse, not necessary to have it. Something like this:

named<Test>("test") {
        prop.set(
            providers.gradleProperty("some.gradle.property")
                .orElse(providers.systemProperty("some.system.property"))
        )
    }

But how do I check if it has property in the first place? I only want to do this if it's set

it does that for you via the orElse clauses. You can provide a default via

.convention

(or add another orElse). If you really want to check if it has a value use

prop.isPresent

inside the task action.

The Gradle property function doesn't seem to exist the kotlin DSL

Hmmm. It does on recent 7.4, 7.5 versions of Gradle.

. I am using 751 but it doesn't seem to want to recognize it for an import

Provider<String> gradleProperty(Provider<String> propertyName);

on ProviderFactory since Gradle 6.2

I think I'm confused because I was your interfaces and I don't seem to have any static methods

ignore those extension functions, they were illustrative. In a Kotlin DSL build script there is

providers

on the project that should be used.

Oh I think I see what you have in mind. So once I get the cradle or system property from providers. Do I then just call the normal system property to set it?

no. use the syntax provided to get a gradle property provider, set that on your task, and call

.get()

inside the task action on the proeprty.

Why not just do providers.gradleproperty.get?

that subverts the point of providers - to defer resolution until it’s needed.

.get()

should only be called at execution time (inside task action).

Also is Gradle property actually going to work for a project EG -P property

yes

But how do I set it back to a system property that the test will receive? Looking at your code I don't see that

named<Test>("test") {
        prop.set(
            providers.gradleProperty("some.gradle.property")
                .orElse(providers.systemProperty("some.system.property"))
        )
    }

that create a provider that will first try a gradle property then a system property. In your task action use

prop.get()

to resolve.

Where does prop come from? And that still doesn't seem like it would set it back to system property for the purpose of spring getting it in my test

prop is a property on the task. What are the specifics of your example?

I've got providers Gradle property run system property spring.profiles.active CI

what does the task definition look like?

Right, exactly

that won’t work. you aren’t setting anything on the task. It looks like your are trying to set a system property there - won’t work in that manner, you’ll need to look at the test task to see how to set a system property (i can’t recall atm).

I mean, that's a correct invocation for setting a system property

Something like this:

tasks.named<Test>("test") {
    useJUnitPlatform()
    systemProperty( "spring.profiles.active", providers.gradleProperty("test.spring.profiles.active").orElse(""))
}

how is that different... orNull is just doing a get and then run will exec when it's not...

true, but you don’t really want to do that yourself - let the Gradle internals resolve as necessary.

seems like mine might actually be (negligibly) more performant too as system property wouldn't get called unless (and I wouldn't want it to) it was set

unlikely to be any material / measurable performance difference. tend to prefer cleaner code first.

isn't orNull just going to call the same get as earlier? trying to understand the difference. Also I'm uncertain (and untested) whether setting spring profiles to an empty string is going to unset my other default of test

you could use ‘test’ as the default, or do a

.map {}

to add test into what was passed in the property. The difference is that Gradle will invoke the provider internally, if and when required, removing .get() or .orNull from your code. Imperative code in build scripts is a code smell, makes it noisy and hard to maintain.

yeah, but it causes confusion I think from a spring perspective... idk, urgh

it’s more idiomatic Gradle; of course, one can do whatever is possible in the world of Kotlin

as val foo = bar ? "foo" : null is debate-ably imperative

Not style. Resolving a provider outside of the execution phase is not idiomatic, it incurs potentially unnecessary operations, clutters the code, and doesn’t allow for subsequent configuration changes to be picked up before execution. The providers pattern was introduced for many good reasons; subverting those reverts back to the many problems.

hmm...

as soon as you call

.orNull

or

.get()

during configuration (such as configuring a task) that subverts lazy configuration. Providers are generally either passed to Gradle to be later resolve, or resolved in your custom task actions (during execution of the task, if the task is even executed).

I said

if

not

is

you can chain properties together if that’s the goal. e.g.

prop1.set(prop2)

, without having to resolve the values.

what is this .set? I don't see it on Provider

Providers are the read-only aspect of Properties. Typically a task will expose properties (that can be set). Also available on extension objects. for example:

scmVersion {
    localOnly.set(true)
    tag {
        prefix.set("release")
        versionSeparator.set("/")
    }
}

... so how would I be setting that if this isn't a property available on test task

you’re not. The provider is passed into the systemProperty method on the test task, which internally does <something> with it.

tried what you're suggesting and it doesn't work because

systemProperty

doesn't take a Provider, and

orElse

returns a provider

seems like that would be a good enhancement request, to accept a Provider in Test.systemProperty.

If

systemProperty

would properly handle providers, the difference would not only be style, but a Chris version would reuse CC even if the value changes, yours not

In this case is mine good enough? To be honest though... In this case the value is very rarely going to change in a single environment

In this case is mine good enough?

If the test task cannot get the value from a provider anyway (didn't check), probably yes.