search

relaycorp / awala-ping-android

Android app for the Awala Ping Service
GNU General Public License v3.0
0 stars 0 forks source link

fix(deps): Bump epoxyVersion from 4.6.3 to 5.1.1 #270

Open dependabot[bot] opened 1 year ago

dependabot[bot] commented 1 year ago

Bumps epoxyVersion from 4.6.3 to 5.1.1. Updates epoxy from 4.6.3 to 5.1.1

Release notes

Sourced from epoxy's releases.

5.1.1

Remove incorrect ksp symbol validation

5.1.0

Updates Kotlin to 1.7.20 and KSP to 1.7.20-1.0.7, as well as the room compiler processing (xprocessing) library to 2.5.0-beta01.

Also deletes the epoxy-paging artifact in favor of the newer epoxy-paging3

5.0.0

This adds support for Kotlin Symbol Processing, while maintaining backwards compatibility with java annotation processing via the xprocessing library from Room.

This includes a major version bump to 5.0.0 because there may be slight behavior differences with KSP, especially for generic types in generated code. For example, if you previously had an epoxy attribute in java source code with a raw type it may now appear in the generated code with a wildcard type, which may require tweaking the type that is passed to the model.

Additionally, some type checking was improved, for example more accurate validation of proper equals and hashcode implementations.

