[jira] [Created] (AVRO-2391) Simplify and modernize setup.py
Michael A. Smith created AVRO-2391: -- Summary: Simplify and modernize setup.py Key: AVRO-2391 URL: https://issues.apache.org/jira/browse/AVRO-2391 Project: Apache Avro Issue Type: Task Components: python Reporter: Michael A. Smith The main purpose of this change is to simplify and modernize the setup code without really changing its behavior. * The main change is that I moved most of the setup code into the declarative setup.cfg, where I hope it is somewhat clearer. * I also fleshed out the setup.py commands so that the build.sh and setup.py have parity -- that is, the build.sh is entirely implemented using setup.py. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AVRO-2390) Travis jobs are killed with "No output has been received"
[
https://issues.apache.org/jira/browse/AVRO-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nandor Kollar updated AVRO-2390:
Summary: Travis jobs are killed with "No output has been received" (was:
Tests Travis jobs are killed with "No output has been received")
> Travis jobs are killed with "No output has been received"
> -
>
> Key: AVRO-2390
> URL: https://issues.apache.org/jira/browse/AVRO-2390
> Project: Apache Avro
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Nandor Kollar
>Priority: Major
>
> Travis jobs fail with
> {code}
> No output has been received in the last 10m0s, this potentially indicates a
> stalled build or something wrong with the build itself.
> Check the details on how to adjust your build configuration on:
> https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
> {code}
> I think travis_wait or using [pv|https://linux.die.net/man/1/pv] should solve
> this problem
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AVRO-2390) Tests Travis jobs are killed with "No output has been received"
Nandor Kollar created AVRO-2390:
---
Summary: Tests Travis jobs are killed with "No output has been
received"
Key: AVRO-2390
URL: https://issues.apache.org/jira/browse/AVRO-2390
Project: Apache Avro
Issue Type: Bug
Affects Versions: 1.9.0
Reporter: Nandor Kollar
Travis jobs fail with
{code}
No output has been received in the last 10m0s, this potentially indicates a
stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on:
https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
{code}
I think travis_wait or using [pv|https://linux.die.net/man/1/pv] should solve
this problem
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AVRO-2389) Serializers for plain old C# objects (POCOs)
Patrick Farry created AVRO-2389: --- Summary: Serializers for plain old C# objects (POCOs) Key: AVRO-2389 URL: https://issues.apache.org/jira/browse/AVRO-2389 Project: Apache Avro Issue Type: New Feature Components: csharp Affects Versions: 1.8.2 Reporter: Patrick Farry Hi All, I have written code that implements Avro serialization for POCO classes - i.e. classes that are not generated by Avro codegen and do not implement ISpecificRecord. The idea was to make it work as much like [JSON.net|http://json.net/] as possible. The serializer inherits from SpecificDefaultWriter and the deserializer from SpecificDefaultReader. Avro fields are mapped to C# properties either by matching the field name and property name or by using an attribute to specify the field sequence number. Is this something that would be of interest to the Avro project? My company has approved committing the code and I'd be available and happy to maintain this code and work on other parts of the C# implementation. Regards. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Python 3 support
+1 from my side Thanks Michael for reviving this thread again. Since 3.4 isn't officially supported anymore, I think it is save to drop support for Avro 1.9 as well to speed up the deprecation process. In practice it will still work against 3.4 until we start using breaking features such as type annotation, f-strings etc. Cheers, Fokko Op za 4 mei 2019 om 20:47 schreef Rajkumar Natarajan > +1 > > On Sat, May 4, 2019, 2:37 PM sajuukk wrote: > > > +1 > > > > W dniu 04.05.2019 o 16:10, Michael A. Smith pisze: > > > Hi, Avro devs, it's time to wake this thread up for a checkpoint. > > > > > > I glanced at pypi stats today and it looks like 3.4 downloads are > usually > > > below 1000. More importantly, Python has already EOL'ed python 3.4. Do > we > > > want to consider python 3.4 support officially dropped as of the 1.9 > > > release? > > > > > > That is, even if python 3.4 happens to work in 1.9 when it is released, > > > only versions 3.5 and up will be officially supported? > > > > > > I don't believe this is terribly controversial, so I'll ask for a vote > > now. > > > > > > Please reply +1 if you believe that avro-python3 as of 1.9 considers > 3.4 > > > deprecated. > > > Please reply -1 if you believe that in avro-python3 1.9 we should > > continue > > > to make efforts to work in python 3.4. > > > Please reply 0 if you want to make comments, but not vote. > > > > > > > https://www.apache.org/foundation/voting.html#votes-on-code-modification > > > > > > > > > On Sat, Nov 10, 2018 at 7:42 PM Piotr Gołąb wrote: > > > > > >> Hi Michael, > > >> > > >> Ok, I think it's good idea to drop the Python 3.4 support after the > last > > >> release of 3.4. We can show deprecation warnings before. By the way, > > this > > >> will also be a good opportunity for some refactoring. As for the Avro > on > > >> Python 2.7, my approach would be just leave it as it is now and don't > > >> introduce new features. > > >> > > >> Best, > > >> Piotr > > >> > > >> > > >> > > >> -- > > >> Sent from: > > >> http://apache-avro.679487.n3.nabble.com/Avro-Developers-f679485.html > > >> > > >
Re: [VOTE] Release Apache Avro 1.9.0 RC3
Canceling the vote.
Thanks Karin for giving 1.9.0 RC a try. I'll release RC4 soon with your
patch.
Cheers, Fokko
Op vr 3 mei 2019 om 12:33 schreef Nandor Kollar
:
> 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 >
> wrote:
>
> > I realized I don't have a Jira account, should I sign up for one?
> >
> > On 2019-05-03, 12:09, "Nandor Kollar"
> > 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 <
> > 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" >
> > > 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
> >
