[hibernate-dev] Fwd: Build failed in Jenkins: hibernate-orm-master-h2 #1316

Anyone know what is up with this Javadoc tool failure in these jobs? We've had the same failure for the last few builds... -- Forwarded message - From: Hibernate CI Date: Tue, Jan 26, 2016 at 4:09 AM Subject: Build failed in Jenkins: hibernate-orm-master-h2 #1316 To: , See

Re: [hibernate-dev] Fwd: Build failed in Jenkins: hibernate-orm-master-h2 #1316

I could replicate it on my local machine too: javadoc: error - java.lang.ClassCastException: com.sun.tools.javadoc.MethodDocImpl cannot be cast to com.sun.tools.javadoc.AnnotationTypeElementDocImpl :documentation:aggregateJavadocs FAILED http://stackoverflow.com/questions/44853/why-am-i-getting-a

Re: [hibernate-dev] Fwd: Build failed in Jenkins: hibernate-orm-master-h2 #1316

the failure is caused by the javadoc of AvailabeSettings#GLOBALLY_QUOTED_IDENTIFIERS_SKIP_COLUMN_DEFINITIONS I'm fixing it On 26 January 2016 at 15:55, Vlad Mihalcea wrote: > I could replicate it on my local machine too: > > javadoc: error - java.lang.ClassCastException: > com.sun.tools.javadoc.

[hibernate-dev] Eclipse tools for Hibernate Search

Hello all, I'm thrilled to announce that there is now Eclipse tooling available to help developers using Hibernate Search. This was created by Dmitry Bocharov, started this summer as a GSOC summer of code and still volunteering on it. Better described in his own words on our blog: - http://in.re

Re: [hibernate-dev] Fwd: Build failed in Jenkins: hibernate-orm-master-h2 #1316

Yes, I just found that too. But what specifically? I found it by brute force lol On Tue, Jan 26, 2016 at 10:07 AM andrea boriero wrote: > the failure is caused by the javadoc of > AvailabeSettings#GLOBALLY_QUOTED_IDENTIFIERS_SKIP_COLUMN_DEFINITIONS > I'm fixing it > > On 26 January 2016 at 15

Re: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in Oracle

This has come up again under HHH-10345[1]. The original request here claims that Oracle have deprecated LONG ( LONGVARCHAR) and LONG RAW (LONGVARBINARY). It refers to the 9i release notes as "proof" of that[2]. The 9i release notes do mention LONG (LONGVARCHAR) datatype being deprecated. Howeve

Re: [hibernate-dev] [hibernate-announce] Eclipse tools for Hibernate Search

Awesome! Congrats everyone, very exciting! On Tue, Jan 26, 2016 at 10:11 AM Sanne Grinovero wrote: > Hello all, > I'm thrilled to announce that there is now Eclipse tooling available > to help developers using Hibernate Search. > > This was created by Dmitry Bocharov, started this summer as a G

Re: [hibernate-dev] Fwd: Build failed in Jenkins: hibernate-orm-master-h2 #1316

the only solution i found is to use {@link javax.persistence.Column @Column(columnDefinition="...")} and {@link javax.persistence.JoinColumn @JoinColumn(columnDefinition="..."} but I wasn't able to find why it fails with {@link javax.persistence.Column @Column#columnDefinition()} and {@link jav

[hibernate-dev] Configuration to support batching (or sorting) of DELETE statements efficiently

Hi, Hibernate provides simple configuration properties to enable batch inserts and updates using "hibernate.order_inserts" and "hibernate.order_updates" respectively. These setting allow hibernate to sort the insert and update statements and process them in batches efficiently. But we don't have

Re: [hibernate-dev] Fwd: Build failed in Jenkins: hibernate-orm-master-h2 #1316

I think it's a Java bug because the same Javadoc entry is found in the org.hibernate.engine.jdbc.env.spi.IdentifierHelper interface: /** * Intended only for use in handling quoting requirements for {@code column-definition} * as defined by {@link javax.persistence.Column#columnDefinition()}, *

Re: [hibernate-dev] Configuration to support batching (or sorting) of DELETE statements efficiently

This must be done like insert but in reverse order. With inserts, we need to add parents first and children after, because of the foreign key constraints. For delete, we need to group children first and delete them prior to deleting parents. Is there something that prevents us from implementing th