<@U0QBCLV62> I'm not sure if this is a limitation ...

# gradle

[jlleitschuh]

@bamboo I'm not sure if this is a limitation of gradle or kotlin:

@get:Input
    override val configuration: CodegenConfigurator by lazy { project.extensions.getByType(CodegenConfigurator::class.java) }

This throws an exception because:

Could not add entry ':PlexxiSwagger:Spec:swagger' to cache taskHistory.bin (/Users/jonathanleitschuh/work/git/plexxicontrol/.gradle/3.5-20170217174236+0000/taskHistory/taskHistory.bin).
> Unable to store task input properties. Property 'configuration' with value 'io.swagger.codegen.config.CodegenConfigurator_Decorated@735e4fd' cannot be serialized.

I know that the undecorated CodegenConfigurator is serializable because I made it so that it was:
https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/main/java/io/swagger/codegen/config/CodegenConfigurator.java#L38

Is this because of the extensions plugin?

[bamboo]

jlleitschuh: it could be something related to that value being exposed as an extension and thus decorated

[bamboo]

@oehme any insight on ☝️ ?

[jlleitschuh]

Is there a simple thing I can cast it to to get the undecorated instance of the object?

[bamboo]

There’s no undecorated instance unfortunately

[bamboo]

The type given to ExtensionContainer#create is implicitly subclassed and it’s that subclass that gets instantiated

[bamboo]

The getter would need to create an undecorated instance explicitly and copy the data

[oehme]

That’s right, our DSL decorators are not serializable

[jlleitschuh]

@oehme Is there a way to get the decorated class?
Is there some object that I can cast it to? Is there some variable that I can pull out of it that has a reference to the decorated class?

[jlleitschuh]

Or is there some way to use an extentions object as a task input?

[oehme]

Using an extension as a task input is not a good idea: Users might modify it through the task object, thinking that it only affects that task, but actually modifying an object that all tasks share. Instead each task should have its own properties and the extension object should only have properties that are cross-cutting and use project.afterEvaluate (or convention mapping, which is effectively public because we know everyone uses it) to transfer the values from the extension to the task. For example, we don’t have incrementalCompile on the Java plugin extension, but instead the user configures it on the JavaCompile tasks themselves. The Java plugin extension only provides things that are cross-cutting, e.g. SourceSet declarations (which are used by several tasks).

[oehme]

Also I’d strongly encourage you to write a configuration object for Gradle instead of using a Serializable blob. That way users will get better reporting like “Out of date because apiPackage changed" instead of “out of date because configuration changed”.