This guide highlights major changes and shows how to change a project to use new plugin.
Previously, it was possible to define execution without an execution. Now it’s important to define executions for every single project.
Improperly upgraded projects using the old model will receive a warning during the build briefly explaining actions required.
The reasons of deprecation and removal of this feature is:
-
There’s no way to tell how and if extension has been applied.
-
Plugin features can’t be extended as much as they planned.
-
Configuration refactoring can’t be done as easy as it could be.
-
A lot of spaghetti, generated and copy-paste code in the plugin makes it hard to maintain and catch an error.
Examples:
DSL language | DSL |
---|---|
Groovy Old version (prior 5.x), |
plugins {
id "java"
id "org.jsonschema2dataclass" version "x.y.z"
} |
Groovy Recommended new version (5.x) |
plugins {
id "java"
id "org.jsonschema2dataclass" version "x.y.z"
}
jsonSchema2Pojo {
executions {
main {}
}
} |
Kotlin Old version (prior 5.x), |
plugins {
`java`
id("org.jsonschema2dataclass") version "x.y.z"
} |
Kotlin Recommended new version (5.x) |
plugins {
`java`
id("org.jsonschema2dataclass") version "x.y.z"
}
jsonSchema2Pojo {
executions {
create("main")
}
} |
DSL language | DSL |
---|---|
Groovy Old version (prior 5.x), |
plugins {
id "java"
id "org.jsonschema2dataclass" version "x.y.z"
}
jsonSchema2Pojo {
targetPackage = 'example'
} |
Groovy Recommended new version (5.x) |
plugins {
id "java"
id "org.jsonschema2dataclass" version "x.y.z"
}
jsonSchema2Pojo {
executions {
main {
targetPackage = 'example'
}
}
} |
Kotlin Old version (prior 5.x), |
plugins {
`java`
id("org.jsonschema2dataclass") version "x.y.z"
}
jsonSchema2Pojo {
targetPackage.set("example")
} |
Kotlin Recommended new version (5.x) |
plugins {
`java`
id("org.jsonschema2dataclass") version "x.y.z"
}
jsonSchema2Pojo {
executions {
create("main") {
targetPackage.set("example")
}
}
} |
Version 5.0 renames sub-tasks to more readable values. Main tasks still have the same name as before.
-
Configuration name is used as part of task name instead of a sequence number.
-
Gradle API provides a set of configurations instead of list and never guarantees, which configuration will be first.
-
Using configuration names is more readable when a developer refers to it.
-
-
Android variant part is shifted toward beginning.
-
This way it’s easier to read task list.
-
Old name | New name | Notes |
---|---|---|
generateJsonSchema2DataClass0 |
generateJsonSchema2DataClassConfigMain |
Configuration name at the end |
generateJsonSchema2DataClassForRelease |
generateJsonSchema2DataClassForRelease |
Common task with Android variant is the same |
generateJsonSchema2DataClass0ForRelease |
generateJsonSchema2DataClassForReleaseConfigMain |
Android variant part shifted |
From 5.x onwards the plugin applies itself and generate tasks as soon as possible. Thus, it’s possible to directly hook the tasks if needed.
Previously, it was possible create only indirect hooks for tasks (which is still the preferred way to hook): * generateJsonSchema2DataClass depends on resource processing tasks * compilation and Lombok plugin tasks depend on generateJsonSchema2DataClass
I have no machine to build the demo. It requires build tools 30.0.3
at the most and can’t use newer ones.
Google provides binaries incompatible with my computer and CPU architecture.
Additionally, I was unable to find live Android library or application projects on GitHub.
This project is using and maintaining AGP3 API and will abandon it when Google decides to remove support of it.
It doesn’t build on CI for a little while and I can’t build on my computer as well.