Add better support for providing system properties to the Test task

[wolfs]

Once https://github.com/gradle/build-cache/issues/800 is finished we should provide better support for building argument providers which add system properties to e.g. the test task.

Since we actually want to model something (like a java agent) and not add some generic system property with a relative path it could be enough to provide a helper method which converts a Map<String, Object> to system property command line arguments.

PR: #4709

[wolfs]

Maybe we want to make things like providing a single input file property with relative path easier by improving the usage of the Runtime API?
Something like this could work:

test.systemProperty('some.file.input', inputs.file('path/to/file').withPathSensitivity(RELATIVE).withStringRepresentation { it.absolutePath })

or

test.systemProperty(inputs.file('path/to/file').withPropertyName('some.file.input').withPathSensitivity(RELATIVE).withStringRepresentation { it.absolutePath })

We could provide outputs in the same way.

[wolfs]

I was thinking that we may be providing a DSL like this:

test.systemProperties {
    add('some.property', inputFile(file))
    add('some.input.directory', inputDirectory(dir))
    add('some.output.file', outputFile(dir))
    add('some.output.directory', outputDirectory(dir))
    add('some.ignored.file.path', ignored(file))
}

The inputFile/Directory would add path sensitivity NONE/RELATIVE respectively.
I guess we would register the inputs/outputs under the property name in jvmArgumentProviders.

The arguments for each of those methods would be something we can unpack (Callable/Provider) I guess.

[lptr]

Let's do this:

test.systemProperties {
    add('some.property', inputFile(otherTask.outputFileProvider))
    add('some.input.directory', inputDirectory(dir))
    add('some.output.file', outputFile(dir))
    add('some.output.directory', outputDirectory(dir))
    add('some.ignored.file.path', ignored(file))
    add('some.value', 'value')
}

[wolfs]

Proposal for the new API: https://docs.google.com/document/d/1BOiXi5Wwkgn_qY_JxfeLs8An5wmiWBfjP4Wu-hIqw8E/edit#

[wolfs]

We are waiting for @adammurdoch input on how to proceed here.

[wolfs]

After some discussion at the world meeting, we should go with a MapProvider for system properties and a map method which changes the type of the provider but captures the origin as inputs.

Something along those lines:

RegularFileProperty inputFile ...

compileJava.systemProperties.put("some.input.file", inputFile.map { it.get().asFile.absolutePath })

[ldaley]

It should also be much easier to add inconsequential system properties. A common example is setting java.io.tmp.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[wolfs]

We still want to do this sometime.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[TWiStErRob]

Please pick this up again! We need a way to add any Provider to systemProperties. It just came up twice in the last week... for one occurrence is how error-prone it is to do it right now see code (Do you notice the bug with the paparazzi.test.record property? if yes, you can open PR to see the fix.)

[britter]

@TWiStErRob you can always use a custom CommandLineArgumentProvider to pass a provider as a system property.

[TWiStErRob]

Thanks, that's a good workaround, but with limited use cases: as far as I understand it goes around the systemProperties Map DSL and kind-of forcefully adds the argument. For example anyone using tasks.withType<Test> would not be able to observe the presence of the property (let alone the value), not even in doFirst {}.