From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

I’ve looking at a data class (<https://github.com/sqldelight/sqldelight/blob/fae16461cc31515da89cc0262014c309d25ce42f/sqldelight-gradle-plugin/src/main/kotlin/app/cash/sqldelight/gradle/PropertiesImpl.kt#L46|SqlDelightSourceFolderImpl>) which has a property of type `File`. It looks kind of like this:
```data class SqlDelightSourceFolder(
  @Internal val folder: File,
  @Input val dependency: Boolean,
) : Serializable```
The data ultimately ends up as an input to a task (<https://github.com/sqldelight/sqldelight/blob/master/sqldelight-gradle-plugin/src/main/kotlin/app/cash/sqldelight/gradle/SqlDelightTask.kt#L54|SqlDelightTask>). It looks kind of like this:
```@CacheableTask
abstract class SqlDelightTask : AbstractTask() {
  ...
  @get:Nested abstract var sourceFolder: SqlDelightSourceFolder
}```
This all works.

But by expressing the task’s input file as a `File`, Gradle doesn’t infer task dependencies if that `File` is the output of another task. So I want to replace the `File` field with something more powerful, a `ConfigurableFileCollection`.
```data class SqlDelightSourceFolder(
  @InputFiles @PathSensitive(PathSensitivity.RELATIVE) val folder: ConfigurableFileCollection,
  @Input val dependency: Boolean,
) : Serializable```
But when I tried that, my build broke because `ConfigurableFileCollection` isn’t serializable.

Is there a good way to use a `ConfigurableFileCollection` as a property of a class, that’s itself an input to a task?

Just use the input file collection and a getter with the set

But the whole sqldelightsourcefolder is a hack

It adds to much input to too many tasks and it is also reused for the Tooling api 

The whole implementation should be refactored 

But a short term workaround is a Provider&lt;Directory&gt; that supports tasks dependencies 

I guess whatever you will set for the `Provider&lt;Directory` will maybe also not be `Serializable`.
Maybe that data class should not implement `Serializable`?
Besides that, as a constructor parameter `ConfigurableFileCollection` probably does not make much sense anyway but should be a `FileCollection` maybe?

The reason I like ConfigurableFileCollection is I saw some Gradle internals that offer a Codec for it
<https://github.com/gradle/gradle/blob/9269d1faa373190325c0218d14781ec67062e42b/platforms/core-configuration/core-serialization-codecs/src/main/kotlin/org/gradle/internal/serialize/codecs/core/ConfigurableFileCollectionCodec.kt#L29|https://github.com/gradle/gradle/blob/9269d1faa373190325c0218d14781ec67062e42b/pla[…]ternal/serialize/codecs/core/ConfigurableFileCollectionCodec.kt>

But I don’t know how to make my class use that codec when it serializes.

That has nothing to do with `Serializable`

Gradle has its own way to serialize things that are supported by that mechanism at some places and standard Java serialization is at most used as fall-back iirc.

Is it possible to use Gradle’s way of serialization, but for my plugin’s own classes?

But like I said, we should not mix up the Tooling Model that needs serialization with the task inputs that needs providers/filecollection.  

It is not a question about which classes but which use-cases

And if for tooling API you need Java serialization, then you need Java serialization, not Gradle serialization

You might need to use different classes for different use-cases, one for tooling API, one as task input

Oooh that makes sense. Too bad, but it makes sense