Build failed in Jenkins: AvroJava #632

2019-03-31 Thread Apache Jenkins Server 
See 

Changes:

[Fokko] AVRO-2199: Validate that field defaults have the correct type  (#497)

[Fokko] AVRO-2357: Allow generic types in reflect protos (#490)

--
[...truncated 274.21 KB...]
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at 
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)

[ERROR] 
testCompileSchemasWithVariousFieldTypes(org.apache.avro.tool.TestSpecificCompilerTool)
  Time elapsed: 0.288 s  <<< FAILURE!
org.junit.ComparisonFailure: Found file: 
target/compiler/output-string/avro/examples/baseball/FieldTest.java does not 
match expected file: 
src/test/compiler/output-string/avro/examples/baseball/FieldTest.java 
expected:<...rg.apache.avro.data.[TimeConversions.TimestampMillisConversion()); 
   MODEL$.addLogicalTypeConversion(new 
org.apache.avro.data.TimeConversions.TimeMillisConversion());  }  private 
static final BinaryMessageEncoder ENCODER =  new 
BinaryMessageEncoder(MODEL$, SCHEMA$);  private static final 
BinaryMessageDecoder DECODER =  new 
BinaryMessageDecoder(MODEL$, SCHEMA$);  /**   * Return the 
BinaryMessageEncoder instance used by this class.   * @return the message 
encoder used by this class   */  public static BinaryMessageEncoder 
getEncoder() {return ENCODER;  }  /**   * Return the BinaryMessageDecoder 
instance used by this class.   * @return the message decoder used by this class 
  */  public static BinaryMessageDecoder getDecoder() {return 
DECODER;  }  /**   * Create a new BinaryMessageDecoder instance for this class 
that uses the specified {@link SchemaStore}.   * @param resolver a {@link 
SchemaStore} used to find schemas by fingerprint   * @return a 
BinaryMessageDecoder instance for this class backed by the given SchemaStore   
*/  public static BinaryMessageDecoder createDecoder(SchemaStore 
resolver) {return new BinaryMessageDecoder(MODEL$, SCHEMA$, 
resolver);  }  /**   * Serializes this FieldTest to a ByteBuffer.   * @return a 
buffer holding the serialized data for this instance   * @throws 
java.io.IOException if this instance could not be serialized   */  public 
java.nio.ByteBuffer toByteBuffer() throws java.io.IOException {return 
ENCODER.encode(this);  }  /**   * Deserializes a FieldTest from a ByteBuffer.   
* @param b a byte buffer holding serialized data for an instance of this class  
 * @return a FieldTest instance decoded from the given buffer   * @throws 
java.io.IOException if the given bytes could not be deserialized into an 
instance of this class   */  public static FieldTest fromByteBuffer(  
java.nio.ByteBuffer b) throws java.io.IOException {return 
DECODER.decode(b);  }  /** The number of the player */   private int number;   
private java.lang.String last_name;   private java.time.Instant timestamp;   
private java.time.Instant timestampMicros;   private java.time.LocalTime 
timeMillis;   private java.time.LocalTime timeMicros;  /**   * Default 
constructor.  Note that this does not initialize fields   * to their default 
values from the schema.  If that is desired then   * one should use 
newBuilder().   */  public FieldTest() {}  /**   * All-args 
constructor.   * @param number The number of the player   * @param last_name 
The new value for last_name   * @param timestamp The new value for timestamp   
* @param timestampMicros The new value for timestampMicros   * @param 
timeMillis The new value for timeMillis   * @param timeMicros The new value for 
timeMicros   */  public FieldTest(java.lang.Integer number, java.lang.String 
last_name, java.time.Instant timestamp, java.time.Instant timestampMicros, 
java.time.LocalTime timeMillis, java.time.LocalTime timeMicros) {
this.number = number;this.last_name = last_name;this.timestamp = 
timestamp.truncatedTo(java.time.temporal.ChronoUnit.MILLIS);
this.timestampMicros = 
timestampMicros.truncatedTo(java.time.temporal.ChronoUnit.MICROS);
this.timeMillis = timeMillis.truncatedTo(java.time.temporal.ChronoUnit.MILLIS); 
   this.timeMicros =

[jira] [Commented] (AVRO-2357) (ReflectData) Support for generic types in protocol definitions

2019-03-31 Thread Hudson (JIRA) 


[ 
https://issues.apache.org/jira/browse/AVRO-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806215#comment-16806215
 ] 

Hudson commented on AVRO-2357:
--

FAILURE: Integrated in Jenkins build AvroJava #632 (See 
[https://builds.apache.org/job/AvroJava/632/])
AVRO-2357: Allow generic types in reflect protos (#490) (fokko: 
[https://github.com/apache/avro/commit/de48a0a8a0343b61fdb255011fde38c619761046])
* (edit) 
lang/java/avro/src/main/java/org/apache/avro/reflect/ReflectionUtil.java
* (edit) 
lang/java/avro/src/test/java/org/apache/avro/reflect/TestReflectData.java
* (edit) lang/java/avro/src/main/java/org/apache/avro/reflect/ReflectData.java


> (ReflectData) Support for generic types in protocol definitions
> ---
>
> Key: AVRO-2357
> URL: https://issues.apache.org/jira/browse/AVRO-2357
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: Ivan Greene
>Priority: Minor
> Fix For: 1.9.0
>
>
> For a Java interface extending another interface with type parameters, we may 
> resolve actual type parameters and build the protocol definition based upon 
> those.
> For example, let's say we have a generic protocol defined by a Java interface:
> {code:java}
> public interface CrudProto {
>   void persist(T record);
>   T fetchById(I id);
> }{code}
> It would be natural to define a set of interfaces that extend this, such as:
> {code:java}
> public interface FooBarRecordProto extends CrudProto {}
> public interface OtherRecordProto extends CrudProto {}
> {code}
> Calling ReflectData.get().getProtocol(FooBarRecordProto.class) should be able 
> to resolve that this protocol deals in FooBarRecords and Strings, and build a 
> protocol accordingly.
> Currently, this call will produce an exception stating that a schema for 'T' 
> cannot be resolved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2199) Validate that field defaults have the correct type

2019-03-31 Thread Hudson (JIRA) 


[ 
https://issues.apache.org/jira/browse/AVRO-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806214#comment-16806214
 ] 

Hudson commented on AVRO-2199:
--

FAILURE: Integrated in Jenkins build AvroJava #632 (See 
[https://builds.apache.org/job/AvroJava/632/])
AVRO-2199: Validate that field defaults have the correct type  (#497) (fokko: 
[https://github.com/apache/avro/commit/392c761952ec7f679b29ae28129403ea8cf307ea])
* (edit) lang/ruby/test/test_schema.rb
* (edit) lang/ruby/test/test_datafile.rb
* (edit) lang/ruby/.gitignore
* (edit) lang/ruby/lib/avro.rb
* (edit) lang/ruby/lib/avro/schema.rb


>  Validate that field defaults have the correct type
> ---
>
> Key: AVRO-2199
> URL: https://issues.apache.org/jira/browse/AVRO-2199
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: ruby
>Affects Versions: 1.8.2
>Reporter: Daniel Orner
>Assignee: Tim Perkins
>Priority: Minor
> Fix For: 1.9.0
>
> Attachments: AVRO-2199.patch
>
>
> Currently, on the master branch, when a schema is parsed, it is possible to 
> define a field with a type and a default of a totally different type. E.g. if 
> the field has type "string", the default can be set to "null".
> I'd like to open a PR which will fix this by running the default through the 
> SchemaValidator whenever a new Field is created. See 
> [https://github.com/salsify/avro-patches/pull/16]
> cc: [~tjwp]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2357) (ReflectData) Support for generic types in protocol definitions

2019-03-31 Thread ASF subversion and git services (JIRA) 


[ 
https://issues.apache.org/jira/browse/AVRO-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806198#comment-16806198
 ] 

ASF subversion and git services commented on AVRO-2357:
---

Commit de48a0a8a0343b61fdb255011fde38c619761046 in avro's branch 
refs/heads/master from ivangreene
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=de48a0a ]

AVRO-2357: Allow generic types in reflect protos (#490)

Adds support for generic types in ReflectData for
Protocols.

> (ReflectData) Support for generic types in protocol definitions
> ---
>
> Key: AVRO-2357
> URL: https://issues.apache.org/jira/browse/AVRO-2357
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: Ivan Greene
>Priority: Minor
>
> For a Java interface extending another interface with type parameters, we may 
> resolve actual type parameters and build the protocol definition based upon 
> those.
> For example, let's say we have a generic protocol defined by a Java interface:
> {code:java}
> public interface CrudProto {
>   void persist(T record);
>   T fetchById(I id);
> }{code}
> It would be natural to define a set of interfaces that extend this, such as:
> {code:java}
> public interface FooBarRecordProto extends CrudProto {}
> public interface OtherRecordProto extends CrudProto {}
> {code}
> Calling ReflectData.get().getProtocol(FooBarRecordProto.class) should be able 
> to resolve that this protocol deals in FooBarRecords and Strings, and build a 
> protocol accordingly.
> Currently, this call will produce an exception stating that a schema for 'T' 
> cannot be resolved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (AVRO-2335) Remove Joda Time Library

2019-03-31 Thread Fokko Driesprong (JIRA) 


 [ 
https://issues.apache.org/jira/browse/AVRO-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fokko Driesprong updated AVRO-2335:
---
Fix Version/s: 1.10.0

> Remove Joda Time Library
> 
>
> Key: AVRO-2335
> URL: https://issues.apache.org/jira/browse/AVRO-2335
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: David Mollitor
>Assignee: Fokko Driesprong
>Priority: Major
> Fix For: 1.10.0
>
>
> Since [AVRO-2079] was completed, Avro supports Java's standard {{java.time}} 
> libraries.  Please remove the Joda Time implementations and the Joda Time 
> dependency from Avro.  Avro 2.0 perhaps?
> {quote}
> Joda-Time is the de facto standard date and time library for Java prior to 
> Java SE 8. *Users are now asked to migrate to java.time (JSR-310).*
> https://www.joda.org/joda-time/
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Work started] (AVRO-2335) Remove Joda Time Library

2019-03-31 Thread Fokko Driesprong (JIRA) 


 [ 
https://issues.apache.org/jira/browse/AVRO-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on AVRO-2335 started by Fokko Driesprong.
--
> Remove Joda Time Library
> 
>
> Key: AVRO-2335
> URL: https://issues.apache.org/jira/browse/AVRO-2335
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: David Mollitor
>Assignee: Fokko Driesprong
>Priority: Major
>
> Since [AVRO-2079] was completed, Avro supports Java's standard {{java.time}} 
> libraries.  Please remove the Joda Time implementations and the Joda Time 
> dependency from Avro.  Avro 2.0 perhaps?
> {quote}
> Joda-Time is the de facto standard date and time library for Java prior to 
> Java SE 8. *Users are now asked to migrate to java.time (JSR-310).*
> https://www.joda.org/joda-time/
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2199) Validate that field defaults have the correct type

2019-03-31 Thread ASF subversion and git services (JIRA) 


[ 
https://issues.apache.org/jira/browse/AVRO-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806193#comment-16806193
 ] 

ASF subversion and git services commented on AVRO-2199:
---

Commit 392c761952ec7f679b29ae28129403ea8cf307ea in avro's branch 
refs/heads/master from Tim Perkins
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=392c761 ]

AVRO-2199: Validate that field defaults have the correct type  (#497)

* AVRO-2199:  Validate that field defaults have the correct type

* AVRO-2199: Code review comments

* AVRO-2199: Make it configurable whether field default validation is enforced 
for Ruby


>  Validate that field defaults have the correct type
> ---
>
> Key: AVRO-2199
> URL: https://issues.apache.org/jira/browse/AVRO-2199
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: ruby
>Affects Versions: 1.8.2
>Reporter: Daniel Orner
>Priority: Minor
> Fix For: 1.9.0
>
> Attachments: AVRO-2199.patch
>
>
> Currently, on the master branch, when a schema is parsed, it is possible to 
> define a field with a type and a default of a totally different type. E.g. if 
> the field has type "string", the default can be set to "null".
> I'd like to open a PR which will fix this by running the default through the 
> SchemaValidator whenever a new Field is created. See 
> [https://github.com/salsify/avro-patches/pull/16]
> cc: [~tjwp]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2199) Validate that field defaults have the correct type

2019-03-31 Thread ASF subversion and git services (JIRA) 


[ 
https://issues.apache.org/jira/browse/AVRO-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806192#comment-16806192
 ] 

ASF subversion and git services commented on AVRO-2199:
---

Commit 392c761952ec7f679b29ae28129403ea8cf307ea in avro's branch 
refs/heads/master from Tim Perkins
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=392c761 ]

AVRO-2199: Validate that field defaults have the correct type  (#497)

* AVRO-2199:  Validate that field defaults have the correct type

* AVRO-2199: Code review comments

* AVRO-2199: Make it configurable whether field default validation is enforced 
for Ruby


>  Validate that field defaults have the correct type
> ---
>
> Key: AVRO-2199
> URL: https://issues.apache.org/jira/browse/AVRO-2199
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: ruby
>Affects Versions: 1.8.2
>Reporter: Daniel Orner
>Priority: Minor
> Fix For: 1.9.0
>
> Attachments: AVRO-2199.patch
>
>
> Currently, on the master branch, when a schema is parsed, it is possible to 
> define a field with a type and a default of a totally different type. E.g. if 
> the field has type "string", the default can be set to "null".
> I'd like to open a PR which will fix this by running the default through the 
> SchemaValidator whenever a new Field is created. See 
> [https://github.com/salsify/avro-patches/pull/16]
> cc: [~tjwp]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2199) Validate that field defaults have the correct type

2019-03-31 Thread ASF subversion and git services (JIRA) 


[ 
https://issues.apache.org/jira/browse/AVRO-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806195#comment-16806195
 ] 

ASF subversion and git services commented on AVRO-2199:
---

Commit 392c761952ec7f679b29ae28129403ea8cf307ea in avro's branch 
refs/heads/master from Tim Perkins
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=392c761 ]

AVRO-2199: Validate that field defaults have the correct type  (#497)

* AVRO-2199:  Validate that field defaults have the correct type

* AVRO-2199: Code review comments

* AVRO-2199: Make it configurable whether field default validation is enforced 
for Ruby


>  Validate that field defaults have the correct type
> ---
>
> Key: AVRO-2199
> URL: https://issues.apache.org/jira/browse/AVRO-2199
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: ruby
>Affects Versions: 1.8.2
>Reporter: Daniel Orner
>Priority: Minor
> Fix For: 1.9.0
>
> Attachments: AVRO-2199.patch
>
>
> Currently, on the master branch, when a schema is parsed, it is possible to 
> define a field with a type and a default of a totally different type. E.g. if 
> the field has type "string", the default can be set to "null".
> I'd like to open a PR which will fix this by running the default through the 
> SchemaValidator whenever a new Field is created. See 
> [https://github.com/salsify/avro-patches/pull/16]
> cc: [~tjwp]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (AVRO-2199) Validate that field defaults have the correct type

2019-03-31 Thread Fokko Driesprong (JIRA) 


 [ 
https://issues.apache.org/jira/browse/AVRO-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fokko Driesprong updated AVRO-2199:
---
Resolution: Fixed
  Assignee: Tim Perkins
Status: Resolved  (was: Patch Available)

>  Validate that field defaults have the correct type
> ---
>
> Key: AVRO-2199
> URL: https://issues.apache.org/jira/browse/AVRO-2199
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: ruby
>Affects Versions: 1.8.2
>Reporter: Daniel Orner
>Assignee: Tim Perkins
>Priority: Minor
> Fix For: 1.9.0
>
> Attachments: AVRO-2199.patch
>
>
> Currently, on the master branch, when a schema is parsed, it is possible to 
> define a field with a type and a default of a totally different type. E.g. if 
> the field has type "string", the default can be set to "null".
> I'd like to open a PR which will fix this by running the default through the 
> SchemaValidator whenever a new Field is created. See 
> [https://github.com/salsify/avro-patches/pull/16]
> cc: [~tjwp]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2201) avro-maven-plugin should be able to import schema from generated specificrecord

2019-03-31 Thread Zoltan Farkas (JIRA) 


[ 
https://issues.apache.org/jira/browse/AVRO-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806129#comment-16806129
 ] 

Zoltan Farkas commented on AVRO-2201:
-

Another way to achieve a similar result is to publish the generated avsc (and 
idl) along with the java classes. Once you do that you can import them easily 
through te existing methods...

I have some examples here: [https://github.com/zolyfarkas/avro-schema-examples] 

not generating duplicate classes is being done by the plugin itself...

 

> avro-maven-plugin should be able to import schema from generated 
> specificrecord
> ---
>
> Key: AVRO-2201
> URL: https://issues.apache.org/jira/browse/AVRO-2201
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: mateusz kanarek
>Priority: Major
>
> Currently SchemaMojo can read avro schemas only from avsc files.
> One can define avro schema and using current SchemaMojo build a jar with 
> generated SpecificRecord(s).
> But there is no easy way to reference this schema from avsc schema in another 
> maven project.
> It would be great if avsc files could reference to avro schema from already 
> generated SpecificRecord.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)