Ah, okay, I see. Well, in this case it is a release blocker then, since it
is indeed a regression. If you've an account to Apache Jira, please file a
Jira here: https://issues.apache.org/jira/projects/AVRO/issues

On Fri, May 3, 2019 at 11:38 AM Katrin Skoglund <katrin.skogl...@avanza.se>
wrote:

> Hi Nandor!
>
> Ah, I wasn't aware that the method is new. What I actually meant was that
> code generation that previously worked now generates code that no longer
> compiles, which I would say is a regression. The implementation of
> customEncode() in the class representing the outer record calls the
> corresponding method on its nested records, which won't compile if they are
> in different packages. This did not happen before since the method did not
> exist, so the code compiled. Here's an example schema that reproduces the
> problem:
>
> {"namespace": "org.apache.avro.codegentest.some",
>   "type": "record",
>   "name": "NestedSomeNamespaceRecord",
>   "doc" : "Test nested types with different namespace than the outer type",
>   "fields": [
>     {
>       "name": "nestedRecord",
>       "type": {
>         "namespace": "org.apache.avro.codegentest.other",
>         "type": "record",
>         "name": "NestedOtherNamespaceRecord",
>         "fields": [
>           {
>             "name": "someField",
>             "type": "int"
>           }
>         ]
>       }
>     }]
> }
>
> And an example from the generated code:
>
>   @Override protected void customEncode(org.apache.avro.io.Encoder out)
>     throws java.io.IOException
>   {
>     this.nestedRecord.customEncode(out);
>
>   }
>
> //Katrin
>
>
> On 2019-05-03, 11:15, "Nandor Kollar" <nkol...@cloudera.com.INVALID>
> wrote:
>
>     Hi Katrin,
>
>     It appears to me, that these methods didn't exist in previous Avro
>     versions, they were added in https://github.com/apache/avro/pull/350
> and
>     were renamed and reduced their visibility in
>
> https://github.com/apache/avro/pull/350/commits/d320b6b536c49b485be45286dbdb73226eef4b35
> .
>     Actually it looks like the version with public visibility wasn't even
>     merged to master.
>
>     Are you using a fork of Avro where these method were public, or am I
>     missing something? I'm not against of making these methods public
> (however
>     I guess the author of the change had some reason to reduce the scope
> form
>     public to protected), however don't think this should be a blocker for
> the
>     release, as this doesn't seem to be a regression.
>
>     Thanks,
>     Nandor
>
>     On Fri, May 3, 2019 at 10:43 AM Katrin Skoglund <
> katrin.skogl...@avanza.se>
>     wrote:
>
>     > Hi all,
>     >
>     > I just managed to test the new RC, specifically the Java code
> generation,
>     > with one of the libraries we use. I then noticed that their
> generated java
>     > code no longer compiles because of a change in access level of two
> methods.
>     >
>     > The generated methods customEncode and customDecode are protected in
> this
>     > version of Avro. They used to be public. This means that the
> generated java
>     > code for schemas using nested records with different namespaces will
> no
>     > longer compile.
>     >
>     > I think it would be good to fix this before releasing since it is a
> real
>     > easy fix, unless there is a good reason why the access level was
> changed to
>     > protected?
>     >
>     > I'll start a PR for this anyway, please let me know if you want the
> fix in
>     > some other way or if I should create a Jira first (new to the process
>     > here).
>     >
>     > //Katrin
>     >
>     >
>     > On 2019-04-30, 12:55, "Driesprong, Fokko" <fo...@driesprong.frl>
> wrote:
>     >
>     >     Hi everyone,
>     >
>     >     Since the last release of Apache Avro 1.8.2 on May 31, 2017. Two
> years
>     >     later,
>     >     I'm thrilled to propose the following RC to be released as
> official
>     > Apache
>     >     Avro 1.9.0 release.
>     >
>     >     The commit id is 24ff48c32d8d13433a1e31e485ef2af187d1eb62
>     >     * This corresponds to the tag: release-1.9.0-rc3
>     >     * https://github.com/apache/avro/releases/tag/release-1.9.0-rc3/
>     >
>     >     The release tarball, signature, and checksums are here:
>     >     * https://dist.apache.org/repos/dist/dev/avro/avro-1.9.0-rc3/
>     >
>     >     You can find the KEYS file here:
>     >     * https://dist.apache.org/repos/dist/dev/avro/KEYS
>     >
>     >     Binary artifacts for Java are staged in Nexus here:
>     >     *
>     >
>     >
> https://repository.apache.org/content/groups/staging/org/apache/avro/avro/1.9.0/
>     >
>     >     This release includes 272 Jira issues:
>     >     https://issues.apache.org/jira/projects/AVRO/versions/12333394
>     >     * Deprecate Joda-Time in favor of Java8 JSR310 and setting it as
>     > default
>     >     * Remove support for Hadoop 1.x
>     >     * Move from Jackson 1.x to 2.9
>     >     * Add ZStandard Codec
>     >     * Lots of updates on the dependencies to fix CVE's
>     >     * and many, many more!
>     >
>     >     Since RC1, two commits have been added:
>     >     * https://jira.apache.org/jira/browse/AVRO-2381
>     >     * https://jira.apache.org/jira/browse/AVRO-2383
>     >
>     >     Since RC2 the SHA1/MD5 checksums have been replaced with SHA512
>     >
>     >     Please download, verify, and test. This vote will remain open
> for at
>     > least
>     >     72 hours. Given sufficient votes, I would like to close it on or
> about
>     >     midnight
>     >     on Saturday, 4th of May 2019.
>     >
>     >     [ ] +1 Release this as Apache Avro 1.9.0
>     >     [ ] +0
>     >     [ ] -1 Do not release this because...
>     >
>     >     Consider this a +1 (non-binding) from my side:
>     >     * Compiled the new version of Parquet against the Divolte
> collector and
>     >     Apache Parquet
>     >
>     >     Cheers, Fokko Driesprong
>     >
>     >
>     >
>
>
>

Reply via email to