Okay, I created a Jira: https://issues.apache.org/jira/browse/AVRO-2386
Thanks Katrin, nice catch! You can open a PR for https://github.com/apache/avro. Because this is a regression, I vote -1 (non-binding) on RC3 On Fri, May 3, 2019 at 12:20 PM Katrin Skoglund <[email protected]> wrote: > I realized I don't have a Jira account, should I sign up for one? > > On 2019-05-03, 12:09, "Nandor Kollar" <[email protected]> > wrote: > > 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 < > [email protected]> > 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" <[email protected]> > > 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 < > > [email protected]> > > 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" <[email protected] > > > > 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 > > > > > > > > > > > > > > > > > >
