FINERACT-2575: replace archived Avro Gradle plugin#5736
FINERACT-2575: replace archived Avro Gradle plugin#5736San-43 wants to merge 1 commit intoapache:developfrom
Conversation
Aman-Mittal
left a comment
There was a problem hiding this comment.
I think to better wait for official release from apache first https://issues.apache.org/jira/browse/AVRO-4223 instead of using beta version
| id 'com.github.spotbugs' version '6.0.26' apply false | ||
| id 'se.thinkcode.cucumber-runner' version '0.0.11' apply false | ||
| id "com.github.davidmc24.gradle.plugin.avro-base" version "1.9.1" apply false | ||
| id "eu.eventloopsoftware.avro-gradle-plugin" version "0.1.2" apply false |
There was a problem hiding this comment.
I think we better hold this one and this plugin is maintained by a single developer. Which is a huge supply chain risk.
As stated by maintainer in ticket https://issues.apache.org/jira/browse/AVRO-4223
A planned release is discussed here under the name of org.apache.avro
If that gets release. I think we should wait for it and use that instead
Thank you very much for your review @Aman-Mittal . I agree we should wait for the official Apache release, and hopefully it won’t take long. I found INFRA-27616, so it looks like the plugin is ready and just waiting to be published as |
I am not convinced anyone is working on ot. Infra ticket is closed with resolution "later". |
@adamsaghy Pr is currently being review for merge against Apache Avro repo. If it is urgent to upgrade.I think we should add TODO: comment here to use official Apache plugin instead when it gets release. While i still emphasize that we should wait for it as there is also parent ticket https://issues.apache.org/jira/browse/AVRO-3731 in which original maintainer davidmc24 has offered to donated this plugin to ASF which is voted by the avro PMC members. |
its not urgent to upgrade. i just wanted someone(s) to review the options. |
Replaces the archived Avro Gradle plugin with
eu.eventloopsoftware.avro-gradle-plugininfineract-avro-schemas.The migration keeps the current generation flow unchanged:
I also restored
enableDecimalLogicalType = trueso decimal fields continue to be generated asBigDecimalinstead ofByteBuffer.