Question: when designing a

ValueSource

, is there a serializability requirement on the parameters? eg.

abstract class MyValueSource : ValueSource<String, MyValueSource.Parameters> {
  interface Parameters : ValueSourceParameters {
    val myClient: Property<MyClient>
  }
}

vs.

abstract class MyValueSource : ValueSource<String, MyValueSource.Parameters> {
  interface Parameters : ValueSourceParameters {
    val myService: Property<MyService> // from a BuildService provider
    val clientName: Property<String>
  }
  
  private val myClient = parameters.myService.zip(parameters.myClient) { ... }
}

I seem to recall that there being a case, but I want to make sure, since you can certainly design without.

I had been tying to do something similar in past, but was blocked because of serializability requirement. Were you able to get around that?

For various reasons, Gradle may serialize ValueSource parameters with two different serialization mechanisms with different requirements: • to isolate them from the rest of the configuration code - this uses a mechanism similar to task input serialization for fingerprinting, and aside from some built-in types it uses java serialization for user types. • to store value sources in the configuration cache - it uses configuration cache serialization that doesn't rely on java serialization (though it supports some of its protocol, like

readResolve

or

writeObject

). It is only used when CC is enabled. The output of the ValueSource may only be serialized with the first serialization if it is used as a task input. It may also be serialized by CC serialization if the ValueSource is obtained at configuration time, for build input fingerprinting.

So let me get this straight: in summary, we have to design

ValueSource

parameters in such a way that we use "serializable" types, which rules out client objects. I presume

BuildService

instances, due to being named, are OK. Aside: there is no such requirement for a

WorkAction

, right?

we have to design ValueSource parameters in such a way that we use "serializable" types

Basically yes

I presume BuildService instances, due to being named, are OK.

There is at least one corner case of BuildServices and ValueSources that Gradle doesn't support yet. It is configuration cache specific

there is no such requirement for a WorkAction, right?

My reading of the code suggests that

WorkAction

parameters,

ArtifactTransform

parameters, and other similar

XxxParameter

things all share the same infrastructure and thus requirements.

Oof for me, but consistency is good.