[jira] [Commented] (AVRO-2621) Practical CustomConversions with SpecificCompiler and Maven
[ https://issues.apache.org/jira/browse/AVRO-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109721#comment-17109721 ] Matthew McMahon commented on AVRO-2621: --- Cloned to AVRO-2840 so that could submit a patch > Practical CustomConversions with SpecificCompiler and Maven > --- > > Key: AVRO-2621 > URL: https://issues.apache.org/jira/browse/AVRO-2621 > Project: Apache Avro > Issue Type: Improvement > Components: java >Reporter: Cherry Development >Priority: Major > Labels: maven > > So, as seen in AVRO-2498 we now have the ability in 1.9, at least using the > Maven tools, to have generated classes with a field of type UUID. For some > background, the secret sauce to get this working is: > * Set the logicalType of the field to 'uuid' and type to 'string' > * In the maven plugin configuration, add an item to with > the value org.apache.avro.Conversions$UUIDConversion > I attempted this with a custom type of my own (in this case, joda Money) > first by implementing a CustomConversion class that created a new > LogicalType called "money". This did not work, though, because although the > maven mojo correctly added the CustomConversion to the SpecificCompiler, when > the compiler parses the schema and sees the logicalType of type "money", it > attempts to look up the LogicalType from LogicalTypes the LogicalType is not > registered and it ignores it, which causes the field within the Schema to not > have a logicalType. Without a logicalType, the compiler does not consider it > a "UsedConversionClass" (see SpecificCompiler.getUsedConversionClass()) and > they velocity template doesn't write the class with the custom field type. > Trying to be clever, I attempted to work around this by putting a static > initializer in my CustomConversion class which called > LogicalTypes.register(). Unfortunately for me, the maven plugin doesn't load > any of the classes specified in until AFTER it has parsed > a schema. > Obviously, putting a static initializer inside of a CustomConversion should > not be part of a solution to this issue, but I propose a very simple solution: > * Add a logicalTypes property to AbstractAvroMojo, with items of a new type, > LocalTypeDefinition. That type will have a name and a logicalTypeFactory. > * Upon startup of the mojo, iterate through each item and call > LogicalTypes.register() on each, passing the indicated name and a new > instance of the indicated logicalTypeFactory class. > * At this point, the existing logic will treat the new custom type the same > as "uuid" is treated and will generate SpecificRecord classes with fields of > that type. > I could implement this pretty trivially, if there's an appetite for it. This > would seem to be 100% backwards compatible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AVRO-2840) Maven allow Custom Logical Types for generated code
[
https://issues.apache.org/jira/browse/AVRO-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109720#comment-17109720
]
Matthew McMahon edited comment on AVRO-2840 at 5/18/20, 1:14 AM:
-
Submitting a patch to make this possible with maven plugin. See
[^AVRO-2840.patch]
The PR is available at [https://github.com/apache/avro/pull/885]
was (Author: maccamlc):
Submitting a patch to make this possible with maven plugin.
The PR is available at [https://github.com/apache/avro/pull/885]
> Maven allow Custom Logical Types for generated code
> ---
>
> Key: AVRO-2840
> URL: https://issues.apache.org/jira/browse/AVRO-2840
> Project: Apache Avro
> Issue Type: Improvement
> Components: java
>Reporter: Matthew McMahon
>Priority: Major
> Labels: maven
> Attachments: AVRO-2840.patch
>
>
> I was looking for a way to use my Custom Conversion in generated code, but as
> detailed, without the Custom Logical Type being registered in the static
> REGISTERED_TYPES of LogicalTypes, then it will not be considered.
> Therefore this issue is an attempt to add this ability into Avro Maven Plugin
> by adding a new configuration map type to the plugin, and will also register
> this logical type in the generated code.
>
> {panel:title=Cloned from AVRO-2621}
> So, as seen in AVRO-2498 we now have the ability in 1.9, at least using the
> Maven tools, to have generated classes with a field of type UUID. For some
> background, the secret sauce to get this working is:
> * Set the logicalType of the field to 'uuid' and type to 'string'
> * In the maven plugin configuration, add an item to with
> the value org.apache.avro.Conversions$UUIDConversion
> I attempted this with a custom type of my own (in this case, joda Money)
> first by implementing a CustomConversion class that created a new
> LogicalType called "money". This did not work, though, because although the
> maven mojo correctly added the CustomConversion to the SpecificCompiler, when
> the compiler parses the schema and sees the logicalType of type "money", it
> attempts to look up the LogicalType from LogicalTypes the LogicalType is not
> registered and it ignores it, which causes the field within the Schema to not
> have a logicalType. Without a logicalType, the compiler does not consider it
> a "UsedConversionClass" (see SpecificCompiler.getUsedConversionClass()) and
> they velocity template doesn't write the class with the custom field type.
> Trying to be clever, I attempted to work around this by putting a static
> initializer in my CustomConversion class which called
> LogicalTypes.register(). Unfortunately for me, the maven plugin doesn't load
> any of the classes specified in until AFTER it has parsed
> a schema.
> Obviously, putting a static initializer inside of a CustomConversion should
> not be part of a solution to this issue, but I propose a very simple solution:
> * Add a logicalTypes property to AbstractAvroMojo, with items of a new type,
> LocalTypeDefinition. That type will have a name and a logicalTypeFactory.
> * Upon startup of the mojo, iterate through each item and call
> LogicalTypes.register() on each, passing the indicated name and a new
> instance of the indicated logicalTypeFactory class.
> * At this point, the existing logic will treat the new custom type the same
> as "uuid" is treated and will generate SpecificRecord classes with fields of
> that type.
> I could implement this pretty trivially, if there's an appetite for it. This
> would seem to be 100% backwards compatible.
> {panel}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AVRO-2840) Maven allow Custom Logical Types for generated code
[
https://issues.apache.org/jira/browse/AVRO-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew McMahon updated AVRO-2840:
--
Attachment: AVRO-2840.patch
Status: Patch Available (was: Open)
Submitting a patch to make this possible with maven plugin.
The PR is available at [https://github.com/apache/avro/pull/885]
> Maven allow Custom Logical Types for generated code
> ---
>
> Key: AVRO-2840
> URL: https://issues.apache.org/jira/browse/AVRO-2840
> Project: Apache Avro
> Issue Type: Improvement
> Components: java
>Reporter: Matthew McMahon
>Priority: Major
> Labels: maven
> Attachments: AVRO-2840.patch
>
>
> I was looking for a way to use my Custom Conversion in generated code, but as
> detailed, without the Custom Logical Type being registered in the static
> REGISTERED_TYPES of LogicalTypes, then it will not be considered.
> Therefore this issue is an attempt to add this ability into Avro Maven Plugin
> by adding a new configuration map type to the plugin, and will also register
> this logical type in the generated code.
>
> {panel:title=Cloned from AVRO-2621}
> So, as seen in AVRO-2498 we now have the ability in 1.9, at least using the
> Maven tools, to have generated classes with a field of type UUID. For some
> background, the secret sauce to get this working is:
> * Set the logicalType of the field to 'uuid' and type to 'string'
> * In the maven plugin configuration, add an item to with
> the value org.apache.avro.Conversions$UUIDConversion
> I attempted this with a custom type of my own (in this case, joda Money)
> first by implementing a CustomConversion class that created a new
> LogicalType called "money". This did not work, though, because although the
> maven mojo correctly added the CustomConversion to the SpecificCompiler, when
> the compiler parses the schema and sees the logicalType of type "money", it
> attempts to look up the LogicalType from LogicalTypes the LogicalType is not
> registered and it ignores it, which causes the field within the Schema to not
> have a logicalType. Without a logicalType, the compiler does not consider it
> a "UsedConversionClass" (see SpecificCompiler.getUsedConversionClass()) and
> they velocity template doesn't write the class with the custom field type.
> Trying to be clever, I attempted to work around this by putting a static
> initializer in my CustomConversion class which called
> LogicalTypes.register(). Unfortunately for me, the maven plugin doesn't load
> any of the classes specified in until AFTER it has parsed
> a schema.
> Obviously, putting a static initializer inside of a CustomConversion should
> not be part of a solution to this issue, but I propose a very simple solution:
> * Add a logicalTypes property to AbstractAvroMojo, with items of a new type,
> LocalTypeDefinition. That type will have a name and a logicalTypeFactory.
> * Upon startup of the mojo, iterate through each item and call
> LogicalTypes.register() on each, passing the indicated name and a new
> instance of the indicated logicalTypeFactory class.
> * At this point, the existing logic will treat the new custom type the same
> as "uuid" is treated and will generate SpecificRecord classes with fields of
> that type.
> I could implement this pretty trivially, if there's an appetite for it. This
> would seem to be 100% backwards compatible.
> {panel}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AVRO-2840) Maven allow Custom Logical Types for generated code
[
https://issues.apache.org/jira/browse/AVRO-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew McMahon updated AVRO-2840:
--
Description:
I was looking for a way to use my Custom Conversion in generated code, but as
detailed, without the Custom Logical Type being registered in the static
REGISTERED_TYPES of LogicalTypes, then it will not be considered.
Therefore this issue is an attempt to add this ability into Avro Maven Plugin
by adding a new configuration map type to the plugin, and will also register
this logical type in the generated code.
{panel:title=Cloned from AVRO-2621}
So, as seen in AVRO-2498 we now have the ability in 1.9, at least using the
Maven tools, to have generated classes with a field of type UUID. For some
background, the secret sauce to get this working is:
* Set the logicalType of the field to 'uuid' and type to 'string'
* In the maven plugin configuration, add an item to with
the value org.apache.avro.Conversions$UUIDConversion
I attempted this with a custom type of my own (in this case, joda Money) first
by implementing a CustomConversion class that created a new LogicalType
called "money". This did not work, though, because although the maven mojo
correctly added the CustomConversion to the SpecificCompiler, when the compiler
parses the schema and sees the logicalType of type "money", it attempts to look
up the LogicalType from LogicalTypes the LogicalType is not registered and it
ignores it, which causes the field within the Schema to not have a logicalType.
Without a logicalType, the compiler does not consider it a
"UsedConversionClass" (see SpecificCompiler.getUsedConversionClass()) and they
velocity template doesn't write the class with the custom field type.
Trying to be clever, I attempted to work around this by putting a static
initializer in my CustomConversion class which called LogicalTypes.register().
Unfortunately for me, the maven plugin doesn't load any of the classes
specified in until AFTER it has parsed a schema.
Obviously, putting a static initializer inside of a CustomConversion should not
be part of a solution to this issue, but I propose a very simple solution:
* Add a logicalTypes property to AbstractAvroMojo, with items of a new type,
LocalTypeDefinition. That type will have a name and a logicalTypeFactory.
* Upon startup of the mojo, iterate through each item and call
LogicalTypes.register() on each, passing the indicated name and a new instance
of the indicated logicalTypeFactory class.
* At this point, the existing logic will treat the new custom type the same as
"uuid" is treated and will generate SpecificRecord classes with fields of that
type.
I could implement this pretty trivially, if there's an appetite for it. This
would seem to be 100% backwards compatible.
{panel}
was:
So, as seen in AVRO-2498 we now have the ability in 1.9, at least using the
Maven tools, to have generated classes with a field of type UUID. For some
background, the secret sauce to get this working is:
* Set the logicalType of the field to 'uuid' and type to 'string'
* In the maven plugin configuration, add an item to with
the value org.apache.avro.Conversions$UUIDConversion
I attempted this with a custom type of my own (in this case, joda Money) first
by implementing a CustomConversion class that created a new LogicalType
called "money". This did not work, though, because although the maven mojo
correctly added the CustomConversion to the SpecificCompiler, when the compiler
parses the schema and sees the logicalType of type "money", it attempts to look
up the LogicalType from LogicalTypes the LogicalType is not registered and it
ignores it, which causes the field within the Schema to not have a logicalType.
Without a logicalType, the compiler does not consider it a
"UsedConversionClass" (see SpecificCompiler.getUsedConversionClass()) and they
velocity template doesn't write the class with the custom field type.
Trying to be clever, I attempted to work around this by putting a static
initializer in my CustomConversion class which called LogicalTypes.register().
Unfortunately for me, the maven plugin doesn't load any of the classes
specified in until AFTER it has parsed a schema.
Obviously, putting a static initializer inside of a CustomConversion should not
be part of a solution to this issue, but I propose a very simple solution:
* Add a logicalTypes property to AbstractAvroMojo, with items of a new type,
LocalTypeDefinition. That type will have a name and a logicalTypeFactory.
* Upon startup of the mojo, iterate through each item and call
LogicalTypes.register() on each, passing the indicated name and a new instance
of the indicated logicalTypeFactory class.
* At this point, the existing logic will treat the new custom type the same as
"uuid" is treated and will generate SpecificRecord classes with fields of that
type.
I
[jira] [Created] (AVRO-2840) Maven allow Custom Logical Types for generated code
Matthew McMahon created AVRO-2840: - Summary: Maven allow Custom Logical Types for generated code Key: AVRO-2840 URL: https://issues.apache.org/jira/browse/AVRO-2840 Project: Apache Avro Issue Type: Improvement Components: java Reporter: Matthew McMahon So, as seen in AVRO-2498 we now have the ability in 1.9, at least using the Maven tools, to have generated classes with a field of type UUID. For some background, the secret sauce to get this working is: * Set the logicalType of the field to 'uuid' and type to 'string' * In the maven plugin configuration, add an item to with the value org.apache.avro.Conversions$UUIDConversion I attempted this with a custom type of my own (in this case, joda Money) first by implementing a CustomConversion class that created a new LogicalType called "money". This did not work, though, because although the maven mojo correctly added the CustomConversion to the SpecificCompiler, when the compiler parses the schema and sees the logicalType of type "money", it attempts to look up the LogicalType from LogicalTypes the LogicalType is not registered and it ignores it, which causes the field within the Schema to not have a logicalType. Without a logicalType, the compiler does not consider it a "UsedConversionClass" (see SpecificCompiler.getUsedConversionClass()) and they velocity template doesn't write the class with the custom field type. Trying to be clever, I attempted to work around this by putting a static initializer in my CustomConversion class which called LogicalTypes.register(). Unfortunately for me, the maven plugin doesn't load any of the classes specified in until AFTER it has parsed a schema. Obviously, putting a static initializer inside of a CustomConversion should not be part of a solution to this issue, but I propose a very simple solution: * Add a logicalTypes property to AbstractAvroMojo, with items of a new type, LocalTypeDefinition. That type will have a name and a logicalTypeFactory. * Upon startup of the mojo, iterate through each item and call LogicalTypes.register() on each, passing the indicated name and a new instance of the indicated logicalTypeFactory class. * At this point, the existing logic will treat the new custom type the same as "uuid" is treated and will generate SpecificRecord classes with fields of that type. I could implement this pretty trivially, if there's an appetite for it. This would seem to be 100% backwards compatible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AVRO-2836) SpecificCompiler does not add DecimalConversion when logical type is a Fixed type
[
https://issues.apache.org/jira/browse/AVRO-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew McMahon updated AVRO-2836:
--
Status: Patch Available (was: Open)
> SpecificCompiler does not add DecimalConversion when logical type is a Fixed
> type
> -
>
> Key: AVRO-2836
> URL: https://issues.apache.org/jira/browse/AVRO-2836
> Project: Apache Avro
> Issue Type: Bug
> Components: java, logical types
>Affects Versions: 1.9.2
>Reporter: Matthew McMahon
>Priority: Major
> Attachments: AVRO-2836.patch
>
>
> I have updated to Avro 1.9.2 using the avro-maven-plugin to generate the
> specific types.
> This is working nicely, except noticed the case of:
> {code:java}
> "fields": [
> {
> "name": "unionOfFixedDecimal",
> "type": ["null", {
> "namespace": "org.apache.avro.codegentest.testdata",
> "name": "FixedInUnion",
> "type": "fixed",
> "size": 12,
> "logicalType": "decimal",
> "precision": 28,
> "scale": 15
> }]
> }] {code}
> This is a fixed type that has a logical type of decimal.
> When the source is generated, the type is BigDecimal. However the
> DecimalConversion is missing and then it breaks when used.
> It seems easy to workaround by manually adding the logical conversion before
> using.
> However the fix seems to be in
> SpecificCompiler#getClassNamesOfPrimitiveFields which is used by
> #getUsedConversionClasses
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AVRO-2837) Java DecimalConversion handling of scale and precision
[ https://issues.apache.org/jira/browse/AVRO-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew McMahon updated AVRO-2837: -- Status: Patch Available (was: Open) > Java DecimalConversion handling of scale and precision > -- > > Key: AVRO-2837 > URL: https://issues.apache.org/jira/browse/AVRO-2837 > Project: Apache Avro > Issue Type: Bug > Components: java, logical types >Affects Versions: 1.9.2, 1.8.2 >Reporter: Matthew McMahon >Priority: Major > Attachments: AVRO-2837.patch, AVRO-2837.patch > > > Came across an interesting issue in Avro 1.8.2 > Configured a decimal logical type (Fixed type of size 12 with scale of 15 and > precision of 28). > Due to an upstream bug, a value of 1070464558597365250.000 > (1.07046455859736525E+18 that is then rescaled to 15) appears, and the > DecimalConversion attempts to turn it into a Fixed type. > This should have failed, as it has a precision of 34 and won't fit into the > 12 bytes (needs 14). However in 1.8.2 this still writes a value that > downstream processing then works out is invalid and errors. > Basically the top 2 bytes are thrown away. > This problem is fixed in 1.9.2 due to the change in > https://issues.apache.org/jira/browse/AVRO-2309 as this particular issue > fails when it attempts to pass an offset of -2 to the System.arraycopy method. > That seems ok, but is a bit of a red herring to the actual issue, and > precision is still not actually being checked. > Proposing a couple changes to the DecimalConversion: > * Check precision set on the decimal logical type. If value has greater > precision then error with more informative message > * Still check scale and error if value has a greater scale. However if the > scale in value is less, than it seems safe to update the scale and pad zero's > rather than error > * Do this for both Bytes and Fixed types > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AVRO-2836) SpecificCompiler does not add DecimalConversion when logical type is a Fixed type
[
https://issues.apache.org/jira/browse/AVRO-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108231#comment-17108231
]
Matthew McMahon edited comment on AVRO-2836 at 5/18/20, 12:41 AM:
--
[^AVRO-2836.patch]
Also created PR at [https://github.com/apache/avro/pull/883]
Appreciate any feedback
was (Author: maccamlc):
[^AVRO-2836.patch]
Also created PR in Gitlab at [https://github.com/apache/avro/pull/883]
Appreciate any feedback
> SpecificCompiler does not add DecimalConversion when logical type is a Fixed
> type
> -
>
> Key: AVRO-2836
> URL: https://issues.apache.org/jira/browse/AVRO-2836
> Project: Apache Avro
> Issue Type: Bug
> Components: java, logical types
>Affects Versions: 1.9.2
>Reporter: Matthew McMahon
>Priority: Major
> Attachments: AVRO-2836.patch
>
>
> I have updated to Avro 1.9.2 using the avro-maven-plugin to generate the
> specific types.
> This is working nicely, except noticed the case of:
> {code:java}
> "fields": [
> {
> "name": "unionOfFixedDecimal",
> "type": ["null", {
> "namespace": "org.apache.avro.codegentest.testdata",
> "name": "FixedInUnion",
> "type": "fixed",
> "size": 12,
> "logicalType": "decimal",
> "precision": 28,
> "scale": 15
> }]
> }] {code}
> This is a fixed type that has a logical type of decimal.
> When the source is generated, the type is BigDecimal. However the
> DecimalConversion is missing and then it breaks when used.
> It seems easy to workaround by manually adding the logical conversion before
> using.
> However the fix seems to be in
> SpecificCompiler#getClassNamesOfPrimitiveFields which is used by
> #getUsedConversionClasses
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109535#comment-17109535 ] Hudson commented on AVRO-2752: -- SUCCESS: Integrated in Jenkins build AvroJava #875 (See [https://builds.apache.org/job/AvroJava/875/]) AVRO-2752: PHP: Setup as Composer package on Packagist.org (#878) (github: [https://github.com/apache/avro/commit/1eb2eb7212d2c63cb96299de2f319c9f2a5a8162]) * (edit) share/docker/Dockerfile * (add) composer.json * (delete) lang/php/test/AllTests.php * (add) lang/php/phpunit.xml * (add) lang/php/monorepo.json * (edit) .gitignore * (edit) lang/php/.gitignore * (edit) lang/php/test/test_helper.php * (edit) lang/php/build.sh > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Assignee: Siad Ardroumli >Priority: Major > Fix For: 1.10.0 > > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109520#comment-17109520 ] ASF subversion and git services commented on AVRO-2752: --- Commit 1eb2eb7212d2c63cb96299de2f319c9f2a5a8162 in avro's branch refs/heads/master from Siad Ardroumli [ https://gitbox.apache.org/repos/asf?p=avro.git;h=1eb2eb7 ] AVRO-2752: PHP: Setup as Composer package on Packagist.org (#878) * AVRO-2752: PHP - add composer support. * AVRO-2752: Added license. * AVRO-2752: install composer. * AVRO-2752: fixed working dir. * AVRO-2752: Fix composer install. * AVRO-2752: Add missing ext. * AVRO-2752: Add missing ext 2. * AVRO-2752: Fix PHP install. * AVRO-2752: Fix PHP7.3 install. > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Priority: Major > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109518#comment-17109518 ] ASF subversion and git services commented on AVRO-2752: --- Commit 1eb2eb7212d2c63cb96299de2f319c9f2a5a8162 in avro's branch refs/heads/master from Siad Ardroumli [ https://gitbox.apache.org/repos/asf?p=avro.git;h=1eb2eb7 ] AVRO-2752: PHP: Setup as Composer package on Packagist.org (#878) * AVRO-2752: PHP - add composer support. * AVRO-2752: Added license. * AVRO-2752: install composer. * AVRO-2752: fixed working dir. * AVRO-2752: Fix composer install. * AVRO-2752: Add missing ext. * AVRO-2752: Add missing ext 2. * AVRO-2752: Fix PHP install. * AVRO-2752: Fix PHP7.3 install. > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Priority: Major > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fokko Driesprong resolved AVRO-2752. Fix Version/s: 1.10.0 Assignee: Siad Ardroumli Resolution: Fixed > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Assignee: Siad Ardroumli >Priority: Major > Fix For: 1.10.0 > > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109517#comment-17109517 ] ASF subversion and git services commented on AVRO-2752: --- Commit 1eb2eb7212d2c63cb96299de2f319c9f2a5a8162 in avro's branch refs/heads/master from Siad Ardroumli [ https://gitbox.apache.org/repos/asf?p=avro.git;h=1eb2eb7 ] AVRO-2752: PHP: Setup as Composer package on Packagist.org (#878) * AVRO-2752: PHP - add composer support. * AVRO-2752: Added license. * AVRO-2752: install composer. * AVRO-2752: fixed working dir. * AVRO-2752: Fix composer install. * AVRO-2752: Add missing ext. * AVRO-2752: Add missing ext 2. * AVRO-2752: Fix PHP install. * AVRO-2752: Fix PHP7.3 install. > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Priority: Major > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109515#comment-17109515 ] ASF subversion and git services commented on AVRO-2752: --- Commit 1eb2eb7212d2c63cb96299de2f319c9f2a5a8162 in avro's branch refs/heads/master from Siad Ardroumli [ https://gitbox.apache.org/repos/asf?p=avro.git;h=1eb2eb7 ] AVRO-2752: PHP: Setup as Composer package on Packagist.org (#878) * AVRO-2752: PHP - add composer support. * AVRO-2752: Added license. * AVRO-2752: install composer. * AVRO-2752: fixed working dir. * AVRO-2752: Fix composer install. * AVRO-2752: Add missing ext. * AVRO-2752: Add missing ext 2. * AVRO-2752: Fix PHP install. * AVRO-2752: Fix PHP7.3 install. > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Priority: Major > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109513#comment-17109513 ] ASF subversion and git services commented on AVRO-2752: --- Commit 1eb2eb7212d2c63cb96299de2f319c9f2a5a8162 in avro's branch refs/heads/master from Siad Ardroumli [ https://gitbox.apache.org/repos/asf?p=avro.git;h=1eb2eb7 ] AVRO-2752: PHP: Setup as Composer package on Packagist.org (#878) * AVRO-2752: PHP - add composer support. * AVRO-2752: Added license. * AVRO-2752: install composer. * AVRO-2752: fixed working dir. * AVRO-2752: Fix composer install. * AVRO-2752: Add missing ext. * AVRO-2752: Add missing ext 2. * AVRO-2752: Fix PHP install. * AVRO-2752: Fix PHP7.3 install. > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Priority: Major > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109514#comment-17109514 ] ASF subversion and git services commented on AVRO-2752: --- Commit 1eb2eb7212d2c63cb96299de2f319c9f2a5a8162 in avro's branch refs/heads/master from Siad Ardroumli [ https://gitbox.apache.org/repos/asf?p=avro.git;h=1eb2eb7 ] AVRO-2752: PHP: Setup as Composer package on Packagist.org (#878) * AVRO-2752: PHP - add composer support. * AVRO-2752: Added license. * AVRO-2752: install composer. * AVRO-2752: fixed working dir. * AVRO-2752: Fix composer install. * AVRO-2752: Add missing ext. * AVRO-2752: Add missing ext 2. * AVRO-2752: Fix PHP install. * AVRO-2752: Fix PHP7.3 install. > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Priority: Major > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109519#comment-17109519 ] ASF subversion and git services commented on AVRO-2752: --- Commit 1eb2eb7212d2c63cb96299de2f319c9f2a5a8162 in avro's branch refs/heads/master from Siad Ardroumli [ https://gitbox.apache.org/repos/asf?p=avro.git;h=1eb2eb7 ] AVRO-2752: PHP: Setup as Composer package on Packagist.org (#878) * AVRO-2752: PHP - add composer support. * AVRO-2752: Added license. * AVRO-2752: install composer. * AVRO-2752: fixed working dir. * AVRO-2752: Fix composer install. * AVRO-2752: Add missing ext. * AVRO-2752: Add missing ext 2. * AVRO-2752: Fix PHP install. * AVRO-2752: Fix PHP7.3 install. > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Priority: Major > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109512#comment-17109512 ] ASF subversion and git services commented on AVRO-2752: --- Commit 1eb2eb7212d2c63cb96299de2f319c9f2a5a8162 in avro's branch refs/heads/master from Siad Ardroumli [ https://gitbox.apache.org/repos/asf?p=avro.git;h=1eb2eb7 ] AVRO-2752: PHP: Setup as Composer package on Packagist.org (#878) * AVRO-2752: PHP - add composer support. * AVRO-2752: Added license. * AVRO-2752: install composer. * AVRO-2752: fixed working dir. * AVRO-2752: Fix composer install. * AVRO-2752: Add missing ext. * AVRO-2752: Add missing ext 2. * AVRO-2752: Fix PHP install. * AVRO-2752: Fix PHP7.3 install. > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Priority: Major > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109516#comment-17109516 ] ASF subversion and git services commented on AVRO-2752: --- Commit 1eb2eb7212d2c63cb96299de2f319c9f2a5a8162 in avro's branch refs/heads/master from Siad Ardroumli [ https://gitbox.apache.org/repos/asf?p=avro.git;h=1eb2eb7 ] AVRO-2752: PHP: Setup as Composer package on Packagist.org (#878) * AVRO-2752: PHP - add composer support. * AVRO-2752: Added license. * AVRO-2752: install composer. * AVRO-2752: fixed working dir. * AVRO-2752: Fix composer install. * AVRO-2752: Add missing ext. * AVRO-2752: Add missing ext 2. * AVRO-2752: Fix PHP install. * AVRO-2752: Fix PHP7.3 install. > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Priority: Major > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109511#comment-17109511 ] ASF subversion and git services commented on AVRO-2752: --- Commit 1eb2eb7212d2c63cb96299de2f319c9f2a5a8162 in avro's branch refs/heads/master from Siad Ardroumli [ https://gitbox.apache.org/repos/asf?p=avro.git;h=1eb2eb7 ] AVRO-2752: PHP: Setup as Composer package on Packagist.org (#878) * AVRO-2752: PHP - add composer support. * AVRO-2752: Added license. * AVRO-2752: install composer. * AVRO-2752: fixed working dir. * AVRO-2752: Fix composer install. * AVRO-2752: Add missing ext. * AVRO-2752: Add missing ext 2. * AVRO-2752: Fix PHP install. * AVRO-2752: Fix PHP7.3 install. > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Priority: Major > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [avro] Fokko merged pull request #878: AVRO-2752: PHP: Setup as Composer package on Packagist.org
Fokko merged pull request #878: URL: https://github.com/apache/avro/pull/878 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [avro] siad007 opened a new pull request #886: AVRO-2839: Add zstd and snappy codec support.
siad007 opened a new pull request #886: URL: https://github.com/apache/avro/pull/886 Added support for Zstandard and snappy codecs. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (AVRO-2839) PHP: Add support for zstd and snappy codec
Siad Ardroumli created AVRO-2839: Summary: PHP: Add support for zstd and snappy codec Key: AVRO-2839 URL: https://issues.apache.org/jira/browse/AVRO-2839 Project: Apache Avro Issue Type: Improvement Components: php Environment: Add support for zstd and snappy codecs, if appropiate extension is available. * zstd ** https://pecl.php.net/package/zstd * snappy ** [https://github.com/kjdev/php-ext-snappy] Reporter: Siad Ardroumli -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AVRO-2839) PHP: Add support for zstd and snappy codec
[ https://issues.apache.org/jira/browse/AVRO-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siad Ardroumli updated AVRO-2839: - Description: Add support for zstd and snappy codecs, if appropiate extension is available. * zstd ** [https://pecl.php.net/package/zstd] * snappy ** [https://github.com/kjdev/php-ext-snappy] > PHP: Add support for zstd and snappy codec > -- > > Key: AVRO-2839 > URL: https://issues.apache.org/jira/browse/AVRO-2839 > Project: Apache Avro > Issue Type: Improvement > Components: php > Environment: > >Reporter: Siad Ardroumli >Priority: Major > > Add support for zstd and snappy codecs, if appropiate extension is available. > * zstd > ** [https://pecl.php.net/package/zstd] > * snappy > ** [https://github.com/kjdev/php-ext-snappy] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AVRO-2839) PHP: Add support for zstd and snappy codec
[ https://issues.apache.org/jira/browse/AVRO-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siad Ardroumli updated AVRO-2839: - Environment: was: Add support for zstd and snappy codecs, if appropiate extension is available. * zstd ** https://pecl.php.net/package/zstd * snappy ** [https://github.com/kjdev/php-ext-snappy] > PHP: Add support for zstd and snappy codec > -- > > Key: AVRO-2839 > URL: https://issues.apache.org/jira/browse/AVRO-2839 > Project: Apache Avro > Issue Type: Improvement > Components: php > Environment: > >Reporter: Siad Ardroumli >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