To use Epoxy with KSP, simply apply it with the ksp gradle plugin instead of kapt (https://github.com/google/ksp/blob/main/docs/quickstart.md). See the new epoxy-kspsample module for an example.

Note that unfortunately the databinding processor does NOT support KSP, simply because Android databinding itself uses KAPT and KSP cannot currently depend on KAPT sources. The code changes are in place to enable KSP with databinding once the databinding plugin from Android supports KSP (although this is unlikely) - alternatively it may be possible to configure the KSP plugin to run after KAPT and depend on its outputs (you're on your own if you want to try that).

Also, parallel processing support was removed because it is not compatible with KSP.

We have also added easy interop with Jetpack Compose via functions in the epoxy-composeinterop artifact. See the epoxy-composesample module for example usage.

5.0.0-beta03

Fixes an empty list crash in the processor when a view with @​ModelView extends a subclass that has a @​ModelProp annotation with a default parameter value.

5.0.0-beta02

This adds support for Kotlin Symbol Processing, while maintaining backwards compatibility with java annotation processing via the xprocessing library from Room. Note that compilation speed with epoxy in KSP is not yet faster than KAPT due to some optimizations that remain to be made, but those should be made before long.

This includes a major version bump to 5.0.0 because there may be slight behavior differences with KSP, especially for generic types in generated code. For example, if you previously had an epoxy attribute in java source code with a raw type it may now appear in the generated code with a wildcard type, which may require tweaking the type that is passed to the model.

Additionally, some type checking was improved, for example more accurate validation of proper equals and hashcode implementations.

To use Epoxy with KSP, simply apply it with the ksp gradle plugin instead of kapt (https://github.com/google/ksp/blob/main/docs/quickstart.md). See the new epoxy-kspsample module for an example.

Note that unfortunately the databinding processor does NOT support KSP, simply because Android databinding itself uses KAPT and KSP cannot currently depend on KAPT sources. The code changes are in place to enable KSP with databinding once the databinding plugin from Android supports KSP (although this is unlikely) - alternatively it may be possible to configure the KSP plugin to run after KAPT and depend on its outputs (you're on your own if you want to try that).

Also, parallel processing support was removed because it is not compatible with KSP.

KSP Generated Sources in IDE

Note, that as of the current KSP version generated java sources are detected by the IDE but NOT generated kotlin sources. This means that generated epoxy kotlin extensions will not automatically be resolved in the IDE. You must manually configure your source sets to include ksp generated folders.

You can add this to your root build.gradle file to work around this

subprojects { project ->
    afterEvaluate {
        if (project.hasProperty("android")) {
            android {
</tr></table>

... (truncated)

Changelog

Sourced from epoxy's changelog.

5.1.1

Remove incorrect ksp symbol validation in processing of @​EpoxyModelClass

5.1.0

Updates Kotlin to 1.7.20 and KSP to 1.7.20-1.0.7, as well as the room compiler processing (xprocessing) library to 2.5.0-beta01.

Also deletes the epoxy-paging artifact in favor of the newer epoxy-paging3

5.0.0

This adds support for Kotlin Symbol Processing, while maintaining backwards compatibility with java annotation processing via the xprocessing library from Room.

This includes a major version bump to 5.0.0 because there may be slight behavior differences with KSP, especially for generic types in generated code. For example, if you previously had an epoxy attribute in java source code with a raw type it may now appear in the generated code with a wildcard type, which may require tweaking the type that is passed to the model.

Additionally, some type checking was improved, for example more accurate validation of proper equals and hashcode implementations.

To use Epoxy with KSP, simply apply it with the ksp gradle plugin instead of kapt (https://github.com/google/ksp/blob/main/docs/quickstart.md). See the new epoxy-kspsample module for an example.

Note that unfortunately the databinding processor does NOT support KSP, simply because Android databinding itself uses KAPT and KSP cannot currently depend on KAPT sources. The code changes are in place to enable KSP with databinding once the databinding plugin from Android supports KSP (although this is unlikely) - alternatively it may be possible to configure the KSP plugin to run after KAPT and depend on its outputs (you're on your own if you want to try that).

Also, parallel processing support was removed because it is not compatible with KSP.

We have also added easy interop with Jetpack Compose via functions in the epoxy-composeinterop artifact. See the epoxy-composesample module for example usage.

4.6.4 (September 23, 2021)

  • Clean up dependency for the experimental epoxy module
Commits


Updates epoxy-processor from 4.6.3 to 5.1.1

Release notes

Sourced from epoxy-processor's releases.

5.1.1

Remove incorrect ksp symbol validation

5.1.0

Updates Kotlin to 1.7.20 and KSP to 1.7.20-1.0.7, as well as the room compiler processing (xprocessing) library to 2.5.0-beta01.

Also deletes the epoxy-paging artifact in favor of the newer epoxy-paging3

5.0.0

This adds support for Kotlin Symbol Processing, while maintaining backwards compatibility with java annotation processing via the xprocessing library from Room.

This includes a major version bump to 5.0.0 because there may be slight behavior differences with KSP, especially for generic types in generated code. For example, if you previously had an epoxy attribute in java source code with a raw type it may now appear in the generated code with a wildcard type, which may require tweaking the type that is passed to the model.

Additionally, some type checking was improved, for example more accurate validation of proper equals and hashcode implementations.

To use Epoxy with KSP, simply apply it with the ksp gradle plugin instead of kapt (https://github.com/google/ksp/blob/main/docs/quickstart.md). See the new epoxy-kspsample module for an example.

Note that unfortunately the databinding processor does NOT support KSP, simply because Android databinding itself uses KAPT and KSP cannot currently depend on KAPT sources. The code changes are in place to enable KSP with databinding once the databinding plugin from Android supports KSP (although this is unlikely) - alternatively it may be possible to configure the KSP plugin to run after KAPT and depend on its outputs (you're on your own if you want to try that).

Also, parallel processing support was removed because it is not compatible with KSP.

We have also added easy interop with Jetpack Compose via functions in the epoxy-composeinterop artifact. See the epoxy-composesample module for example usage.

5.0.0-beta03

Fixes an empty list crash in the processor when a view with @​ModelView extends a subclass that has a @​ModelProp annotation with a default parameter value.

5.0.0-beta02

This adds support for Kotlin Symbol Processing, while maintaining backwards compatibility with java annotation processing via the xprocessing library from Room. Note that compilation speed with epoxy in KSP is not yet faster than KAPT due to some optimizations that remain to be made, but those should be made before long.

This includes a major version bump to 5.0.0 because there may be slight behavior differences with KSP, especially for generic types in generated code. For example, if you previously had an epoxy attribute in java source code with a raw type it may now appear in the generated code with a wildcard type, which may require tweaking the type that is passed to the model.

Additionally, some type checking was improved, for example more accurate validation of proper equals and hashcode implementations.

To use Epoxy with KSP, simply apply it with the ksp gradle plugin instead of kapt (https://github.com/google/ksp/blob/main/docs/quickstart.md). See the new epoxy-kspsample module for an example.

Note that unfortunately the databinding processor does NOT support KSP, simply because Android databinding itself uses KAPT and KSP cannot currently depend on KAPT sources. The code changes are in place to enable KSP with databinding once the databinding plugin from Android supports KSP (although this is unlikely) - alternatively it may be possible to configure the KSP plugin to run after KAPT and depend on its outputs (you're on your own if you want to try that).

Also, parallel processing support was removed because it is not compatible with KSP.

KSP Generated Sources in IDE

Note, that as of the current KSP version generated java sources are detected by the IDE but NOT generated kotlin sources. This means that generated epoxy kotlin extensions will not automatically be resolved in the IDE. You must manually configure your source sets to include ksp generated folders.

You can add this to your root build.gradle file to work around this

subprojects { project ->
    afterEvaluate {
        if (project.hasProperty("android")) {
            android {
</tr></table>

... (truncated)

Changelog

Sourced from epoxy-processor's changelog.

5.1.1

Remove incorrect ksp symbol validation in processing of @​EpoxyModelClass

5.1.0

Updates Kotlin to 1.7.20 and KSP to 1.7.20-1.0.7, as well as the room compiler processing (xprocessing) library to 2.5.0-beta01.

Also deletes the epoxy-paging artifact in favor of the newer epoxy-paging3

5.0.0

This adds support for Kotlin Symbol Processing, while maintaining backwards compatibility with java annotation processing via the xprocessing library from Room.

This includes a major version bump to 5.0.0 because there may be slight behavior differences with KSP, especially for generic types in generated code. For example, if you previously had an epoxy attribute in java source code with a raw type it may now appear in the generated code with a wildcard type, which may require tweaking the type that is passed to the model.

Additionally, some type checking was improved, for example more accurate validation of proper equals and hashcode implementations.

To use Epoxy with KSP, simply apply it with the ksp gradle plugin instead of kapt (https://github.com/google/ksp/blob/main/docs/quickstart.md). See the new epoxy-kspsample module for an example.

Note that unfortunately the databinding processor does NOT support KSP, simply because Android databinding itself uses KAPT and KSP cannot currently depend on KAPT sources. The code changes are in place to enable KSP with databinding once the databinding plugin from Android supports KSP (although this is unlikely) - alternatively it may be possible to configure the KSP plugin to run after KAPT and depend on its outputs (you're on your own if you want to try that).

Also, parallel processing support was removed because it is not compatible with KSP.

We have also added easy interop with Jetpack Compose via functions in the epoxy-composeinterop artifact. See the epoxy-composesample module for example usage.

4.6.4 (September 23, 2021)

  • Clean up dependency for the experimental epoxy module
Commits


You can trigger a rebase of this PR by commenting @dependabot rebase.

Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note Automatic rebases have been disabled on this pull request as it has been open for over 30 days.