You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Alexey Romanenko <ar...@gmail.com> on 2023/10/18 20:14:18 UTC
Re: [NOTICE] Deprecation Avro classes in "core" and use "extensions/avro" instead for Java SDK
Heads up!
Finally, all Avro-related code and Avro dependency, that was deprecated before (see a message above), has been removed from Beam Java SDK “core” module [1]. We believe that it was a sufficient number of Beam releases (six!) that passed after this code had been deprecated and users had an opportunity to switch to a new Avro extension as it was recommended before.
We did our best to make this transition as smooth as possible but, please, let me know you find any failed tests or any other strange behavior because of this change.
Thanks,
Alexey
[1] https://github.com/apache/beam/pull/27851/
> On 22 Feb 2023, at 20:21, Robert Bradshaw via dev <de...@beam.apache.org> wrote:
>
> Thanks for pushing this through!
>
> On Wed, Feb 22, 2023 at 10:38 AM Alexey Romanenko
> <ar...@gmail.com> wrote:
>>
>> Hi all,
>>
>> As a part of migration the Avro-related classes from Java SDK “core” module to a dedicated extension [1] (as it was discussed here [2] and here [3]), two important PRs has been merged [4][5]. Therefore, old Avro-related classes became deprecated in “core” (still possible to use but not recommended) and all other Beam modules, that depended on them, switched to use "extensions/avro” instead.
>>
>> We did our best to make this change smooth, compatible and not breaking but, since it was one of the oldest part of “core”, then everything, unfortunatelly, is possible and we probably could miss something despite of all efforts. So, considering that, I’d like to ask community to run any kind of tests or pipelines that utilise, for example, AvroCoder or AvroUtils or any other related Avro classes and check if new changes doesn’t break something and everything works as expected.
>>
>> —
>> Alexey
>>
>> [1] https://github.com/apache/beam/issues/24292
>> [2] https://lists.apache.org/thread/mz8hvz8dwhd0tzmv2lyobhlz7gtg4gq7
>> [3] https://lists.apache.org/thread/47oz1mlwj0orvo1458v5pw5c20bwt08q
>> [4] https://github.com/apache/beam/pull/24992
>> [5] https://github.com/apache/beam/pull/25534
>>
>>
Re: [NOTICE] Deprecation Avro classes in "core" and use "extensions/avro" instead for Java SDK
Posted by Kenneth Knowles <ke...@apache.org>.
Woooo
On Wed, Oct 18, 2023 at 4:19 PM Byron Ellis via dev <de...@beam.apache.org>
wrote:
> Awesome!
>
> On Wed, Oct 18, 2023 at 1:14 PM Alexey Romanenko <ar...@gmail.com>
> wrote:
>
>> Heads up!
>>
>> Finally, all Avro-related code and Avro dependency, that was deprecated
>> before (see a message above), has been removed from Beam Java SDK “core”
>> module [1]. We believe that it was a sufficient number of Beam releases
>> (six!) that passed after this code had been deprecated and users had an
>> opportunity to switch to a new Avro extension as it was recommended before.
>>
>> We did our best to make this transition as smooth as possible but,
>> please, let me know you find any failed tests or any other strange behavior
>> because of this change.
>>
>> Thanks,
>> Alexey
>>
>>
>> [1] https://github.com/apache/beam/pull/27851/
>>
>>
>> On 22 Feb 2023, at 20:21, Robert Bradshaw via dev <de...@beam.apache.org>
>> wrote:
>>
>> Thanks for pushing this through!
>>
>> On Wed, Feb 22, 2023 at 10:38 AM Alexey Romanenko
>> <ar...@gmail.com> wrote:
>>
>>
>> Hi all,
>>
>> As a part of migration the Avro-related classes from Java SDK “core”
>> module to a dedicated extension [1] (as it was discussed here [2] and here
>> [3]), two important PRs has been merged [4][5]. Therefore, old Avro-related
>> classes became deprecated in “core” (still possible to use but not
>> recommended) and all other Beam modules, that depended on them, switched to
>> use "extensions/avro” instead.
>>
>> We did our best to make this change smooth, compatible and not breaking
>> but, since it was one of the oldest part of “core”, then everything,
>> unfortunatelly, is possible and we probably could miss something despite of
>> all efforts. So, considering that, I’d like to ask community to run any
>> kind of tests or pipelines that utilise, for example, AvroCoder or
>> AvroUtils or any other related Avro classes and check if new changes
>> doesn’t break something and everything works as expected.
>>
>> —
>> Alexey
>>
>> [1] https://github.com/apache/beam/issues/24292
>> [2] https://lists.apache.org/thread/mz8hvz8dwhd0tzmv2lyobhlz7gtg4gq7
>> [3] https://lists.apache.org/thread/47oz1mlwj0orvo1458v5pw5c20bwt08q
>> [4] https://github.com/apache/beam/pull/24992
>> [5] https://github.com/apache/beam/pull/25534
>>
>>
>>
>>
Re: [NOTICE] Deprecation Avro classes in "core" and use "extensions/avro" instead for Java SDK
Posted by Byron Ellis via dev <de...@beam.apache.org>.
Awesome!
On Wed, Oct 18, 2023 at 1:14 PM Alexey Romanenko <ar...@gmail.com>
wrote:
> Heads up!
>
> Finally, all Avro-related code and Avro dependency, that was deprecated
> before (see a message above), has been removed from Beam Java SDK “core”
> module [1]. We believe that it was a sufficient number of Beam releases
> (six!) that passed after this code had been deprecated and users had an
> opportunity to switch to a new Avro extension as it was recommended before.
>
> We did our best to make this transition as smooth as possible but, please,
> let me know you find any failed tests or any other strange behavior because
> of this change.
>
> Thanks,
> Alexey
>
>
> [1] https://github.com/apache/beam/pull/27851/
>
>
> On 22 Feb 2023, at 20:21, Robert Bradshaw via dev <de...@beam.apache.org>
> wrote:
>
> Thanks for pushing this through!
>
> On Wed, Feb 22, 2023 at 10:38 AM Alexey Romanenko
> <ar...@gmail.com> wrote:
>
>
> Hi all,
>
> As a part of migration the Avro-related classes from Java SDK “core”
> module to a dedicated extension [1] (as it was discussed here [2] and here
> [3]), two important PRs has been merged [4][5]. Therefore, old Avro-related
> classes became deprecated in “core” (still possible to use but not
> recommended) and all other Beam modules, that depended on them, switched to
> use "extensions/avro” instead.
>
> We did our best to make this change smooth, compatible and not breaking
> but, since it was one of the oldest part of “core”, then everything,
> unfortunatelly, is possible and we probably could miss something despite of
> all efforts. So, considering that, I’d like to ask community to run any
> kind of tests or pipelines that utilise, for example, AvroCoder or
> AvroUtils or any other related Avro classes and check if new changes
> doesn’t break something and everything works as expected.
>
> —
> Alexey
>
> [1] https://github.com/apache/beam/issues/24292
> [2] https://lists.apache.org/thread/mz8hvz8dwhd0tzmv2lyobhlz7gtg4gq7
> [3] https://lists.apache.org/thread/47oz1mlwj0orvo1458v5pw5c20bwt08q
> [4] https://github.com/apache/beam/pull/24992
> [5] https://github.com/apache/beam/pull/25534
>
>
>
>