https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# plugin-development
s
This message was deleted.
c
While it isn’t directly there you can do some magic with PipedInputStream / PipedOutputStream to handle things incrementally for large amounts of output.
This is a more general solution, using it with Gradle, annotated those parts you could directly replace.
Copy code
private val executor = Executors.newCachedThreadPool()

private fun <T> pipedStreams(block: PipedStreamsDsl<T>.() -> Unit): T {
    val dsl = PipedStreamsDsl<T>()
    dsl.apply(block)
    val sourceAction = requireNotNull(dsl.source)
    val sinkAction = requireNotNull(dsl.sink)

    return PipedOutputStream().use { source ->
        PipedInputStream(source).use { sink ->
            // start reading in separate thread
            val futureResult = executor.submit<T> {
                sinkAction(sink)
            }

            // Gradle exec here
            // invoke the main action that writes into source
            // keep on the same thread for Gradle compatibility
            sourceAction(source)

            // wait for everything to complete
            futureResult.get()
        }
    }
}
e
if it's that huge, it probably shouldn't be cached, and afaik the interface was designed for configuration caching first
c
don’t believe that caching was the issue, rather reading a large amount of data without a way to incrementally filter it as it comes in, as would be the case using a ByteArrayOutputStream with ExecOperations.
e
you could make your own valuesource which directly uses 
ProcessBuilder
and only emits the subset you care about, if you wanted to stay in the configuration-cache friendly world
otherwise why not keep using 
exec
?
k
True, people might want to be lazy with 
providers.exec { ... }.standardOutput.asText.map { ... }
, until it gets terrible for whatever reason. It's just wishful thinking.
c
people will certainly be lazy and do that. its possible to wrap that up, as noted earlier, in a custom ValueSource that uses ExecOperations to execute <whatever> and incrementally process the results.
k
It's probably better to do the custom 
ValueSource
anyways, given the second map will probably be a doozy.
e
I meant, 
ExecOperations
/ 
project.exec
is still there for the non-
Provider
way
if you're doing 
providers.exec
it's hashed into the configuration cache inputs, which might not be what if it's large amounts of output
Open in Slack
PreviousNext
Powered by