Hi guys, I just tried the latest beta and I cannot compile my project. With the latest hibernate 4.3.X I was able to do this: ------- final org.hibernate.cfg.Configuration configuration = getHibernateConfiguration(); configuration.buildMappings(); final SchemaUpdate schemaUpdate = new SchemaUpdate(configuration); ------- however it seems that the SchemaUpdate constructor has been removed and now a new one is added: -------- public SchemaUpdate(MetadataImplementor metadata) { this( metadata.getMetadataBuildingOptions().getServiceRegistry(), metadata ); } --------- Also the configuration.buildMappings() method has been deprecated. Where do I get the MetadataImplementor from? Also is there any changelog I can refer to? Thanks. -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

hibernate-core seems to be the only artifact that is available in JBoss Nexus. On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > So apparently the artifacts / repo issue is a Nexus bug that is effecting > the JBoss repo (and therefore us)... > http://issues.sonatype.org/browse/NEXUS-7654 > > As I pointed out in the announcement, I am managing the "migration guide" > in source repo while I develop the Betas. See > https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... > As far are the new bootstrapping apis, see > http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... > and > http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... > > On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; > wrote: > >> Hi guys, >> >> I just tried the latest beta and I cannot compile my project. With the >> latest hibernate 4.3.X I was able to do this: >> ------- >> final org.hibernate.cfg.Configuration configuration = >> getHibernateConfiguration(); >> configuration.buildMappings(); >> final SchemaUpdate schemaUpdate = new >> SchemaUpdate(configuration); >> ------- >> >> however it seems that the SchemaUpdate constructor has been removed and >> now >> a new one is added: >> -------- >> public SchemaUpdate(MetadataImplementor metadata) { >> this( metadata.getMetadataBuildingOptions().getServiceRegistry(), >> metadata ); >> } >> --------- >> >> Also the configuration.buildMappings() method has been deprecated. Where >> do >> I get the MetadataImplementor from? Also is there any changelog I can >> refer >> to? >> >> Thanks. >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >

Thanks Steve, I managed to migrate my configuration to the new MetamodelImplementor. Now when I run the scema export I get a lot of these warning: INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect WARN : JDBC Driver reports it stores quoted identifiers in both mixed and upper case WARN : HHH000072: Duplicate joins for class: com.xxx.platform.core.model.cms.AbstractPageModel WARN : HHH000072: Duplicate joins for class: com.xxx.platform.module.invoice.core.model.InvoicePageModel WARN : HHH000072: Duplicate joins for class: com.xxx.platform.core.model.batch.BatchStepExecutionContextModel WARN : HHH000072: Duplicate joins for class: com.xxx.platform.core.model.batch.BatchJobExecutionContextModel WARN : HHH000072: Duplicate joins for class: com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel WARN : HHH000072: Duplicate joins for class: com.xxx.platform.module.search.core.model.SearchPageRedirectModel WARN : HHH000072: Duplicate joins for class: com.xxx.platform.module.promotion.core.model.PromotionModel and when I run some test I get the following exception: java.lang.NoSuchMethodError: java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; at org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) at org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) at org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) at org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) at org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) at org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) at org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) at org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > I am told that the bug does not affect the JBoss->Central sync process. > So at some point the artifacts should all be available in Central > > On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> hibernate-core seems to be the only artifact that is available in JBoss >> Nexus. >> >> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> So apparently the artifacts / repo issue is a Nexus bug that is >>> effecting the JBoss repo (and therefore us)... >>> http://issues.sonatype.org/browse/NEXUS-7654 >>> >>> As I pointed out in the announcement, I am managing the "migration >>> guide" in source repo while I develop the Betas. See >>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>> As far are the new bootstrapping apis, see >>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>> and >>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>> >>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >>> wrote: >>> >>>> Hi guys, >>>> >>>> I just tried the latest beta and I cannot compile my project. With the >>>> latest hibernate 4.3.X I was able to do this: >>>> ------- >>>> final org.hibernate.cfg.Configuration configuration = >>>> getHibernateConfiguration(); >>>> configuration.buildMappings(); >>>> final SchemaUpdate schemaUpdate = new >>>> SchemaUpdate(configuration); >>>> ------- >>>> >>>> however it seems that the SchemaUpdate constructor has been removed >>>> and now >>>> a new one is added: >>>> -------- >>>> public SchemaUpdate(MetadataImplementor metadata) { >>>> this( >>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>> metadata ); >>>> } >>>> --------- >>>> >>>> Also the configuration.buildMappings() method has been deprecated. >>>> Where do >>>> I get the MetadataImplementor from? Also is there any changelog I can >>>> refer >>>> to? >>>> >>>> Thanks. >>>> -- >>>> Regards, Petar! >>>> Karlovo, Bulgaria. >>>> --- >>>> Public PGP Key at: >>>> >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> >> > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611

So then you also noticed that I replied to him :) Jean-Baptiste Nizet <https://hibernate.atlassian.net/secure/ViewProfile.jspa?name=jnizet> Awesome, thanks for trying it out! I have noticed that occasionally too wrt HHH000072, but have been so heads down trying to get ready for the 5.0.0 Beta release that I have not yet had time to look closer. I will get to it. On Tue, Mar 31, 2015 at 6:13 PM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; wrote: > BTW, > > I see here: https://hibernate.atlassian.net/browse/HHH-8844 that > Jean-Baptiste Nizet commented he also gets these "Duplicate joins for > class" warnings: > ----- > > - unrelated: I get a warning for **every** entity that I didn't get > with Hibernate 4, which is not very clear and seems like a false positive: > `WARN o.h.b.i.InFlightMetadataCollectorImpl - HHH000072: Duplicate joins > for class: ...`. Note that I get this warning even for entities that have > no association at all with any other entity. > > > ----- > > 2015-04-01 2:03 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com&gt;: > >> Thanks Steve, >> >> I managed to migrate my configuration to the new MetamodelImplementor. >> Now when I run the scema export I get a lot of these warning: >> >> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect >> WARN : JDBC Driver reports it stores quoted identifiers in both mixed >> and upper case >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.core.model.cms.AbstractPageModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.module.invoice.core.model.InvoicePageModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.module.promotion.core.model.PromotionModel >> >> and when I run some test I get the following exception: >> java.lang.NoSuchMethodError: >> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >> at >> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >> at >> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >> at >> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >> at >> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >> at >> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >> at >> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >> at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >> at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >> at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >> at >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >> at >> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >> at >> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >> >> >> >> >> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> I am told that the bug does not affect the JBoss->Central sync >>> process. So at some point the artifacts should all be available in Central >>> >>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> hibernate-core seems to be the only artifact that is available in >>>> JBoss Nexus. >>>> >>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> So apparently the artifacts / repo issue is a Nexus bug that is >>>>> effecting the JBoss repo (and therefore us)... >>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>> >>>>> As I pointed out in the announcement, I am managing the "migration >>>>> guide" in source repo while I develop the Betas. See >>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>> As far are the new bootstrapping apis, see >>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>> and >>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>> >>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>> >>>>>> Hi guys, >>>>>> >>>>>> I just tried the latest beta and I cannot compile my project. With >>>>>> the >>>>>> latest hibernate 4.3.X I was able to do this: >>>>>> ------- >>>>>> final org.hibernate.cfg.Configuration configuration = >>>>>> getHibernateConfiguration(); >>>>>> configuration.buildMappings(); >>>>>> final SchemaUpdate schemaUpdate = new >>>>>> SchemaUpdate(configuration); >>>>>> ------- >>>>>> >>>>>> however it seems that the SchemaUpdate constructor has been removed >>>>>> and now >>>>>> a new one is added: >>>>>> -------- >>>>>> public SchemaUpdate(MetadataImplementor metadata) { >>>>>> this( >>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>> metadata ); >>>>>> } >>>>>> --------- >>>>>> >>>>>> Also the configuration.buildMappings() method has been deprecated. >>>>>> Where do >>>>>> I get the MetadataImplementor from? Also is there any changelog I >>>>>> can refer >>>>>> to? >>>>>> >>>>>> Thanks. >>>>>> -- >>>>>> Regards, Petar! >>>>>> Karlovo, Bulgaria. >>>>>> --- >>>>>> Public PGP Key at: >>>>>> >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> > > > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >

What JRE are you trying to use? This error: java.lang.NoSuchMethodError: java.util.concurrent. ConcurrentHashMap.keySet()Ljava/util/concurrent/ ConcurrentHashMap$KeySetView; is indicative of an issue in cross-jre support due to a change internal to java classes. On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; wrote: > Thanks Steve, > > I managed to migrate my configuration to the new MetamodelImplementor. > Now when I run the scema export I get a lot of these warning: > > INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect > WARN : JDBC Driver reports it stores quoted identifiers in both mixed and > upper case > WARN : HHH000072: Duplicate joins for class: > com.xxx.platform.core.model.cms.AbstractPageModel > WARN : HHH000072: Duplicate joins for class: > com.xxx.platform.module.invoice.core.model.InvoicePageModel > WARN : HHH000072: Duplicate joins for class: > com.xxx.platform.core.model.batch.BatchStepExecutionContextModel > WARN : HHH000072: Duplicate joins for class: > com.xxx.platform.core.model.batch.BatchJobExecutionContextModel > WARN : HHH000072: Duplicate joins for class: > com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel > WARN : HHH000072: Duplicate joins for class: > com.xxx.platform.module.search.core.model.SearchPageRedirectModel > WARN : HHH000072: Duplicate joins for class: > com.xxx.platform.module.promotion.core.model.PromotionModel > > and when I run some test I get the following exception: > java.lang.NoSuchMethodError: > java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; > at > org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) > at > org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) > at > org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) > at > org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) > at > org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) > at > org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) > at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) > at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) > at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) > at > org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) > at > org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) > at > org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) > > > > > 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> I am told that the bug does not affect the JBoss->Central sync process. >> So at some point the artifacts should all be available in Central >> >> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> hibernate-core seems to be the only artifact that is available in JBoss >>> Nexus. >>> >>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> So apparently the artifacts / repo issue is a Nexus bug that is >>>> effecting the JBoss repo (and therefore us)... >>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>> >>>> As I pointed out in the announcement, I am managing the "migration >>>> guide" in source repo while I develop the Betas. See >>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>> As far are the new bootstrapping apis, see >>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>> and >>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>> >>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <paranoiabla(a)gmail.com >>>> > wrote: >>>> >>>>> Hi guys, >>>>> >>>>> I just tried the latest beta and I cannot compile my project. With the >>>>> latest hibernate 4.3.X I was able to do this: >>>>> ------- >>>>> final org.hibernate.cfg.Configuration configuration = >>>>> getHibernateConfiguration(); >>>>> configuration.buildMappings(); >>>>> final SchemaUpdate schemaUpdate = new >>>>> SchemaUpdate(configuration); >>>>> ------- >>>>> >>>>> however it seems that the SchemaUpdate constructor has been removed >>>>> and now >>>>> a new one is added: >>>>> -------- >>>>> public SchemaUpdate(MetadataImplementor metadata) { >>>>> this( >>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>> metadata ); >>>>> } >>>>> --------- >>>>> >>>>> Also the configuration.buildMappings() method has been deprecated. >>>>> Where do >>>>> I get the MetadataImplementor from? Also is there any changelog I can >>>>> refer >>>>> to? >>>>> >>>>> Thanks. >>>>> -- >>>>> Regards, Petar! >>>>> Karlovo, Bulgaria. >>>>> --- >>>>> Public PGP Key at: >>>>> >>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> >>>> >>> >> > > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >

petar@petar-ThinkPad-X1-Carbon:~$ java -version java version "1.7.0_71" Java(TM) SE Runtime Environment (build 1.7.0_71-b14) Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) petar@petar-ThinkPad-X1-Carbon:~$ uname -a Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu Mar 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux petar@petar-ThinkPad-X1-Carbon:~$ 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > What JRE are you trying to use? This error: > > java.lang.NoSuchMethodError: java.util.concurrent. > ConcurrentHashMap.keySet()Ljava/util/concurrent/ > ConcurrentHashMap$KeySetView; > > is indicative of an issue in cross-jre support due to a change internal > to java classes. > > > On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; > wrote: > >> Thanks Steve, >> >> I managed to migrate my configuration to the new MetamodelImplementor. >> Now when I run the scema export I get a lot of these warning: >> >> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect >> WARN : JDBC Driver reports it stores quoted identifiers in both mixed >> and upper case >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.core.model.cms.AbstractPageModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.module.invoice.core.model.InvoicePageModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.module.promotion.core.model.PromotionModel >> >> and when I run some test I get the following exception: >> java.lang.NoSuchMethodError: >> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >> at >> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >> at >> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >> at >> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >> at >> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >> at >> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >> at >> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >> at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >> at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >> at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >> at >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >> at >> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >> at >> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >> >> >> >> >> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> I am told that the bug does not affect the JBoss->Central sync >>> process. So at some point the artifacts should all be available in Central >>> >>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> hibernate-core seems to be the only artifact that is available in >>>> JBoss Nexus. >>>> >>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> So apparently the artifacts / repo issue is a Nexus bug that is >>>>> effecting the JBoss repo (and therefore us)... >>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>> >>>>> As I pointed out in the announcement, I am managing the "migration >>>>> guide" in source repo while I develop the Betas. See >>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>> As far are the new bootstrapping apis, see >>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>> and >>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>> >>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>> >>>>>> Hi guys, >>>>>> >>>>>> I just tried the latest beta and I cannot compile my project. With >>>>>> the >>>>>> latest hibernate 4.3.X I was able to do this: >>>>>> ------- >>>>>> final org.hibernate.cfg.Configuration configuration = >>>>>> getHibernateConfiguration(); >>>>>> configuration.buildMappings(); >>>>>> final SchemaUpdate schemaUpdate = new >>>>>> SchemaUpdate(configuration); >>>>>> ------- >>>>>> >>>>>> however it seems that the SchemaUpdate constructor has been removed >>>>>> and now >>>>>> a new one is added: >>>>>> -------- >>>>>> public SchemaUpdate(MetadataImplementor metadata) { >>>>>> this( >>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>> metadata ); >>>>>> } >>>>>> --------- >>>>>> >>>>>> Also the configuration.buildMappings() method has been deprecated. >>>>>> Where do >>>>>> I get the MetadataImplementor from? Also is there any changelog I >>>>>> can refer >>>>>> to? >>>>>> >>>>>> Thanks. >>>>>> -- >>>>>> Regards, Petar! >>>>>> Karlovo, Bulgaria. >>>>>> --- >>>>>> Public PGP Key at: >>>>>> >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> > > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611

Nope. It just effects any code compiled with Java 8 even though the change is internal. The problem is the generated bytecode incorporates this change. Like I said, this should be compiled with 1.6 compatibility, but that is apparently not working atm. I am having a struggle getting a mixed JDK build working "just right". On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; wrote: > According to this: > > https://gist.github.com/AlainODea/1375759b8720a3f9f094 > > Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> while > the 1.8*ConcurrentHashMap#keySet()* returns a > ConcurrentHashMap.KeySetView<K,V>`. > > I think you're using some Java8 API. > > > 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com&gt;: > >> petar@petar-ThinkPad-X1-Carbon:~$ java -version >> java version "1.7.0_71" >> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) >> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu Mar >> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> petar@petar-ThinkPad-X1-Carbon:~$ >> >> >> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> What JRE are you trying to use? This error: >>> >>> java.lang.NoSuchMethodError: java.util.concurrent. >>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>> ConcurrentHashMap$KeySetView; >>> >>> is indicative of an issue in cross-jre support due to a change internal >>> to java classes. >>> >>> >>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >>> wrote: >>> >>>> Thanks Steve, >>>> >>>> I managed to migrate my configuration to the new MetamodelImplementor. >>>> Now when I run the scema export I get a lot of these warning: >>>> >>>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect >>>> WARN : JDBC Driver reports it stores quoted identifiers in both mixed >>>> and upper case >>>> WARN : HHH000072: Duplicate joins for class: >>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>> WARN : HHH000072: Duplicate joins for class: >>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>> WARN : HHH000072: Duplicate joins for class: >>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>> WARN : HHH000072: Duplicate joins for class: >>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>> WARN : HHH000072: Duplicate joins for class: >>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>> WARN : HHH000072: Duplicate joins for class: >>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>> WARN : HHH000072: Duplicate joins for class: >>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>> >>>> and when I run some test I get the following exception: >>>> java.lang.NoSuchMethodError: >>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>> at >>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>> at >>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>> at >>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>> at >>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>> at >>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>> at >>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>> at >>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>> at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>> at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>> at >>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>> at >>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>> at >>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>> >>>> >>>> >>>> >>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> >>>>> I am told that the bug does not affect the JBoss->Central sync >>>>> process. So at some point the artifacts should all be available in Central >>>>> >>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> hibernate-core seems to be the only artifact that is available in >>>>>> JBoss Nexus. >>>>>> >>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve(a)hibernate.org >>>>>> > wrote: >>>>>> >>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is >>>>>>> effecting the JBoss repo (and therefore us)... >>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>>>> >>>>>>> As I pointed out in the announcement, I am managing the "migration >>>>>>> guide" in source repo while I develop the Betas. See >>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>>>> As far are the new bootstrapping apis, see >>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>>>> and >>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>>>> >>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> I just tried the latest beta and I cannot compile my project. With >>>>>>>> the >>>>>>>> latest hibernate 4.3.X I was able to do this: >>>>>>>> ------- >>>>>>>> final org.hibernate.cfg.Configuration configuration = >>>>>>>> getHibernateConfiguration(); >>>>>>>> configuration.buildMappings(); >>>>>>>> final SchemaUpdate schemaUpdate = new >>>>>>>> SchemaUpdate(configuration); >>>>>>>> ------- >>>>>>>> >>>>>>>> however it seems that the SchemaUpdate constructor has been >>>>>>>> removed and now >>>>>>>> a new one is added: >>>>>>>> -------- >>>>>>>> public SchemaUpdate(MetadataImplementor metadata) { >>>>>>>> this( >>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>>>> metadata ); >>>>>>>> } >>>>>>>> --------- >>>>>>>> >>>>>>>> Also the configuration.buildMappings() method has been deprecated. >>>>>>>> Where do >>>>>>>> I get the MetadataImplementor from? Also is there any changelog I >>>>>>>> can refer >>>>>>>> to? >>>>>>>> >>>>>>>> Thanks. >>>>>>>> -- >>>>>>>> Regards, Petar! >>>>>>>> Karlovo, Bulgaria. >>>>>>>> --- >>>>>>>> Public PGP Key at: >>>>>>>> >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>>>>> _______________________________________________ >>>>>>>> hibernate-dev mailing list >>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, Petar! >>>> Karlovo, Bulgaria. >>>> --- >>>> Public PGP Key at: >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>> >>> >>> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> > > > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >

Ahh, seems this may be an option to work around it: <quote> Using the general *Map* interface in place of the concrete *ConcurrentHashMap* type here side-steps the coupling to the Java 8 return type and will allow this code to be compiled with Java 8 and run on Java 7. </quote> I had missed that part. On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > When I say "internal" here, I mean internal to java classes. > > On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Nope. It just effects any code compiled with Java 8 even though the >> change is internal. The problem is the generated bytecode incorporates >> this change. Like I said, this should be compiled with 1.6 compatibility, >> but that is apparently not working atm. I am having a struggle getting a >> mixed JDK build working "just right". >> >> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >> wrote: >> >>> According to this: >>> >>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>> >>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> while >>> the 1.8*ConcurrentHashMap#keySet()* returns a >>> ConcurrentHashMap.KeySetView<K,V>`. >>> >>> I think you're using some Java8 API. >>> >>> >>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com&gt;: >>> >>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>> java version "1.7.0_71" >>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) >>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu >>>> Mar 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>> >>>> >>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> >>>>> What JRE are you trying to use? This error: >>>>> >>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>>> ConcurrentHashMap$KeySetView; >>>>> >>>>> is indicative of an issue in cross-jre support due to a change >>>>> internal to java classes. >>>>> >>>>> >>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>> >>>>>> Thanks Steve, >>>>>> >>>>>> I managed to migrate my configuration to the new >>>>>> MetamodelImplementor. Now when I run the scema export I get a lot of these >>>>>> warning: >>>>>> >>>>>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect >>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both >>>>>> mixed and upper case >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>>>> >>>>>> and when I run some test I get the following exception: >>>>>> java.lang.NoSuchMethodError: >>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>> at >>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>>>> at >>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>>>> at >>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>>>> at >>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>>>> at >>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>>>> at >>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>>>> at >>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>>>> at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>>>> at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>>>> at >>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>>>> at >>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>>>> at >>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>>> >>>>>>> I am told that the bug does not affect the JBoss->Central sync >>>>>>> process. So at some point the artifacts should all be available in Central >>>>>>> >>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>> >>>>>>>> hibernate-core seems to be the only artifact that is available in >>>>>>>> JBoss Nexus. >>>>>>>> >>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>> >>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is >>>>>>>>> effecting the JBoss repo (and therefore us)... >>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>>>>>> >>>>>>>>> As I pointed out in the announcement, I am managing the >>>>>>>>> "migration guide" in source repo while I develop the Betas. See >>>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>>>>>> As far are the new bootstrapping apis, see >>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>>>>>> and >>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>>>>>> >>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>>>> >>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>> I just tried the latest beta and I cannot compile my project. >>>>>>>>>> With the >>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>>>>>>>> ------- >>>>>>>>>> final org.hibernate.cfg.Configuration configuration = >>>>>>>>>> getHibernateConfiguration(); >>>>>>>>>> configuration.buildMappings(); >>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>>>>>>>> SchemaUpdate(configuration); >>>>>>>>>> ------- >>>>>>>>>> >>>>>>>>>> however it seems that the SchemaUpdate constructor has been >>>>>>>>>> removed and now >>>>>>>>>> a new one is added: >>>>>>>>>> -------- >>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) { >>>>>>>>>> this( >>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>>>>>> metadata ); >>>>>>>>>> } >>>>>>>>>> --------- >>>>>>>>>> >>>>>>>>>> Also the configuration.buildMappings() method has been >>>>>>>>>> deprecated. Where do >>>>>>>>>> I get the MetadataImplementor from? Also is there any changelog >>>>>>>>>> I can refer >>>>>>>>>> to? >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> -- >>>>>>>>>> Regards, Petar! >>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>> --- >>>>>>>>>> Public PGP Key at: >>>>>>>>>> >>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >>>>>>>>>> 0611 >>>>>>>>>> _______________________________________________ >>>>>>>>>> hibernate-dev mailing list >>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, Petar! >>>>>> Karlovo, Bulgaria. >>>>>> --- >>>>>> Public PGP Key at: >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, Petar! >>>> Karlovo, Bulgaria. >>>> --- >>>> Public PGP Key at: >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>> >>> >>> >>> >>> -- >>> Regards, Petar! >>> Karlovo, Bulgaria. >>> --- >>> Public PGP Key at: >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>> >> >> >

Ahh, seems this may be an option to work around it: <quote> Using the general *Map* interface in place of the concrete *ConcurrentHashMap* type here side-steps the coupling to the Java 8 return type and will allow this code to be compiled with Java 8 and run on Java 7. </quote> I had missed that part. On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > When I say "internal" here, I mean internal to java classes. > > On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Nope. It just effects any code compiled with Java 8 even though the >> change is internal. The problem is the generated bytecode incorporates >> this change. Like I said, this should be compiled with 1.6 compatibility, >> but that is apparently not working atm. I am having a struggle getting a >> mixed JDK build working "just right". >> >> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >> wrote: >> >>> According to this: >>> >>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>> >>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> while >>> the 1.8*ConcurrentHashMap#keySet()* returns a >>> ConcurrentHashMap.KeySetView<K,V>`. >>> >>> I think you're using some Java8 API. >>> >>> >>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com&gt;: >>> >>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>> java version "1.7.0_71" >>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) >>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu Mar >>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>> >>>> >>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> >>>>> What JRE are you trying to use? This error: >>>>> >>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>>> ConcurrentHashMap$KeySetView; >>>>> >>>>> is indicative of an issue in cross-jre support due to a change >>>>> internal to java classes. >>>>> >>>>> >>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla(a)gmail.com >>>>> > wrote: >>>>> >>>>>> Thanks Steve, >>>>>> >>>>>> I managed to migrate my configuration to the new >>>>>> MetamodelImplementor. Now when I run the scema export I get a lot of these >>>>>> warning: >>>>>> >>>>>> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect >>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both mixed >>>>>> and upper case >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>>>> >>>>>> and when I run some test I get the following exception: >>>>>> java.lang.NoSuchMethodError: >>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>> at >>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>>>> at >>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>>>> at >>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>>>> at >>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>>>> at >>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>>>> at >>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>>>> at >>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>>>> at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>>>> at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>>>> at >>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>>>> at >>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>>>> at >>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>>> >>>>>>> I am told that the bug does not affect the JBoss->Central sync >>>>>>> process. So at some point the artifacts should all be available in Central >>>>>>> >>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve(a)hibernate.org >>>>>>> > wrote: >>>>>>> >>>>>>>> hibernate-core seems to be the only artifact that is available in >>>>>>>> JBoss Nexus. >>>>>>>> >>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>> >>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is >>>>>>>>> effecting the JBoss repo (and therefore us)... >>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>>>>>> >>>>>>>>> As I pointed out in the announcement, I am managing the "migration >>>>>>>>> guide" in source repo while I develop the Betas. See >>>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>>>>>> As far are the new bootstrapping apis, see >>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>>>>>> and >>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>>>>>> >>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>>>> >>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>> I just tried the latest beta and I cannot compile my project. >>>>>>>>>> With the >>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>>>>>>>> ------- >>>>>>>>>> final org.hibernate.cfg.Configuration configuration = >>>>>>>>>> getHibernateConfiguration(); >>>>>>>>>> configuration.buildMappings(); >>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>>>>>>>> SchemaUpdate(configuration); >>>>>>>>>> ------- >>>>>>>>>> >>>>>>>>>> however it seems that the SchemaUpdate constructor has been >>>>>>>>>> removed and now >>>>>>>>>> a new one is added: >>>>>>>>>> -------- >>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) { >>>>>>>>>> this( >>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>>>>>> metadata ); >>>>>>>>>> } >>>>>>>>>> --------- >>>>>>>>>> >>>>>>>>>> Also the configuration.buildMappings() method has been >>>>>>>>>> deprecated. Where do >>>>>>>>>> I get the MetadataImplementor from? Also is there any changelog I >>>>>>>>>> can refer >>>>>>>>>> to? >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> -- >>>>>>>>>> Regards, Petar! >>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>> --- >>>>>>>>>> Public PGP Key at: >>>>>>>>>> >>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >>>>>>>>>> 0611 >>>>>>>>>> _______________________________________________ >>>>>>>>>> hibernate-dev mailing list >>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, Petar! >>>>>> Karlovo, Bulgaria. >>>>>> --- >>>>>> Public PGP Key at: >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, Petar! >>>> Karlovo, Bulgaria. >>>> --- >>>> Public PGP Key at: >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>> >>> >>> >>> >>> -- >>> Regards, Petar! >>> Karlovo, Bulgaria. >>> --- >>> Public PGP Key at: >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>> >> >> > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Well the idea is to run the Gradle process with Java 8 (the build itself is a Java process too don't forget). We pass in the older JDK specifically to be able to set the bootclasspath for compilation and the executable for running tests. That's the theory. Interestingly I developed a simplified project to test these theories: https://github.com/sebersole/gradle-mixed-jdk And of course this all works there. As you'd expect right? I think the JAXB thing comes into play here as well. Gradle does not have any XJC support built in, so we have to make use of its Ant support to run the XJC Ant tasks for JAXB model generation. The problem there is that, afaik, there is no way to tell Gradle's AntBuilder to use a JDK other than the one that launched Gradle. I think this is why we see a JAXB model defined for Java 7, rather than Java 6, because we essentially run XJC with Java 8. Anyway, this certainly makes the build more complex and we definitely have to think through all these scenarios. In fact after Beta1, one of my todos is to build up the build "from scratch" using that gradle-mixed-jdk project as a basis. In general the plan though is to run all the tests (other than hibernate-java8, obviously) with the "baseline JDK, whether that be Java 6 or 7. On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > There are many similar issues discussed on the Lucene developer's > mailing list, it's an interesting read: > - > http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... > > I see no alternative than to have those test jobs actually exercising > ORM with JDK6, or maybe even compile it all with JDK6 except the Java8 > additional module to be compiled with JDK8 ? > > > > On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > Ahh, seems this may be an option to work around it: > > > > <quote> > > Using the general *Map* interface in place of the concrete > > *ConcurrentHashMap* type here side-steps the coupling to the Java 8 > return > > type and will allow this code to be compiled with Java 8 and run on > Java 7. > > </quote> > > > > I had missed that part. > > > > > > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > > > >> When I say "internal" here, I mean internal to java classes. > >> > >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve(a)hibernate.org&gt; > >> wrote: > >> > >>> Nope. It just effects any code compiled with Java 8 even though the > >>> change is internal. The problem is the generated bytecode > incorporates > >>> this change. Like I said, this should be compiled with 1.6 > compatibility, > >>> but that is apparently not working atm. I am having a struggle > getting a > >>> mixed JDK build working "just right". > >>> > >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < > paranoiabla(a)gmail.com&gt; > >>> wrote: > >>> > >>>> According to this: > >>>> > >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 > >>>> > >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> > while > >>>> the 1.8*ConcurrentHashMap#keySet()* returns a > >>>> ConcurrentHashMap.KeySetView<K,V>`. > >>>> > >>>> I think you're using some Java8 API. > >>>> > >>>> > >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com&gt;: > >>>> > >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version > >>>>> java version "1.7.0_71" > >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) > >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) > >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a > >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu > Mar > >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > >>>>> petar@petar-ThinkPad-X1-Carbon:~$ > >>>>> > >>>>> > >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >>>>> > >>>>>> What JRE are you trying to use? This error: > >>>>>> > >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. > >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ > >>>>>> ConcurrentHashMap$KeySetView; > >>>>>> > >>>>>> is indicative of an issue in cross-jre support due to a change > >>>>>> internal to java classes. > >>>>>> > >>>>>> > >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < > paranoiabla(a)gmail.com > >>>>>> > wrote: > >>>>>> > >>>>>>> Thanks Steve, > >>>>>>> > >>>>>>> I managed to migrate my configuration to the new > >>>>>>> MetamodelImplementor. Now when I run the scema export I get a lot > of these > >>>>>>> warning: > >>>>>>> > >>>>>>> INFO : HHH000400: Using dialect: > org.hibernate.dialect.MySQL5Dialect > >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both > mixed > >>>>>>> and upper case > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> > com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel > >>>>>>> > >>>>>>> and when I run some test I get the following exception: > >>>>>>> java.lang.NoSuchMethodError: > >>>>>>> > java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; > >>>>>>> at > >>>>>>> > org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) > >>>>>>> at > >>>>>>> > org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) > >>>>>>> at > >>>>>>> > org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) > >>>>>>> at > >>>>>>> > org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) > >>>>>>> at > >>>>>>> > org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) > >>>>>>> at > >>>>>>> > org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) > >>>>>>> at > >>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) > >>>>>>> at > org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) > >>>>>>> at > org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) > >>>>>>> at > >>>>>>> > org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) > >>>>>>> at > >>>>>>> > org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) > >>>>>>> at > >>>>>>> > org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >>>>>>> > >>>>>>>> I am told that the bug does not affect the JBoss->Central sync > >>>>>>>> process. So at some point the artifacts should all be available > in Central > >>>>>>>> > >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < > steve(a)hibernate.org > >>>>>>>> > wrote: > >>>>>>>> > >>>>>>>>> hibernate-core seems to be the only artifact that is available > in > >>>>>>>>> JBoss Nexus. > >>>>>>>>> > >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < > >>>>>>>>> steve(a)hibernate.org&gt; wrote: > >>>>>>>>> > >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is > >>>>>>>>>> effecting the JBoss repo (and therefore us)... > >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 > >>>>>>>>>> > >>>>>>>>>> As I pointed out in the announcement, I am managing the > "migration > >>>>>>>>>> guide" in source repo while I develop the Betas. See > >>>>>>>>>> > https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... > >>>>>>>>>> As far are the new bootstrapping apis, see > >>>>>>>>>> > http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... > >>>>>>>>>> and > >>>>>>>>>> > http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... > >>>>>>>>>> > >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < > >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi guys, > >>>>>>>>>>> > >>>>>>>>>>> I just tried the latest beta and I cannot compile my project. > >>>>>>>>>>> With the > >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: > >>>>>>>>>>> ------- > >>>>>>>>>>> final org.hibernate.cfg.Configuration configuration = > >>>>>>>>>>> getHibernateConfiguration(); > >>>>>>>>>>> configuration.buildMappings(); > >>>>>>>>>>> final SchemaUpdate schemaUpdate = new > >>>>>>>>>>> SchemaUpdate(configuration); > >>>>>>>>>>> ------- > >>>>>>>>>>> > >>>>>>>>>>> however it seems that the SchemaUpdate constructor has been > >>>>>>>>>>> removed and now > >>>>>>>>>>> a new one is added: > >>>>>>>>>>> -------- > >>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) { > >>>>>>>>>>> this( > >>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), > >>>>>>>>>>> metadata ); > >>>>>>>>>>> } > >>>>>>>>>>> --------- > >>>>>>>>>>> > >>>>>>>>>>> Also the configuration.buildMappings() method has been > >>>>>>>>>>> deprecated. Where do > >>>>>>>>>>> I get the MetadataImplementor from? Also is there any > changelog I > >>>>>>>>>>> can refer > >>>>>>>>>>> to? > >>>>>>>>>>> > >>>>>>>>>>> Thanks. > >>>>>>>>>>> -- > >>>>>>>>>>> Regards, Petar! > >>>>>>>>>>> Karlovo, Bulgaria. > >>>>>>>>>>> --- > >>>>>>>>>>> Public PGP Key at: > >>>>>>>>>>> > >>>>>>>>>>> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 > >>>>>>>>>>> 0611 > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> hibernate-dev mailing list > >>>>>>>>>>> hibernate-dev(a)lists.jboss.org > >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Regards, Petar! > >>>>>>> Karlovo, Bulgaria. > >>>>>>> --- > >>>>>>> Public PGP Key at: > >>>>>>> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 > 0611 > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Regards, Petar! > >>>>> Karlovo, Bulgaria. > >>>>> --- > >>>>> Public PGP Key at: > >>>>> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Regards, Petar! > >>>> Karlovo, Bulgaria. > >>>> --- > >>>> Public PGP Key at: > >>>> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > >>>> > >>> > >>> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

Well the idea is to run the Gradle process with Java 8 (the build itself is a Java process too don't forget). We pass in the older JDK specifically to be able to set the bootclasspath for compilation and the executable for running tests. That's the theory. Interestingly I developed a simplified project to test these theories: https://github.com/sebersole/gradle-mixed-jdk And of course this all works there. As you'd expect right? I think the JAXB thing comes into play here as well. Gradle does not have any XJC support built in, so we have to make use of its Ant support to run the XJC Ant tasks for JAXB model generation. The problem there is that, afaik, there is no way to tell Gradle's AntBuilder to use a JDK other than the one that launched Gradle. I think this is why we see a JAXB model defined for Java 7, rather than Java 6, because we essentially run XJC with Java 8. Anyway, this certainly makes the build more complex and we definitely have to think through all these scenarios. In fact after Beta1, one of my todos is to build up the build "from scratch" using that gradle-mixed-jdk project as a basis. In general the plan though is to run all the tests (other than hibernate-java8, obviously) with the "baseline JDK, whether that be Java 6 or 7. On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > There are many similar issues discussed on the Lucene developer's > mailing list, it's an interesting read: > - > http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... > > I see no alternative than to have those test jobs actually exercising > ORM with JDK6, or maybe even compile it all with JDK6 except the Java8 > additional module to be compiled with JDK8 ? > > > > On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > Ahh, seems this may be an option to work around it: > > > > <quote> > > Using the general *Map* interface in place of the concrete > > *ConcurrentHashMap* type here side-steps the coupling to the Java 8 > return > > type and will allow this code to be compiled with Java 8 and run on > Java 7. > > </quote> > > > > I had missed that part. > > > > > > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > > > >> When I say "internal" here, I mean internal to java classes. > >> > >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <steve(a)hibernate.org&gt; > >> wrote: > >> > >>> Nope. It just effects any code compiled with Java 8 even though the > >>> change is internal. The problem is the generated bytecode > incorporates > >>> this change. Like I said, this should be compiled with 1.6 > compatibility, > >>> but that is apparently not working atm. I am having a struggle > getting a > >>> mixed JDK build working "just right". > >>> > >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < > paranoiabla(a)gmail.com&gt; > >>> wrote: > >>> > >>>> According to this: > >>>> > >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 > >>>> > >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> > while > >>>> the 1.8*ConcurrentHashMap#keySet()* returns a > >>>> ConcurrentHashMap.KeySetView<K,V>`. > >>>> > >>>> I think you're using some Java8 API. > >>>> > >>>> > >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com&gt;: > >>>> > >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version > >>>>> java version "1.7.0_71" > >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) > >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) > >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a > >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu > Mar > >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > >>>>> petar@petar-ThinkPad-X1-Carbon:~$ > >>>>> > >>>>> > >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >>>>> > >>>>>> What JRE are you trying to use? This error: > >>>>>> > >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. > >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ > >>>>>> ConcurrentHashMap$KeySetView; > >>>>>> > >>>>>> is indicative of an issue in cross-jre support due to a change > >>>>>> internal to java classes. > >>>>>> > >>>>>> > >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < > paranoiabla(a)gmail.com > >>>>>> > wrote: > >>>>>> > >>>>>>> Thanks Steve, > >>>>>>> > >>>>>>> I managed to migrate my configuration to the new > >>>>>>> MetamodelImplementor. Now when I run the scema export I get a lot > of these > >>>>>>> warning: > >>>>>>> > >>>>>>> INFO : HHH000400: Using dialect: > org.hibernate.dialect.MySQL5Dialect > >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both > mixed > >>>>>>> and upper case > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> > com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel > >>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel > >>>>>>> > >>>>>>> and when I run some test I get the following exception: > >>>>>>> java.lang.NoSuchMethodError: > >>>>>>> > java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; > >>>>>>> at > >>>>>>> > org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) > >>>>>>> at > >>>>>>> > org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) > >>>>>>> at > >>>>>>> > org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) > >>>>>>> at > >>>>>>> > org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) > >>>>>>> at > >>>>>>> > org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) > >>>>>>> at > >>>>>>> > org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) > >>>>>>> at > >>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) > >>>>>>> at > org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) > >>>>>>> at > org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) > >>>>>>> at > >>>>>>> > org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) > >>>>>>> at > >>>>>>> > org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) > >>>>>>> at > >>>>>>> > org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >>>>>>> > >>>>>>>> I am told that the bug does not affect the JBoss->Central sync > >>>>>>>> process. So at some point the artifacts should all be available > in Central > >>>>>>>> > >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < > steve(a)hibernate.org > >>>>>>>> > wrote: > >>>>>>>> > >>>>>>>>> hibernate-core seems to be the only artifact that is available > in > >>>>>>>>> JBoss Nexus. > >>>>>>>>> > >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < > >>>>>>>>> steve(a)hibernate.org&gt; wrote: > >>>>>>>>> > >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that is > >>>>>>>>>> effecting the JBoss repo (and therefore us)... > >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 > >>>>>>>>>> > >>>>>>>>>> As I pointed out in the announcement, I am managing the > "migration > >>>>>>>>>> guide" in source repo while I develop the Betas. See > >>>>>>>>>> > https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... > >>>>>>>>>> As far are the new bootstrapping apis, see > >>>>>>>>>> > http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... > >>>>>>>>>> and > >>>>>>>>>> > http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... > >>>>>>>>>> > >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < > >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi guys, > >>>>>>>>>>> > >>>>>>>>>>> I just tried the latest beta and I cannot compile my project. > >>>>>>>>>>> With the > >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: > >>>>>>>>>>> ------- > >>>>>>>>>>> final org.hibernate.cfg.Configuration configuration = > >>>>>>>>>>> getHibernateConfiguration(); > >>>>>>>>>>> configuration.buildMappings(); > >>>>>>>>>>> final SchemaUpdate schemaUpdate = new > >>>>>>>>>>> SchemaUpdate(configuration); > >>>>>>>>>>> ------- > >>>>>>>>>>> > >>>>>>>>>>> however it seems that the SchemaUpdate constructor has been > >>>>>>>>>>> removed and now > >>>>>>>>>>> a new one is added: > >>>>>>>>>>> -------- > >>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) { > >>>>>>>>>>> this( > >>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), > >>>>>>>>>>> metadata ); > >>>>>>>>>>> } > >>>>>>>>>>> --------- > >>>>>>>>>>> > >>>>>>>>>>> Also the configuration.buildMappings() method has been > >>>>>>>>>>> deprecated. Where do > >>>>>>>>>>> I get the MetadataImplementor from? Also is there any > changelog I > >>>>>>>>>>> can refer > >>>>>>>>>>> to? > >>>>>>>>>>> > >>>>>>>>>>> Thanks. > >>>>>>>>>>> -- > >>>>>>>>>>> Regards, Petar! > >>>>>>>>>>> Karlovo, Bulgaria. > >>>>>>>>>>> --- > >>>>>>>>>>> Public PGP Key at: > >>>>>>>>>>> > >>>>>>>>>>> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 > >>>>>>>>>>> 0611 > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> hibernate-dev mailing list > >>>>>>>>>>> hibernate-dev(a)lists.jboss.org > >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Regards, Petar! > >>>>>>> Karlovo, Bulgaria. > >>>>>>> --- > >>>>>>> Public PGP Key at: > >>>>>>> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 > 0611 > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Regards, Petar! > >>>>> Karlovo, Bulgaria. > >>>>> --- > >>>>> Public PGP Key at: > >>>>> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Regards, Petar! > >>>> Karlovo, Bulgaria. > >>>> --- > >>>> Public PGP Key at: > >>>> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > >>>> > >>> > >>> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

Currently, AnimalSniffer is in place to prevent this very category of

Currently, AnimalSniffer is in place to prevent this very category of

Increase your Gradle-fu we must young apprentice :) AnimalSniffer is still run. I simply converted it to be a plugin. Check out org.hibernate.build.animalsniffer.AnimalSnifferPlugin in ORM's /buildSrc project AnimalSniffer will apparently not detect this :) On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > > Currently, AnimalSniffer is in place to prevent this very category of > error and I'm wondering why it didn't detect the "usage" of KeySetView. > > Looked at this a bit closer. Turns out, AnimalSniffer *will* detect this > issue if it actually is run. The problem is that AS apparently is not > executed by default anymore, due to the recent change to how AS is used [1]. > > Prior to that change, running AS was done automatically after the compileJava > task and would have reported that usage of KeySetView: > > Undefined reference: > java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; > in > [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class > > Unfortunately my Gradle Foo is rather limited, so I'm not sure how to > re-establish that behaviour with the new AS plug-in. > > --Gunnar > > [1] > https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb6... > > > > > 2015-04-01 9:39 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: > >> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> Just to clarify... I *think* that as long as we run the build with >>> Java 8 >>> and set the bootclasspath to 6 or 7 we should be fine. >>> >> >> Yes, setting the boot classpath to 6 (or 7) makes sure you only use >> classes present in that JDK (be it explicitly or implicitly as in the >> ConcurrentHashMap case), because it's that class library which will be used >> for compilation then. It is cumbersome to use though as you need to specify >> the location of a 6 or 7 JDK which makes the build less easily portable >> between machines. >> >> Currently, AnimalSniffer is in place to prevent this very category of >> error and I'm wondering why it didn't detect the "usage" of KeySetView. It >> really should have detected it, assuming it analyses the byte code of >> classes. But this makes me wonder now whether it only analyses the source >> code actually. Then it wouldn't be usable to prevent this sort of issue. >> >> Coding against the ConcurrentMap interface is the best way to avoid the >> issue. But of course there is no guarantee that it happens again, unless >> e.g. having a build on CI which uses 6 or 7 on its boot classpath. >> >> >>> On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>> > Well the idea is to run the Gradle process with Java 8 (the build >>> itself >>> > is a Java process too don't forget). We pass in the older JDK >>> specifically >>> > to be able to set the bootclasspath for compilation and the >>> executable for >>> > running tests. That's the theory. >>> > >>> > Interestingly I developed a simplified project to test these theories: >>> > https://github.com/sebersole/gradle-mixed-jdk And of course this all >>> > works there. As you'd expect right? >>> > >>> > I think the JAXB thing comes into play here as well. Gradle does not >>> have >>> > any XJC support built in, so we have to make use of its Ant support >>> to run >>> > the XJC Ant tasks for JAXB model generation. The problem there is >>> that, >>> > afaik, there is no way to tell Gradle's AntBuilder to use a JDK other >>> than >>> > the one that launched Gradle. I think this is why we see a JAXB model >>> > defined for Java 7, rather than Java 6, because we essentially run >>> XJC with >>> > Java 8. >>> > >>> > Anyway, this certainly makes the build more complex and we definitely >>> have >>> > to think through all these scenarios. In fact after Beta1, one of my >>> todos >>> > is to build up the build "from scratch" using that gradle-mixed-jdk >>> project >>> > as a basis. >>> > >>> > In general the plan though is to run all the tests (other than >>> > hibernate-java8, obviously) with the "baseline JDK, whether that be >>> Java 6 >>> > or 7. >>> > >>> > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero <sanne(a)hibernate.org >>> > >>> > wrote: >>> > >>> >> There are many similar issues discussed on the Lucene developer's >>> >> mailing list, it's an interesting read: >>> >> - >>> >> >>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>> >> >>> >> I see no alternative than to have those test jobs actually exercising >>> >> ORM with JDK6, or maybe even compile it all with JDK6 except the >>> Java8 >>> >> additional module to be compiled with JDK8 ? >>> >> >>> >> >>> >> >>> >> On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >> > Ahh, seems this may be an option to work around it: >>> >> > >>> >> > <quote> >>> >> > Using the general *Map* interface in place of the concrete >>> >> > *ConcurrentHashMap* type here side-steps the coupling to the Java 8 >>> >> return >>> >> > type and will allow this code to be compiled with Java 8 and run on >>> >> Java 7. >>> >> > </quote> >>> >> > >>> >> > I had missed that part. >>> >> > >>> >> > >>> >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>> steve(a)hibernate.org&gt; >>> >> wrote: >>> >> > >>> >> >> When I say "internal" here, I mean internal to java classes. >>> >> >> >>> >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>> steve(a)hibernate.org&gt; >>> >> >> wrote: >>> >> >> >>> >> >>> Nope. It just effects any code compiled with Java 8 even though >>> the >>> >> >>> change is internal. The problem is the generated bytecode >>> >> incorporates >>> >> >>> this change. Like I said, this should be compiled with 1.6 >>> >> compatibility, >>> >> >>> but that is apparently not working atm. I am having a struggle >>> >> getting a >>> >> >>> mixed JDK build working "just right". >>> >> >>> >>> >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>> >> paranoiabla(a)gmail.com&gt; >>> >> >>> wrote: >>> >> >>> >>> >> >>>> According to this: >>> >> >>>> >>> >> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>> >> >>>> >>> >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a >>> Set<K> >>> >> while >>> >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>> >> >>>> ConcurrentHashMap.KeySetView<K,V>`. >>> >> >>>> >>> >> >>>> I think you're using some Java8 API. >>> >> >>>> >>> >> >>>> >>> >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com >>> >: >>> >> >>>> >>> >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>> >> >>>>> java version "1.7.0_71" >>> >> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>> >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) >>> >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>> >> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu >>> SMP Thu >>> >> Mar >>> >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>> >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>> >> >>>>> >>> >> >>>>> >>> >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve(a)hibernate.org >>> >: >>> >> >>>>> >>> >> >>>>>> What JRE are you trying to use? This error: >>> >> >>>>>> >>> >> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>> >> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>> >> >>>>>> ConcurrentHashMap$KeySetView; >>> >> >>>>>> >>> >> >>>>>> is indicative of an issue in cross-jre support due to a change >>> >> >>>>>> internal to java classes. >>> >> >>>>>> >>> >> >>>>>> >>> >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>> >> paranoiabla(a)gmail.com >>> >> >>>>>> > wrote: >>> >> >>>>>> >>> >> >>>>>>> Thanks Steve, >>> >> >>>>>>> >>> >> >>>>>>> I managed to migrate my configuration to the new >>> >> >>>>>>> MetamodelImplementor. Now when I run the scema export I get >>> a lot >>> >> of these >>> >> >>>>>>> warning: >>> >> >>>>>>> >>> >> >>>>>>> INFO : HHH000400: Using dialect: >>> >> org.hibernate.dialect.MySQL5Dialect >>> >> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in >>> both >>> >> mixed >>> >> >>>>>>> and upper case >>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >> >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >> >>>>>>> >>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >> >>>>>>> >>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >> >>>>>>> >>> >> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >> >>>>>>> >>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >> >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>> >> >>>>>>> >>> >> >>>>>>> and when I run some test I get the following exception: >>> >> >>>>>>> java.lang.NoSuchMethodError: >>> >> >>>>>>> >>> >> >>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>> >> >>>>>>> at >>> >> >>>>>>> >>> >> >>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>> >> >>>>>>> at >>> >> >>>>>>> >>> >> >>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>> >> >>>>>>> at >>> >> >>>>>>> >>> >> >>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>> >> >>>>>>> at >>> >> >>>>>>> >>> >> >>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>> >> >>>>>>> at >>> >> >>>>>>> >>> >> >>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>> >> >>>>>>> at >>> >> >>>>>>> >>> >> >>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>> >> >>>>>>> at >>> >> >>>>>>> >>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>> >> >>>>>>> at >>> >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>> >> >>>>>>> at >>> >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>> >> >>>>>>> at >>> >> >>>>>>> >>> >> >>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>> >> >>>>>>> at >>> >> >>>>>>> >>> >> >>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>> >> >>>>>>> at >>> >> >>>>>>> >>> >> >>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>> >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>> steve(a)hibernate.org&gt;: >>> >> >>>>>>> >>> >> >>>>>>>> I am told that the bug does not affect the JBoss->Central >>> sync >>> >> >>>>>>>> process. So at some point the artifacts should all be >>> available >>> >> in Central >>> >> >>>>>>>> >>> >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>> >> steve(a)hibernate.org >>> >> >>>>>>>> > wrote: >>> >> >>>>>>>> >>> >> >>>>>>>>> hibernate-core seems to be the only artifact that is >>> available >>> >> in >>> >> >>>>>>>>> JBoss Nexus. >>> >> >>>>>>>>> >>> >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>> >> >>>>>>>>> steve(a)hibernate.org&gt; wrote: >>> >> >>>>>>>>> >>> >> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug >>> that is >>> >> >>>>>>>>>> effecting the JBoss repo (and therefore us)... >>> >> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>> >> >>>>>>>>>> >>> >> >>>>>>>>>> As I pointed out in the announcement, I am managing the >>> >> "migration >>> >> >>>>>>>>>> guide" in source repo while I develop the Betas. See >>> >> >>>>>>>>>> >>> >> >>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>> >> >>>>>>>>>> As far are the new bootstrapping apis, see >>> >> >>>>>>>>>> >>> >> >>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>> >> >>>>>>>>>> and >>> >> >>>>>>>>>> >>> >> >>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>> >> >>>>>>>>>> >>> >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>> >> >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>> >> >>>>>>>>>> >>> >> >>>>>>>>>>> Hi guys, >>> >> >>>>>>>>>>> >>> >> >>>>>>>>>>> I just tried the latest beta and I cannot compile my >>> project. >>> >> >>>>>>>>>>> With the >>> >> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>> >> >>>>>>>>>>> ------- >>> >> >>>>>>>>>>> final org.hibernate.cfg.Configuration >>> configuration = >>> >> >>>>>>>>>>> getHibernateConfiguration(); >>> >> >>>>>>>>>>> configuration.buildMappings(); >>> >> >>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>> >> >>>>>>>>>>> SchemaUpdate(configuration); >>> >> >>>>>>>>>>> ------- >>> >> >>>>>>>>>>> >>> >> >>>>>>>>>>> however it seems that the SchemaUpdate constructor has >>> been >>> >> >>>>>>>>>>> removed and now >>> >> >>>>>>>>>>> a new one is added: >>> >> >>>>>>>>>>> -------- >>> >> >>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) { >>> >> >>>>>>>>>>> this( >>> >> >>>>>>>>>>> >>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>> >> >>>>>>>>>>> metadata ); >>> >> >>>>>>>>>>> } >>> >> >>>>>>>>>>> --------- >>> >> >>>>>>>>>>> >>> >> >>>>>>>>>>> Also the configuration.buildMappings() method has been >>> >> >>>>>>>>>>> deprecated. Where do >>> >> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any >>> >> changelog I >>> >> >>>>>>>>>>> can refer >>> >> >>>>>>>>>>> to? >>> >> >>>>>>>>>>> >>> >> >>>>>>>>>>> Thanks. >>> >> >>>>>>>>>>> -- >>> >> >>>>>>>>>>> Regards, Petar! >>> >> >>>>>>>>>>> Karlovo, Bulgaria. >>> >> >>>>>>>>>>> --- >>> >> >>>>>>>>>>> Public PGP Key at: >>> >> >>>>>>>>>>> >>> >> >>>>>>>>>>> >>> >> >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> >> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>> 8550 C311 >>> >> >>>>>>>>>>> 0611 >>> >> >>>>>>>>>>> _______________________________________________ >>> >> >>>>>>>>>>> hibernate-dev mailing list >>> >> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>> >> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >>>>>>>>>>> >>> >> >>>>>>>>>> >>> >> >>>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> -- >>> >> >>>>>>> Regards, Petar! >>> >> >>>>>>> Karlovo, Bulgaria. >>> >> >>>>>>> --- >>> >> >>>>>>> Public PGP Key at: >>> >> >>>>>>> >>> >> >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>> C311 >>> >> 0611 >>> >> >>>>>>> >>> >> >>>>>> >>> >> >>>>>> >>> >> >>>>> >>> >> >>>>> >>> >> >>>>> -- >>> >> >>>>> Regards, Petar! >>> >> >>>>> Karlovo, Bulgaria. >>> >> >>>>> --- >>> >> >>>>> Public PGP Key at: >>> >> >>>>> >>> >> >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >>> 0611 >>> >> >>>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> -- >>> >> >>>> Regards, Petar! >>> >> >>>> Karlovo, Bulgaria. >>> >> >>>> --- >>> >> >>>> Public PGP Key at: >>> >> >>>> >>> >> >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >>> 0611 >>> >> >>>> >>> >> >>> >>> >> >>> >>> >> >> >>> >> > _______________________________________________ >>> >> > hibernate-dev mailing list >>> >> > hibernate-dev(a)lists.jboss.org >>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >>> > >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> >

Gunnar, it is applied. Add something that is java 8 specific and see... On Apr 1, 2015 7:59 AM, "Gunnar Morling" <gunnar(a)hibernate.org&gt; wrote: > I saw the plug-in, Steve. But how/when is it executed? > > Running "./gradlew build" used to execute AnimalSniffer and would have > revealed that accidental usage of KeySetView. That's not the case anymore. > It would be nice if that new plug-in could be applied automatically after > compileJava as it used to be the case with the Ant-based approach. > > > 2015-04-01 13:48 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> Increase your Gradle-fu we must young apprentice :) >> >> AnimalSniffer is still run. I simply converted it to be a plugin. >> Check out org.hibernate.build.animalsniffer.AnimalSnifferPlugin in ORM's >> /buildSrc project >> >> AnimalSniffer will apparently not detect this :) >> >> On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; >> wrote: >> >>> > Currently, AnimalSniffer is in place to prevent this very category >>> of error and I'm wondering why it didn't detect the "usage" of KeySetView. >>> >>> Looked at this a bit closer. Turns out, AnimalSniffer *will* detect >>> this issue if it actually is run. The problem is that AS apparently is >>> not executed by default anymore, due to the recent change to how AS is used >>> [1]. >>> >>> Prior to that change, running AS was done automatically after the compileJava >>> task and would have reported that usage of KeySetView: >>> >>> Undefined reference: >>> java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>> in >>> [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class >>> >>> Unfortunately my Gradle Foo is rather limited, so I'm not sure how to >>> re-establish that behaviour with the new AS plug-in. >>> >>> --Gunnar >>> >>> [1] >>> https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb6... >>> >>> >>> >>> >>> 2015-04-01 9:39 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: >>> >>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> >>>>> Just to clarify... I *think* that as long as we run the build with >>>>> Java 8 >>>>> and set the bootclasspath to 6 or 7 we should be fine. >>>>> >>>> >>>> Yes, setting the boot classpath to 6 (or 7) makes sure you only use >>>> classes present in that JDK (be it explicitly or implicitly as in the >>>> ConcurrentHashMap case), because it's that class library which will be used >>>> for compilation then. It is cumbersome to use though as you need to specify >>>> the location of a 6 or 7 JDK which makes the build less easily portable >>>> between machines. >>>> >>>> Currently, AnimalSniffer is in place to prevent this very category of >>>> error and I'm wondering why it didn't detect the "usage" of KeySetView. It >>>> really should have detected it, assuming it analyses the byte code of >>>> classes. But this makes me wonder now whether it only analyses the source >>>> code actually. Then it wouldn't be usable to prevent this sort of issue. >>>> >>>> Coding against the ConcurrentMap interface is the best way to avoid >>>> the issue. But of course there is no guarantee that it happens again, >>>> unless e.g. having a build on CI which uses 6 or 7 on its boot classpath. >>>> >>>> >>>>> On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>> > Well the idea is to run the Gradle process with Java 8 (the build >>>>> itself >>>>> > is a Java process too don't forget). We pass in the older JDK >>>>> specifically >>>>> > to be able to set the bootclasspath for compilation and the >>>>> executable for >>>>> > running tests. That's the theory. >>>>> > >>>>> > Interestingly I developed a simplified project to test these >>>>> theories: >>>>> > https://github.com/sebersole/gradle-mixed-jdk And of course this >>>>> all >>>>> > works there. As you'd expect right? >>>>> > >>>>> > I think the JAXB thing comes into play here as well. Gradle does >>>>> not have >>>>> > any XJC support built in, so we have to make use of its Ant support >>>>> to run >>>>> > the XJC Ant tasks for JAXB model generation. The problem there is >>>>> that, >>>>> > afaik, there is no way to tell Gradle's AntBuilder to use a JDK >>>>> other than >>>>> > the one that launched Gradle. I think this is why we see a JAXB >>>>> model >>>>> > defined for Java 7, rather than Java 6, because we essentially run >>>>> XJC with >>>>> > Java 8. >>>>> > >>>>> > Anyway, this certainly makes the build more complex and we >>>>> definitely have >>>>> > to think through all these scenarios. In fact after Beta1, one of >>>>> my todos >>>>> > is to build up the build "from scratch" using that gradle-mixed-jdk >>>>> project >>>>> > as a basis. >>>>> > >>>>> > In general the plan though is to run all the tests (other than >>>>> > hibernate-java8, obviously) with the "baseline JDK, whether that be >>>>> Java 6 >>>>> > or 7. >>>>> > >>>>> > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>>> sanne(a)hibernate.org&gt; >>>>> > wrote: >>>>> > >>>>> >> There are many similar issues discussed on the Lucene developer's >>>>> >> mailing list, it's an interesting read: >>>>> >> - >>>>> >> >>>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>>> >> >>>>> >> I see no alternative than to have those test jobs actually >>>>> exercising >>>>> >> ORM with JDK6, or maybe even compile it all with JDK6 except the >>>>> Java8 >>>>> >> additional module to be compiled with JDK8 ? >>>>> >> >>>>> >> >>>>> >> >>>>> >> On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >> > Ahh, seems this may be an option to work around it: >>>>> >> > >>>>> >> > <quote> >>>>> >> > Using the general *Map* interface in place of the concrete >>>>> >> > *ConcurrentHashMap* type here side-steps the coupling to the >>>>> Java 8 >>>>> >> return >>>>> >> > type and will allow this code to be compiled with Java 8 and run >>>>> on >>>>> >> Java 7. >>>>> >> > </quote> >>>>> >> > >>>>> >> > I had missed that part. >>>>> >> > >>>>> >> > >>>>> >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>>> steve(a)hibernate.org&gt; >>>>> >> wrote: >>>>> >> > >>>>> >> >> When I say "internal" here, I mean internal to java classes. >>>>> >> >> >>>>> >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>>> steve(a)hibernate.org&gt; >>>>> >> >> wrote: >>>>> >> >> >>>>> >> >>> Nope. It just effects any code compiled with Java 8 even >>>>> though the >>>>> >> >>> change is internal. The problem is the generated bytecode >>>>> >> incorporates >>>>> >> >>> this change. Like I said, this should be compiled with 1.6 >>>>> >> compatibility, >>>>> >> >>> but that is apparently not working atm. I am having a struggle >>>>> >> getting a >>>>> >> >>> mixed JDK build working "just right". >>>>> >> >>> >>>>> >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>>> >> paranoiabla(a)gmail.com&gt; >>>>> >> >>> wrote: >>>>> >> >>> >>>>> >> >>>> According to this: >>>>> >> >>>> >>>>> >> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>>> >> >>>> >>>>> >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a >>>>> Set<K> >>>>> >> while >>>>> >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>>> >> >>>> ConcurrentHashMap.KeySetView<K,V>`. >>>>> >> >>>> >>>>> >> >>>> I think you're using some Java8 API. >>>>> >> >>>> >>>>> >> >>>> >>>>> >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>>> paranoiabla(a)gmail.com&gt;: >>>>> >> >>>> >>>>> >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>>> >> >>>>> java version "1.7.0_71" >>>>> >> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>>> >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed >>>>> mode) >>>>> >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>>> >> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu >>>>> SMP Thu >>>>> >> Mar >>>>> >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>> >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>>> steve(a)hibernate.org&gt;: >>>>> >> >>>>> >>>>> >> >>>>>> What JRE are you trying to use? This error: >>>>> >> >>>>>> >>>>> >> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>>> >> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>>> >> >>>>>> ConcurrentHashMap$KeySetView; >>>>> >> >>>>>> >>>>> >> >>>>>> is indicative of an issue in cross-jre support due to a >>>>> change >>>>> >> >>>>>> internal to java classes. >>>>> >> >>>>>> >>>>> >> >>>>>> >>>>> >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>>> >> paranoiabla(a)gmail.com >>>>> >> >>>>>> > wrote: >>>>> >> >>>>>> >>>>> >> >>>>>>> Thanks Steve, >>>>> >> >>>>>>> >>>>> >> >>>>>>> I managed to migrate my configuration to the new >>>>> >> >>>>>>> MetamodelImplementor. Now when I run the scema export I >>>>> get a lot >>>>> >> of these >>>>> >> >>>>>>> warning: >>>>> >> >>>>>>> >>>>> >> >>>>>>> INFO : HHH000400: Using dialect: >>>>> >> org.hibernate.dialect.MySQL5Dialect >>>>> >> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in >>>>> both >>>>> >> mixed >>>>> >> >>>>>>> and upper case >>>>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>> >> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>> >> >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>> >> >>>>>>> >>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>> >> >>>>>>> >>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>> >> >>>>>>> >>>>> >> >>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>> >> >>>>>>> >>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>> >> >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>>> >> >>>>>>> >>>>> >> >>>>>>> and when I run some test I get the following exception: >>>>> >> >>>>>>> java.lang.NoSuchMethodError: >>>>> >> >>>>>>> >>>>> >> >>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>> >> >>>>>>> at >>>>> >> >>>>>>> >>>>> >> >>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>>> >> >>>>>>> at >>>>> >> >>>>>>> >>>>> >> >>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>>> >> >>>>>>> at >>>>> >> >>>>>>> >>>>> >> >>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>>> >> >>>>>>> at >>>>> >> >>>>>>> >>>>> >> >>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>>> >> >>>>>>> at >>>>> >> >>>>>>> >>>>> >> >>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>>> >> >>>>>>> at >>>>> >> >>>>>>> >>>>> >> >>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>>> >> >>>>>>> at >>>>> >> >>>>>>> >>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>>> >> >>>>>>> at >>>>> >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>>> >> >>>>>>> at >>>>> >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>>> >> >>>>>>> at >>>>> >> >>>>>>> >>>>> >> >>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>>> >> >>>>>>> at >>>>> >> >>>>>>> >>>>> >> >>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>>> >> >>>>>>> at >>>>> >> >>>>>>> >>>>> >> >>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>>> >> >>>>>>> >>>>> >> >>>>>>> >>>>> >> >>>>>>> >>>>> >> >>>>>>> >>>>> >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>>> steve(a)hibernate.org&gt;: >>>>> >> >>>>>>> >>>>> >> >>>>>>>> I am told that the bug does not affect the JBoss->Central >>>>> sync >>>>> >> >>>>>>>> process. So at some point the artifacts should all be >>>>> available >>>>> >> in Central >>>>> >> >>>>>>>> >>>>> >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>>>> >> steve(a)hibernate.org >>>>> >> >>>>>>>> > wrote: >>>>> >> >>>>>>>> >>>>> >> >>>>>>>>> hibernate-core seems to be the only artifact that is >>>>> available >>>>> >> in >>>>> >> >>>>>>>>> JBoss Nexus. >>>>> >> >>>>>>>>> >>>>> >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>>> >> >>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>> >> >>>>>>>>> >>>>> >> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug >>>>> that is >>>>> >> >>>>>>>>>> effecting the JBoss repo (and therefore us)... >>>>> >> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>> >> >>>>>>>>>> >>>>> >> >>>>>>>>>> As I pointed out in the announcement, I am managing the >>>>> >> "migration >>>>> >> >>>>>>>>>> guide" in source repo while I develop the Betas. See >>>>> >> >>>>>>>>>> >>>>> >> >>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>> >> >>>>>>>>>> As far are the new bootstrapping apis, see >>>>> >> >>>>>>>>>> >>>>> >> >>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>> >> >>>>>>>>>> and >>>>> >> >>>>>>>>>> >>>>> >> >>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>> >> >>>>>>>>>> >>>>> >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>>> >> >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>> >> >>>>>>>>>> >>>>> >> >>>>>>>>>>> Hi guys, >>>>> >> >>>>>>>>>>> >>>>> >> >>>>>>>>>>> I just tried the latest beta and I cannot compile my >>>>> project. >>>>> >> >>>>>>>>>>> With the >>>>> >> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>>> >> >>>>>>>>>>> ------- >>>>> >> >>>>>>>>>>> final org.hibernate.cfg.Configuration >>>>> configuration = >>>>> >> >>>>>>>>>>> getHibernateConfiguration(); >>>>> >> >>>>>>>>>>> configuration.buildMappings(); >>>>> >> >>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>>> >> >>>>>>>>>>> SchemaUpdate(configuration); >>>>> >> >>>>>>>>>>> ------- >>>>> >> >>>>>>>>>>> >>>>> >> >>>>>>>>>>> however it seems that the SchemaUpdate constructor has >>>>> been >>>>> >> >>>>>>>>>>> removed and now >>>>> >> >>>>>>>>>>> a new one is added: >>>>> >> >>>>>>>>>>> -------- >>>>> >> >>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) { >>>>> >> >>>>>>>>>>> this( >>>>> >> >>>>>>>>>>> >>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>> >> >>>>>>>>>>> metadata ); >>>>> >> >>>>>>>>>>> } >>>>> >> >>>>>>>>>>> --------- >>>>> >> >>>>>>>>>>> >>>>> >> >>>>>>>>>>> Also the configuration.buildMappings() method has been >>>>> >> >>>>>>>>>>> deprecated. Where do >>>>> >> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any >>>>> >> changelog I >>>>> >> >>>>>>>>>>> can refer >>>>> >> >>>>>>>>>>> to? >>>>> >> >>>>>>>>>>> >>>>> >> >>>>>>>>>>> Thanks. >>>>> >> >>>>>>>>>>> -- >>>>> >> >>>>>>>>>>> Regards, Petar! >>>>> >> >>>>>>>>>>> Karlovo, Bulgaria. >>>>> >> >>>>>>>>>>> --- >>>>> >> >>>>>>>>>>> Public PGP Key at: >>>>> >> >>>>>>>>>>> >>>>> >> >>>>>>>>>>> >>>>> >> >>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>> >> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>>> 8550 C311 >>>>> >> >>>>>>>>>>> 0611 >>>>> >> >>>>>>>>>>> _______________________________________________ >>>>> >> >>>>>>>>>>> hibernate-dev mailing list >>>>> >> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>> >> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >> >>>>>>>>>>> >>>>> >> >>>>>>>>>> >>>>> >> >>>>>>>>>> >>>>> >> >>>>>>>>> >>>>> >> >>>>>>>> >>>>> >> >>>>>>> >>>>> >> >>>>>>> >>>>> >> >>>>>>> -- >>>>> >> >>>>>>> Regards, Petar! >>>>> >> >>>>>>> Karlovo, Bulgaria. >>>>> >> >>>>>>> --- >>>>> >> >>>>>>> Public PGP Key at: >>>>> >> >>>>>>> >>>>> >> >>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>> >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>>> C311 >>>>> >> 0611 >>>>> >> >>>>>>> >>>>> >> >>>>>> >>>>> >> >>>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> -- >>>>> >> >>>>> Regards, Petar! >>>>> >> >>>>> Karlovo, Bulgaria. >>>>> >> >>>>> --- >>>>> >> >>>>> Public PGP Key at: >>>>> >> >>>>> >>>>> >> >>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>> >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>>> C311 0611 >>>>> >> >>>>> >>>>> >> >>>> >>>>> >> >>>> >>>>> >> >>>> >>>>> >> >>>> -- >>>>> >> >>>> Regards, Petar! >>>>> >> >>>> Karlovo, Bulgaria. >>>>> >> >>>> --- >>>>> >> >>>> Public PGP Key at: >>>>> >> >>>> >>>>> >> >>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>> >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>>> C311 0611 >>>>> >> >>>> >>>>> >> >>> >>>>> >> >>> >>>>> >> >> >>>>> >> > _______________________________________________ >>>>> >> > hibernate-dev mailing list >>>>> >> > hibernate-dev(a)lists.jboss.org >>>>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >> >>>>> > >>>>> > >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> >>>> >>> >> >

On 01 Apr 2015, at 18:09, Steve Ebersole <steve(a)hibernate.org&gt; wrote: I'm not going to argue with you man. AnimalSniffer *is* run. If you don't believe that and don't want to verify it for yourself, oh well, nothing I can do about that... On Wed, Apr 1, 2015 at 8:32 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > Hum, you are not April-fooling me, right ;) > > There is something Java-8-specific in already: the usage of > ConcurrentHashMap#keySet() (in > SessionFactoryImpl#iterateEntityNameResolvers()) which - when compiled on > Java 8 - adds a reference to the Java-8-only type KeySetView to the class > file of SessionFactoryImpl. That's the issue pointed out by Petar > originally. > > But when running "./gradlew build" on the current master, the build > passes. I would expect it to fail though, as AnimalSniffer should detect > that usage of Java 8's KeySetView class. So I don't see that AS is executed > actually? Or are you saying it is run but it's findings don't cause the > build to fail? > > If I go back to the original approach of using AS (via git checkout > 5f6d1~1), it behaves as I'd expect it: "./gradlew build" fails due to that > reference from SessionFactoryImpl#iterateEntityNameResolvers(). > > Do you actually see the build on master fail due to that reference being > discovered by AS? > > > 2015-04-01 15:03 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> Gunnar, it is applied. Add something that is java 8 specific and see... >> On Apr 1, 2015 7:59 AM, "Gunnar Morling" <gunnar(a)hibernate.org&gt; wrote: >> >>> I saw the plug-in, Steve. But how/when is it executed? >>> >>> Running "./gradlew build" used to execute AnimalSniffer and would have >>> revealed that accidental usage of KeySetView. That's not the case anymore. >>> It would be nice if that new plug-in could be applied automatically after >>> compileJava as it used to be the case with the Ant-based approach. >>> >>> >>> 2015-04-01 13:48 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>> >>>> Increase your Gradle-fu we must young apprentice :) >>>> >>>> AnimalSniffer is still run. I simply converted it to be a plugin. >>>> Check out org.hibernate.build.animalsniffer.AnimalSnifferPlugin in ORM's >>>> /buildSrc project >>>> >>>> AnimalSniffer will apparently not detect this :) >>>> >>>> On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; >>>> wrote: >>>> >>>>>> Currently, AnimalSniffer is in place to prevent this very category >>>>> of error and I'm wondering why it didn't detect the "usage" of KeySetView. >>>>> >>>>> Looked at this a bit closer. Turns out, AnimalSniffer *will* detect >>>>> this issue if it actually is run. The problem is that AS apparently is >>>>> not executed by default anymore, due to the recent change to how AS is used >>>>> [1]. >>>>> >>>>> Prior to that change, running AS was done automatically after the compileJava >>>>> task and would have reported that usage of KeySetView: >>>>> >>>>> Undefined reference: >>>>> java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>> in >>>>> [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class >>>>> >>>>> Unfortunately my Gradle Foo is rather limited, so I'm not sure how to >>>>> re-establish that behaviour with the new AS plug-in. >>>>> >>>>> --Gunnar >>>>> >>>>> [1] >>>>> https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb6... >>>>> >>>>> >>>>> >>>>> >>>>> 2015-04-01 9:39 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: >>>>> >>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>>> >>>>>>> Just to clarify... I *think* that as long as we run the build with >>>>>>> Java 8 >>>>>>> and set the bootclasspath to 6 or 7 we should be fine. >>>>>>> >>>>>> >>>>>> Yes, setting the boot classpath to 6 (or 7) makes sure you only use >>>>>> classes present in that JDK (be it explicitly or implicitly as in the >>>>>> ConcurrentHashMap case), because it's that class library which will be used >>>>>> for compilation then. It is cumbersome to use though as you need to specify >>>>>> the location of a 6 or 7 JDK which makes the build less easily portable >>>>>> between machines. >>>>>> >>>>>> Currently, AnimalSniffer is in place to prevent this very category of >>>>>> error and I'm wondering why it didn't detect the "usage" of KeySetView. It >>>>>> really should have detected it, assuming it analyses the byte code of >>>>>> classes. But this makes me wonder now whether it only analyses the source >>>>>> code actually. Then it wouldn't be usable to prevent this sort of issue. >>>>>> >>>>>> Coding against the ConcurrentMap interface is the best way to avoid >>>>>> the issue. But of course there is no guarantee that it happens again, >>>>>> unless e.g. having a build on CI which uses 6 or 7 on its boot classpath. >>>>>> >>>>>> >>>>>>> On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> Well the idea is to run the Gradle process with Java 8 (the build >>>>>>> itself >>>>>>>> is a Java process too don't forget). We pass in the older JDK >>>>>>> specifically >>>>>>>> to be able to set the bootclasspath for compilation and the >>>>>>> executable for >>>>>>>> running tests. That's the theory. >>>>>>>> >>>>>>>> Interestingly I developed a simplified project to test these >>>>>>> theories: >>>>>>>> https://github.com/sebersole/gradle-mixed-jdk And of course this >>>>>>> all >>>>>>>> works there. As you'd expect right? >>>>>>>> >>>>>>>> I think the JAXB thing comes into play here as well. Gradle does >>>>>>> not have >>>>>>>> any XJC support built in, so we have to make use of its Ant >>>>>>> support to run >>>>>>>> the XJC Ant tasks for JAXB model generation. The problem there is >>>>>>> that, >>>>>>>> afaik, there is no way to tell Gradle's AntBuilder to use a JDK >>>>>>> other than >>>>>>>> the one that launched Gradle. I think this is why we see a JAXB >>>>>>> model >>>>>>>> defined for Java 7, rather than Java 6, because we essentially run >>>>>>> XJC with >>>>>>>> Java 8. >>>>>>>> >>>>>>>> Anyway, this certainly makes the build more complex and we >>>>>>> definitely have >>>>>>>> to think through all these scenarios. In fact after Beta1, one of >>>>>>> my todos >>>>>>>> is to build up the build "from scratch" using that >>>>>>> gradle-mixed-jdk project >>>>>>>> as a basis. >>>>>>>> >>>>>>>> In general the plan though is to run all the tests (other than >>>>>>>> hibernate-java8, obviously) with the "baseline JDK, whether that >>>>>>> be Java 6 >>>>>>>> or 7. >>>>>>>> >>>>>>>> On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>>>>> sanne(a)hibernate.org&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>>> There are many similar issues discussed on the Lucene developer's >>>>>>>>> mailing list, it's an interesting read: >>>>>>>>> - >>>>>>>>> >>>>>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>>>>>>> >>>>>>>>> I see no alternative than to have those test jobs actually >>>>>>> exercising >>>>>>>>> ORM with JDK6, or maybe even compile it all with JDK6 except the >>>>>>> Java8 >>>>>>>>> additional module to be compiled with JDK8 ? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; >>>>>>> wrote: >>>>>>>>>> Ahh, seems this may be an option to work around it: >>>>>>>>>> >>>>>>>>>> <quote> >>>>>>>>>> Using the general *Map* interface in place of the concrete >>>>>>>>>> *ConcurrentHashMap* type here side-steps the coupling to the >>>>>>> Java 8 >>>>>>>>> return >>>>>>>>>> type and will allow this code to be compiled with Java 8 and >>>>>>> run on >>>>>>>>> Java 7. >>>>>>>>>> </quote> >>>>>>>>>> >>>>>>>>>> I had missed that part. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>>>>> steve(a)hibernate.org&gt; >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> When I say "internal" here, I mean internal to java classes. >>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Nope. It just effects any code compiled with Java 8 even >>>>>>> though the >>>>>>>>>>>> change is internal. The problem is the generated bytecode >>>>>>>>> incorporates >>>>>>>>>>>> this change. Like I said, this should be compiled with 1.6 >>>>>>>>> compatibility, >>>>>>>>>>>> but that is apparently not working atm. I am having a >>>>>>> struggle >>>>>>>>> getting a >>>>>>>>>>>> mixed JDK build working "just right". >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>>>>>>> paranoiabla(a)gmail.com&gt; >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> According to this: >>>>>>>>>>>>> >>>>>>>>>>>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>>>>>>>>>>> >>>>>>>>>>>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a >>>>>>> Set<K> >>>>>>>>> while >>>>>>>>>>>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>>>>>>>>>>> ConcurrentHashMap.KeySetView<K,V>`. >>>>>>>>>>>>> >>>>>>>>>>>>> I think you're using some Java8 API. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>>>>> paranoiabla(a)gmail.com&gt;: >>>>>>>>>>>>> >>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>>>>>>>>>>>> java version "1.7.0_71" >>>>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed >>>>>>> mode) >>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>>>>>>>>>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu >>>>>>> SMP Thu >>>>>>>>> Mar >>>>>>>>>>>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> What JRE are you trying to use? This error: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>>>>>>>>>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>>>>>>>>>>>>> ConcurrentHashMap$KeySetView; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> is indicative of an issue in cross-jre support due to a >>>>>>> change >>>>>>>>>>>>>>> internal to java classes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>>>>>>> paranoiabla(a)gmail.com >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks Steve, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I managed to migrate my configuration to the new >>>>>>>>>>>>>>>> MetamodelImplementor. Now when I run the scema export I >>>>>>> get a lot >>>>>>>>> of these >>>>>>>>>>>>>>>> warning: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> INFO : HHH000400: Using dialect: >>>>>>>>> org.hibernate.dialect.MySQL5Dialect >>>>>>>>>>>>>>>> WARN : JDBC Driver reports it stores quoted identifiers >>>>>>> in both >>>>>>>>> mixed >>>>>>>>>>>>>>>> and upper case >>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>> >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>> >>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>> >>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>> >>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>> >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> and when I run some test I get the following exception: >>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>> >>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>>>>>>>>>>>>>> at >>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>>>>>>>>>>>>>> at >>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am told that the bug does not affect the >>>>>>> JBoss->Central sync >>>>>>>>>>>>>>>>> process. So at some point the artifacts should all be >>>>>>> available >>>>>>>>> in Central >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>>>>>>>> steve(a)hibernate.org >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> hibernate-core seems to be the only artifact that is >>>>>>> available >>>>>>>>> in >>>>>>>>>>>>>>>>>> JBoss Nexus. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>>>>>>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So apparently the artifacts / repo issue is a Nexus >>>>>>> bug that is >>>>>>>>>>>>>>>>>>> effecting the JBoss repo (and therefore us)... >>>>>>>>>>>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> As I pointed out in the announcement, I am managing the >>>>>>>>> "migration >>>>>>>>>>>>>>>>>>> guide" in source repo while I develop the Betas. See >>>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>>>>>>>>>>>>>>>> As far are the new bootstrapping apis, see >>>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>>>>>>>>>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I just tried the latest beta and I cannot compile my >>>>>>> project. >>>>>>>>>>>>>>>>>>>> With the >>>>>>>>>>>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>>>>>>>>>>>>>>>>>> ------- >>>>>>>>>>>>>>>>>>>> final org.hibernate.cfg.Configuration >>>>>>> configuration = >>>>>>>>>>>>>>>>>>>> getHibernateConfiguration(); >>>>>>>>>>>>>>>>>>>> configuration.buildMappings(); >>>>>>>>>>>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>>>>>>>>>>>>>>>>>> SchemaUpdate(configuration); >>>>>>>>>>>>>>>>>>>> ------- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> however it seems that the SchemaUpdate constructor >>>>>>> has been >>>>>>>>>>>>>>>>>>>> removed and now >>>>>>>>>>>>>>>>>>>> a new one is added: >>>>>>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) >>>>>>> { >>>>>>>>>>>>>>>>>>>> this( >>>>>>>>>>>>>>>>>>>> >>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>>>>>>>>>>>>>>>> metadata ); >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Also the configuration.buildMappings() method has been >>>>>>>>>>>>>>>>>>>> deprecated. Where do >>>>>>>>>>>>>>>>>>>> I get the MetadataImplementor from? Also is there any >>>>>>>>> changelog I >>>>>>>>>>>>>>>>>>>> can refer >>>>>>>>>>>>>>>>>>>> to? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>>>>> 8550 C311 >>>>>>>>>>>>>>>>>>>> 0611 >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>>>>>>>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>>>>> C311 >>>>>>>>> 0611 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>>>>>> >>>>>>>>> >>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>>>>> C311 0611 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Regards, Petar! >>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>>>> --- >>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>>>>> >>>>>>>>> >>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>>>>> C311 0611 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> hibernate-dev mailing list >>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> hibernate-dev mailing list >>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi Steve, the test project that I created still fails with the latest SNAPSHOT release, although the foreign keys are not created. Can you please investigate if that is related to the same issue. The test repository is here: https://github.com/paranoiabla/HHH-8805 2015-04-03 16:15 GMT+03:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > Steve, I think there is something fishy. > I have created a branch with a blatant usage of a JDK 8 API in > hibernate-core > There is one commit above today’s master: > > protected EmptyInterceptor() { > + final java.time.ZoneId id = > java.time.ZoneId.systemDefault(); > + System.out.println( id.getId() ); > } > > https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer < > https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer> > > > And when I run ./gradlew clean build > things do pass, i.e. Animal Sniffer is either not executed or it does not > make the build fail. I did not see any Animal Sniffer reference in the > console while it was running. > > Does it do the same for you if you clone my branch? > > Emmanuel > > PS: 18 mins here on a Mac + SSD. I guess Linux beats the crap out of Mac > on FindBug executions ;) > > > On 01 Apr 2015, at 18:09, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > > > I'm not going to argue with you man. AnimalSniffer *is* run. If you > don't > > believe that and don't want to verify it for yourself, oh well, nothing > I > > can do about that... > > > > On Wed, Apr 1, 2015 at 8:32 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; > wrote: > > > >> Hum, you are not April-fooling me, right ;) > >> > >> There is something Java-8-specific in already: the usage of > >> ConcurrentHashMap#keySet() (in > >> SessionFactoryImpl#iterateEntityNameResolvers()) which - when compiled > on > >> Java 8 - adds a reference to the Java-8-only type KeySetView to the > class > >> file of SessionFactoryImpl. That's the issue pointed out by Petar > >> originally. > >> > >> But when running "./gradlew build" on the current master, the build > >> passes. I would expect it to fail though, as AnimalSniffer should > detect > >> that usage of Java 8's KeySetView class. So I don't see that AS is > executed > >> actually? Or are you saying it is run but it's findings don't cause the > >> build to fail? > >> > >> If I go back to the original approach of using AS (via git checkout > >> 5f6d1~1), it behaves as I'd expect it: "./gradlew build" fails due to > that > >> reference from SessionFactoryImpl#iterateEntityNameResolvers(). > >> > >> Do you actually see the build on master fail due to that reference > being > >> discovered by AS? > >> > >> > >> 2015-04-01 15:03 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> > >>> Gunnar, it is applied. Add something that is java 8 specific and > see... > >>> On Apr 1, 2015 7:59 AM, "Gunnar Morling" <gunnar(a)hibernate.org&gt; > wrote: > >>> > >>>> I saw the plug-in, Steve. But how/when is it executed? > >>>> > >>>> Running "./gradlew build" used to execute AnimalSniffer and would > have > >>>> revealed that accidental usage of KeySetView. That's not the case > anymore. > >>>> It would be nice if that new plug-in could be applied automatically > after > >>>> compileJava as it used to be the case with the Ant-based approach. > >>>> > >>>> > >>>> 2015-04-01 13:48 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >>>> > >>>>> Increase your Gradle-fu we must young apprentice :) > >>>>> > >>>>> AnimalSniffer is still run. I simply converted it to be a plugin. > >>>>> Check out org.hibernate.build.animalsniffer.AnimalSnifferPlugin in > ORM's > >>>>> /buildSrc project > >>>>> > >>>>> AnimalSniffer will apparently not detect this :) > >>>>> > >>>>> On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling < > gunnar(a)hibernate.org&gt; > >>>>> wrote: > >>>>> > >>>>>>> Currently, AnimalSniffer is in place to prevent this very category > >>>>>> of error and I'm wondering why it didn't detect the "usage" of > KeySetView. > >>>>>> > >>>>>> Looked at this a bit closer. Turns out, AnimalSniffer *will* detect > >>>>>> this issue if it actually is run. The problem is that AS > apparently is > >>>>>> not executed by default anymore, due to the recent change to how > AS is used > >>>>>> [1]. > >>>>>> > >>>>>> Prior to that change, running AS was done automatically after the > compileJava > >>>>>> task and would have reported that usage of KeySetView: > >>>>>> > >>>>>> Undefined reference: > >>>>>> > java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; > >>>>>> in > >>>>>> > [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class > >>>>>> > >>>>>> Unfortunately my Gradle Foo is rather limited, so I'm not sure how > to > >>>>>> re-establish that behaviour with the new AS plug-in. > >>>>>> > >>>>>> --Gunnar > >>>>>> > >>>>>> [1] > >>>>>> > https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb6... > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 2015-04-01 9:39 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: > >>>>>> > >>>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >>>>>>> > >>>>>>>> Just to clarify... I *think* that as long as we run the build > with > >>>>>>>> Java 8 > >>>>>>>> and set the bootclasspath to 6 or 7 we should be fine. > >>>>>>>> > >>>>>>> > >>>>>>> Yes, setting the boot classpath to 6 (or 7) makes sure you only > use > >>>>>>> classes present in that JDK (be it explicitly or implicitly as in > the > >>>>>>> ConcurrentHashMap case), because it's that class library which > will be used > >>>>>>> for compilation then. It is cumbersome to use though as you need > to specify > >>>>>>> the location of a 6 or 7 JDK which makes the build less easily > portable > >>>>>>> between machines. > >>>>>>> > >>>>>>> Currently, AnimalSniffer is in place to prevent this very > category of > >>>>>>> error and I'm wondering why it didn't detect the "usage" of > KeySetView. It > >>>>>>> really should have detected it, assuming it analyses the byte > code of > >>>>>>> classes. But this makes me wonder now whether it only analyses > the source > >>>>>>> code actually. Then it wouldn't be usable to prevent this sort of > issue. > >>>>>>> > >>>>>>> Coding against the ConcurrentMap interface is the best way to > avoid > >>>>>>> the issue. But of course there is no guarantee that it happens > again, > >>>>>>> unless e.g. having a build on CI which uses 6 or 7 on its boot > classpath. > >>>>>>> > >>>>>>> > >>>>>>>> On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole < > steve(a)hibernate.org&gt; > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Well the idea is to run the Gradle process with Java 8 (the > build > >>>>>>>> itself > >>>>>>>>> is a Java process too don't forget). We pass in the older JDK > >>>>>>>> specifically > >>>>>>>>> to be able to set the bootclasspath for compilation and the > >>>>>>>> executable for > >>>>>>>>> running tests. That's the theory. > >>>>>>>>> > >>>>>>>>> Interestingly I developed a simplified project to test these > >>>>>>>> theories: > >>>>>>>>> https://github.com/sebersole/gradle-mixed-jdk And of course > this > >>>>>>>> all > >>>>>>>>> works there. As you'd expect right? > >>>>>>>>> > >>>>>>>>> I think the JAXB thing comes into play here as well. Gradle > does > >>>>>>>> not have > >>>>>>>>> any XJC support built in, so we have to make use of its Ant > >>>>>>>> support to run > >>>>>>>>> the XJC Ant tasks for JAXB model generation. The problem there > is > >>>>>>>> that, > >>>>>>>>> afaik, there is no way to tell Gradle's AntBuilder to use a JDK > >>>>>>>> other than > >>>>>>>>> the one that launched Gradle. I think this is why we see a JAXB > >>>>>>>> model > >>>>>>>>> defined for Java 7, rather than Java 6, because we essentially > run > >>>>>>>> XJC with > >>>>>>>>> Java 8. > >>>>>>>>> > >>>>>>>>> Anyway, this certainly makes the build more complex and we > >>>>>>>> definitely have > >>>>>>>>> to think through all these scenarios. In fact after Beta1, one > of > >>>>>>>> my todos > >>>>>>>>> is to build up the build "from scratch" using that > >>>>>>>> gradle-mixed-jdk project > >>>>>>>>> as a basis. > >>>>>>>>> > >>>>>>>>> In general the plan though is to run all the tests (other than > >>>>>>>>> hibernate-java8, obviously) with the "baseline JDK, whether that > >>>>>>>> be Java 6 > >>>>>>>>> or 7. > >>>>>>>>> > >>>>>>>>> On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < > >>>>>>>> sanne(a)hibernate.org&gt; > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> There are many similar issues discussed on the Lucene > developer's > >>>>>>>>>> mailing list, it's an interesting read: > >>>>>>>>>> - > >>>>>>>>>> > >>>>>>>> > http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... > >>>>>>>>>> > >>>>>>>>>> I see no alternative than to have those test jobs actually > >>>>>>>> exercising > >>>>>>>>>> ORM with JDK6, or maybe even compile it all with JDK6 except > the > >>>>>>>> Java8 > >>>>>>>>>> additional module to be compiled with JDK8 ? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; > >>>>>>>> wrote: > >>>>>>>>>>> Ahh, seems this may be an option to work around it: > >>>>>>>>>>> > >>>>>>>>>>> <quote> > >>>>>>>>>>> Using the general *Map* interface in place of the concrete > >>>>>>>>>>> *ConcurrentHashMap* type here side-steps the coupling to the > >>>>>>>> Java 8 > >>>>>>>>>> return > >>>>>>>>>>> type and will allow this code to be compiled with Java 8 and > >>>>>>>> run on > >>>>>>>>>> Java 7. > >>>>>>>>>>> </quote> > >>>>>>>>>>> > >>>>>>>>>>> I had missed that part. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < > >>>>>>>> steve(a)hibernate.org&gt; > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> When I say "internal" here, I mean internal to java classes. > >>>>>>>>>>>> > >>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < > >>>>>>>> steve(a)hibernate.org&gt; > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Nope. It just effects any code compiled with Java 8 even > >>>>>>>> though the > >>>>>>>>>>>>> change is internal. The problem is the generated bytecode > >>>>>>>>>> incorporates > >>>>>>>>>>>>> this change. Like I said, this should be compiled with 1.6 > >>>>>>>>>> compatibility, > >>>>>>>>>>>>> but that is apparently not working atm. I am having a > >>>>>>>> struggle > >>>>>>>>>> getting a > >>>>>>>>>>>>> mixed JDK build working "just right". > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < > >>>>>>>>>> paranoiabla(a)gmail.com&gt; > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> According to this: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a > >>>>>>>> Set<K> > >>>>>>>>>> while > >>>>>>>>>>>>>> the 1.8*ConcurrentHashMap#keySet()* returns a > >>>>>>>>>>>>>> ConcurrentHashMap.KeySetView<K,V>`. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I think you're using some Java8 API. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < > >>>>>>>> paranoiabla(a)gmail.com&gt;: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version > >>>>>>>>>>>>>>> java version "1.7.0_71" > >>>>>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) > >>>>>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed > >>>>>>>> mode) > >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a > >>>>>>>>>>>>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic > #44-Ubuntu > >>>>>>>> SMP Thu > >>>>>>>>>> Mar > >>>>>>>>>>>>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < > >>>>>>>> steve(a)hibernate.org&gt;: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> What JRE are you trying to use? This error: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: java.util.concurrent. > >>>>>>>>>>>>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ > >>>>>>>>>>>>>>>> ConcurrentHashMap$KeySetView; > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> is indicative of an issue in cross-jre support due to a > >>>>>>>> change > >>>>>>>>>>>>>>>> internal to java classes. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < > >>>>>>>>>> paranoiabla(a)gmail.com > >>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks Steve, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I managed to migrate my configuration to the new > >>>>>>>>>>>>>>>>> MetamodelImplementor. Now when I run the scema export I > >>>>>>>> get a lot > >>>>>>>>>> of these > >>>>>>>>>>>>>>>>> warning: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> INFO : HHH000400: Using dialect: > >>>>>>>>>> org.hibernate.dialect.MySQL5Dialect > >>>>>>>>>>>>>>>>> WARN : JDBC Driver reports it stores quoted identifiers > >>>>>>>> in both > >>>>>>>>>> mixed > >>>>>>>>>>>>>>>>> and upper case > >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>>>>>>>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel > >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>>>>>>>>>>>> > >>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel > >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>>>>>>>>>>>> > >>>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel > >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>>>>>>>>>>>> > >>>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel > >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel > >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>>>>>>>>>>>> > >>>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel > >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: > >>>>>>>>>>>>>>>>> > >>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> and when I run some test I get the following exception: > >>>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: > >>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; > >>>>>>>>>>>>>>>>> at > >>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) > >>>>>>>>>>>>>>>>> at > >>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) > >>>>>>>>>>>>>>>>> at > >>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) > >>>>>>>>>>>>>>>>> at > >>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) > >>>>>>>>>>>>>>>>> at > >>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) > >>>>>>>>>>>>>>>>> at > >>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) > >>>>>>>>>>>>>>>>> at > >>>>>>>>>>>>>>>>> > >>>>>>>> > org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) > >>>>>>>>>>>>>>>>> at > >>>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) > >>>>>>>>>>>>>>>>> at > >>>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) > >>>>>>>>>>>>>>>>> at > >>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) > >>>>>>>>>>>>>>>>> at > >>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) > >>>>>>>>>>>>>>>>> at > >>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < > >>>>>>>> steve(a)hibernate.org&gt;: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I am told that the bug does not affect the > >>>>>>>> JBoss->Central sync > >>>>>>>>>>>>>>>>>> process. So at some point the artifacts should all be > >>>>>>>> available > >>>>>>>>>> in Central > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < > >>>>>>>>>> steve(a)hibernate.org > >>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> hibernate-core seems to be the only artifact that is > >>>>>>>> available > >>>>>>>>>> in > >>>>>>>>>>>>>>>>>>> JBoss Nexus. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < > >>>>>>>>>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> So apparently the artifacts / repo issue is a Nexus > >>>>>>>> bug that is > >>>>>>>>>>>>>>>>>>>> effecting the JBoss repo (and therefore us)... > >>>>>>>>>>>>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> As I pointed out in the announcement, I am managing > the > >>>>>>>>>> "migration > >>>>>>>>>>>>>>>>>>>> guide" in source repo while I develop the Betas. See > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... > >>>>>>>>>>>>>>>>>>>> As far are the new bootstrapping apis, see > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... > >>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < > >>>>>>>>>>>>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Hi guys, > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> I just tried the latest beta and I cannot compile my > >>>>>>>> project. > >>>>>>>>>>>>>>>>>>>>> With the > >>>>>>>>>>>>>>>>>>>>> latest hibernate 4.3.X I was able to do this: > >>>>>>>>>>>>>>>>>>>>> ------- > >>>>>>>>>>>>>>>>>>>>> final org.hibernate.cfg.Configuration > >>>>>>>> configuration = > >>>>>>>>>>>>>>>>>>>>> getHibernateConfiguration(); > >>>>>>>>>>>>>>>>>>>>> configuration.buildMappings(); > >>>>>>>>>>>>>>>>>>>>> final SchemaUpdate schemaUpdate = new > >>>>>>>>>>>>>>>>>>>>> SchemaUpdate(configuration); > >>>>>>>>>>>>>>>>>>>>> ------- > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> however it seems that the SchemaUpdate constructor > >>>>>>>> has been > >>>>>>>>>>>>>>>>>>>>> removed and now > >>>>>>>>>>>>>>>>>>>>> a new one is added: > >>>>>>>>>>>>>>>>>>>>> -------- > >>>>>>>>>>>>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) > >>>>>>>> { > >>>>>>>>>>>>>>>>>>>>> this( > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), > >>>>>>>>>>>>>>>>>>>>> metadata ); > >>>>>>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>>>>>> --------- > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Also the configuration.buildMappings() method has > been > >>>>>>>>>>>>>>>>>>>>> deprecated. Where do > >>>>>>>>>>>>>>>>>>>>> I get the MetadataImplementor from? Also is there > any > >>>>>>>>>> changelog I > >>>>>>>>>>>>>>>>>>>>> can refer > >>>>>>>>>>>>>>>>>>>>> to? > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>> Regards, Petar! > >>>>>>>>>>>>>>>>>>>>> Karlovo, Bulgaria. > >>>>>>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>>>>>> Public PGP Key at: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >>>>>>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 > >>>>>>>> 8550 C311 > >>>>>>>>>>>>>>>>>>>>> 0611 > >>>>>>>>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>>>>>>>> hibernate-dev mailing list > >>>>>>>>>>>>>>>>>>>>> hibernate-dev(a)lists.jboss.org > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>> Regards, Petar! > >>>>>>>>>>>>>>>>> Karlovo, Bulgaria. > >>>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>>> Public PGP Key at: > >>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 > 8550 > >>>>>>>> C311 > >>>>>>>>>> 0611 > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>> Regards, Petar! > >>>>>>>>>>>>>>> Karlovo, Bulgaria. > >>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>> Public PGP Key at: > >>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 > >>>>>>>> C311 0611 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> Regards, Petar! > >>>>>>>>>>>>>> Karlovo, Bulgaria. > >>>>>>>>>>>>>> --- > >>>>>>>>>>>>>> Public PGP Key at: > >>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 > >>>>>>>> C311 0611 > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> hibernate-dev mailing list > >>>>>>>>>>> hibernate-dev(a)lists.jboss.org > >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> hibernate-dev mailing list > >>>>>>>> hibernate-dev(a)lists.jboss.org > >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611

Just a quick follow-up here: SchemaMigratorImpl:125 is calling existingDatabase.getTableInformation where existingDatabase is of type org.hibernate.tool.schema.extract.internal.*legacy*.DatabaseInformationImpl (I have no idea why is it using the legacy one), and If I step into it I can see it's using a tableInformationMap which is empty - really weird as I can see before that the hbm2ddl was reporting tables were not found so I was expecting it to create them: 2015-04-06 09:29:40,608 org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl [main] INFO : HHH000262: Table not found: warehouse 2015-04-06 09:29:40,610 org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl [main] INFO : HHH000262: Table not found: widget_title_lv 2015-04-06 09:29:40,614 org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl [main] INFO : HHH000262: Table not found: wishlist 2015-04-06 09:29:40,618 org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl [main] INFO : HHH000262: Table not found: wishlist_entry 2015-04-06 09:29:40,622 org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl [main] INFO : HHH000262: Table not found: working_day I'll try to create a test that reproduces the problem 2015-04-06 5:20 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > I see you have a test repository reproducing the error. I will try to > run from there. > > On Sun, Apr 5, 2015 at 3:02 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; > wrote: > >> Hi Steve, >> >> the test project that I created still fails with the latest SNAPSHOT >> release, although the foreign keys are not created. Can you please >> investigate if that is related to the same issue. The test repository is >> here: >> >> https://github.com/paranoiabla/HHH-8805 >> >> >> 2015-04-03 16:15 GMT+03:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >> >>> Steve, I think there is something fishy. >>> I have created a branch with a blatant usage of a JDK 8 API in >>> hibernate-core >>> There is one commit above today’s master: >>> >>> protected EmptyInterceptor() { >>> + final java.time.ZoneId id = >>> java.time.ZoneId.systemDefault(); >>> + System.out.println( id.getId() ); >>> } >>> >>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer < >>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer> >>> >>> >>> And when I run ./gradlew clean build >>> things do pass, i.e. Animal Sniffer is either not executed or it does >>> not make the build fail. I did not see any Animal Sniffer reference in the >>> console while it was running. >>> >>> Does it do the same for you if you clone my branch? >>> >>> Emmanuel >>> >>> PS: 18 mins here on a Mac + SSD. I guess Linux beats the crap out of >>> Mac on FindBug executions ;) >>> >>> > On 01 Apr 2015, at 18:09, Steve Ebersole <steve(a)hibernate.org&gt; wrote: >>> > >>> > I'm not going to argue with you man. AnimalSniffer *is* run. If you >>> don't >>> > believe that and don't want to verify it for yourself, oh well, >>> nothing I >>> > can do about that... >>> > >>> > On Wed, Apr 1, 2015 at 8:32 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; >>> wrote: >>> > >>> >> Hum, you are not April-fooling me, right ;) >>> >> >>> >> There is something Java-8-specific in already: the usage of >>> >> ConcurrentHashMap#keySet() (in >>> >> SessionFactoryImpl#iterateEntityNameResolvers()) which - when >>> compiled on >>> >> Java 8 - adds a reference to the Java-8-only type KeySetView to the >>> class >>> >> file of SessionFactoryImpl. That's the issue pointed out by Petar >>> >> originally. >>> >> >>> >> But when running "./gradlew build" on the current master, the build >>> >> passes. I would expect it to fail though, as AnimalSniffer should >>> detect >>> >> that usage of Java 8's KeySetView class. So I don't see that AS is >>> executed >>> >> actually? Or are you saying it is run but it's findings don't cause >>> the >>> >> build to fail? >>> >> >>> >> If I go back to the original approach of using AS (via git checkout >>> >> 5f6d1~1), it behaves as I'd expect it: "./gradlew build" fails due >>> to that >>> >> reference from SessionFactoryImpl#iterateEntityNameResolvers(). >>> >> >>> >> Do you actually see the build on master fail due to that reference >>> being >>> >> discovered by AS? >>> >> >>> >> >>> >> 2015-04-01 15:03 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>> >> >>> >>> Gunnar, it is applied. Add something that is java 8 specific and >>> see... >>> >>> On Apr 1, 2015 7:59 AM, "Gunnar Morling" <gunnar(a)hibernate.org&gt; >>> wrote: >>> >>> >>> >>>> I saw the plug-in, Steve. But how/when is it executed? >>> >>>> >>> >>>> Running "./gradlew build" used to execute AnimalSniffer and would >>> have >>> >>>> revealed that accidental usage of KeySetView. That's not the case >>> anymore. >>> >>>> It would be nice if that new plug-in could be applied >>> automatically after >>> >>>> compileJava as it used to be the case with the Ant-based approach. >>> >>>> >>> >>>> >>> >>>> 2015-04-01 13:48 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>> >>>> >>> >>>>> Increase your Gradle-fu we must young apprentice :) >>> >>>>> >>> >>>>> AnimalSniffer is still run. I simply converted it to be a plugin. >>> >>>>> Check out org.hibernate.build.animalsniffer.AnimalSnifferPlugin >>> in ORM's >>> >>>>> /buildSrc project >>> >>>>> >>> >>>>> AnimalSniffer will apparently not detect this :) >>> >>>>> >>> >>>>> On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling < >>> gunnar(a)hibernate.org&gt; >>> >>>>> wrote: >>> >>>>> >>> >>>>>>> Currently, AnimalSniffer is in place to prevent this very >>> category >>> >>>>>> of error and I'm wondering why it didn't detect the "usage" of >>> KeySetView. >>> >>>>>> >>> >>>>>> Looked at this a bit closer. Turns out, AnimalSniffer *will* >>> detect >>> >>>>>> this issue if it actually is run. The problem is that AS >>> apparently is >>> >>>>>> not executed by default anymore, due to the recent change to how >>> AS is used >>> >>>>>> [1]. >>> >>>>>> >>> >>>>>> Prior to that change, running AS was done automatically after >>> the compileJava >>> >>>>>> task and would have reported that usage of KeySetView: >>> >>>>>> >>> >>>>>> Undefined reference: >>> >>>>>> >>> java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>> >>>>>> in >>> >>>>>> >>> [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class >>> >>>>>> >>> >>>>>> Unfortunately my Gradle Foo is rather limited, so I'm not sure >>> how to >>> >>>>>> re-establish that behaviour with the new AS plug-in. >>> >>>>>> >>> >>>>>> --Gunnar >>> >>>>>> >>> >>>>>> [1] >>> >>>>>> >>> https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb6... >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> 2015-04-01 9:39 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: >>> >>>>>> >>> >>>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>> >>>>>>> >>> >>>>>>>> Just to clarify... I *think* that as long as we run the build >>> with >>> >>>>>>>> Java 8 >>> >>>>>>>> and set the bootclasspath to 6 or 7 we should be fine. >>> >>>>>>>> >>> >>>>>>> >>> >>>>>>> Yes, setting the boot classpath to 6 (or 7) makes sure you only >>> use >>> >>>>>>> classes present in that JDK (be it explicitly or implicitly as >>> in the >>> >>>>>>> ConcurrentHashMap case), because it's that class library which >>> will be used >>> >>>>>>> for compilation then. It is cumbersome to use though as you >>> need to specify >>> >>>>>>> the location of a 6 or 7 JDK which makes the build less easily >>> portable >>> >>>>>>> between machines. >>> >>>>>>> >>> >>>>>>> Currently, AnimalSniffer is in place to prevent this very >>> category of >>> >>>>>>> error and I'm wondering why it didn't detect the "usage" of >>> KeySetView. It >>> >>>>>>> really should have detected it, assuming it analyses the byte >>> code of >>> >>>>>>> classes. But this makes me wonder now whether it only analyses >>> the source >>> >>>>>>> code actually. Then it wouldn't be usable to prevent this sort >>> of issue. >>> >>>>>>> >>> >>>>>>> Coding against the ConcurrentMap interface is the best way to >>> avoid >>> >>>>>>> the issue. But of course there is no guarantee that it happens >>> again, >>> >>>>>>> unless e.g. having a build on CI which uses 6 or 7 on its boot >>> classpath. >>> >>>>>>> >>> >>>>>>> >>> >>>>>>>> On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole < >>> steve(a)hibernate.org&gt; >>> >>>>>>>> wrote: >>> >>>>>>>> >>> >>>>>>>>> Well the idea is to run the Gradle process with Java 8 (the >>> build >>> >>>>>>>> itself >>> >>>>>>>>> is a Java process too don't forget). We pass in the older JDK >>> >>>>>>>> specifically >>> >>>>>>>>> to be able to set the bootclasspath for compilation and the >>> >>>>>>>> executable for >>> >>>>>>>>> running tests. That's the theory. >>> >>>>>>>>> >>> >>>>>>>>> Interestingly I developed a simplified project to test these >>> >>>>>>>> theories: >>> >>>>>>>>> https://github.com/sebersole/gradle-mixed-jdk And of course >>> this >>> >>>>>>>> all >>> >>>>>>>>> works there. As you'd expect right? >>> >>>>>>>>> >>> >>>>>>>>> I think the JAXB thing comes into play here as well. Gradle >>> does >>> >>>>>>>> not have >>> >>>>>>>>> any XJC support built in, so we have to make use of its Ant >>> >>>>>>>> support to run >>> >>>>>>>>> the XJC Ant tasks for JAXB model generation. The problem >>> there is >>> >>>>>>>> that, >>> >>>>>>>>> afaik, there is no way to tell Gradle's AntBuilder to use a >>> JDK >>> >>>>>>>> other than >>> >>>>>>>>> the one that launched Gradle. I think this is why we see a >>> JAXB >>> >>>>>>>> model >>> >>>>>>>>> defined for Java 7, rather than Java 6, because we >>> essentially run >>> >>>>>>>> XJC with >>> >>>>>>>>> Java 8. >>> >>>>>>>>> >>> >>>>>>>>> Anyway, this certainly makes the build more complex and we >>> >>>>>>>> definitely have >>> >>>>>>>>> to think through all these scenarios. In fact after Beta1, >>> one of >>> >>>>>>>> my todos >>> >>>>>>>>> is to build up the build "from scratch" using that >>> >>>>>>>> gradle-mixed-jdk project >>> >>>>>>>>> as a basis. >>> >>>>>>>>> >>> >>>>>>>>> In general the plan though is to run all the tests (other than >>> >>>>>>>>> hibernate-java8, obviously) with the "baseline JDK, whether >>> that >>> >>>>>>>> be Java 6 >>> >>>>>>>>> or 7. >>> >>>>>>>>> >>> >>>>>>>>> On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>> >>>>>>>> sanne(a)hibernate.org&gt; >>> >>>>>>>>> wrote: >>> >>>>>>>>> >>> >>>>>>>>>> There are many similar issues discussed on the Lucene >>> developer's >>> >>>>>>>>>> mailing list, it's an interesting read: >>> >>>>>>>>>> - >>> >>>>>>>>>> >>> >>>>>>>> >>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>> >>>>>>>>>> >>> >>>>>>>>>> I see no alternative than to have those test jobs actually >>> >>>>>>>> exercising >>> >>>>>>>>>> ORM with JDK6, or maybe even compile it all with JDK6 except >>> the >>> >>>>>>>> Java8 >>> >>>>>>>>>> additional module to be compiled with JDK8 ? >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> On 1 April 2015 at 00:36, Steve Ebersole < >>> steve(a)hibernate.org&gt; >>> >>>>>>>> wrote: >>> >>>>>>>>>>> Ahh, seems this may be an option to work around it: >>> >>>>>>>>>>> >>> >>>>>>>>>>> <quote> >>> >>>>>>>>>>> Using the general *Map* interface in place of the concrete >>> >>>>>>>>>>> *ConcurrentHashMap* type here side-steps the coupling to the >>> >>>>>>>> Java 8 >>> >>>>>>>>>> return >>> >>>>>>>>>>> type and will allow this code to be compiled with Java 8 and >>> >>>>>>>> run on >>> >>>>>>>>>> Java 7. >>> >>>>>>>>>>> </quote> >>> >>>>>>>>>>> >>> >>>>>>>>>>> I had missed that part. >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>> >>>>>>>> steve(a)hibernate.org&gt; >>> >>>>>>>>>> wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>>> When I say "internal" here, I mean internal to java >>> classes. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>> >>>>>>>> steve(a)hibernate.org&gt; >>> >>>>>>>>>>>> wrote: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>>> Nope. It just effects any code compiled with Java 8 even >>> >>>>>>>> though the >>> >>>>>>>>>>>>> change is internal. The problem is the generated bytecode >>> >>>>>>>>>> incorporates >>> >>>>>>>>>>>>> this change. Like I said, this should be compiled with >>> 1.6 >>> >>>>>>>>>> compatibility, >>> >>>>>>>>>>>>> but that is apparently not working atm. I am having a >>> >>>>>>>> struggle >>> >>>>>>>>>> getting a >>> >>>>>>>>>>>>> mixed JDK build working "just right". >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>> >>>>>>>>>> paranoiabla(a)gmail.com&gt; >>> >>>>>>>>>>>>> wrote: >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>>> According to this: >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* >>> returns a >>> >>>>>>>> Set<K> >>> >>>>>>>>>> while >>> >>>>>>>>>>>>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>> >>>>>>>>>>>>>> ConcurrentHashMap.KeySetView<K,V>`. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> I think you're using some Java8 API. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>> >>>>>>>> paranoiabla(a)gmail.com&gt;: >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>> >>>>>>>>>>>>>>> java version "1.7.0_71" >>> >>>>>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>> >>>>>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, >>> mixed >>> >>>>>>>> mode) >>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>> >>>>>>>>>>>>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic >>> #44-Ubuntu >>> >>>>>>>> SMP Thu >>> >>>>>>>>>> Mar >>> >>>>>>>>>>>>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>> >>>>>>>> steve(a)hibernate.org&gt;: >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> What JRE are you trying to use? This error: >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>> >>>>>>>>>>>>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>> >>>>>>>>>>>>>>>> ConcurrentHashMap$KeySetView; >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> is indicative of an issue in cross-jre support due to a >>> >>>>>>>> change >>> >>>>>>>>>>>>>>>> internal to java classes. >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>> >>>>>>>>>> paranoiabla(a)gmail.com >>> >>>>>>>>>>>>>>>>> wrote: >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> Thanks Steve, >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> I managed to migrate my configuration to the new >>> >>>>>>>>>>>>>>>>> MetamodelImplementor. Now when I run the scema export >>> I >>> >>>>>>>> get a lot >>> >>>>>>>>>> of these >>> >>>>>>>>>>>>>>>>> warning: >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> INFO : HHH000400: Using dialect: >>> >>>>>>>>>> org.hibernate.dialect.MySQL5Dialect >>> >>>>>>>>>>>>>>>>> WARN : JDBC Driver reports it stores quoted >>> identifiers >>> >>>>>>>> in both >>> >>>>>>>>>> mixed >>> >>>>>>>>>>>>>>>>> and upper case >>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >>>>>>>>>>>>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>> >>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>> >>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> and when I run some test I get the following >>> exception: >>> >>>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>> >>>>>>>>>>>>>>>>> at >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>> >>>>>>>>>>>>>>>>> at >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>> >>>>>>>>>>>>>>>>> at >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>> >>>>>>>>>>>>>>>>> at >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>> >>>>>>>>>>>>>>>>> at >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>> >>>>>>>>>>>>>>>>> at >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>> >>>>>>>>>>>>>>>>> at >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>> >>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>> >>>>>>>>>>>>>>>>> at >>> >>>>>>>>>> >>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>> >>>>>>>>>>>>>>>>> at >>> >>>>>>>>>> >>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>> >>>>>>>>>>>>>>>>> at >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>> >>>>>>>>>>>>>>>>> at >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>> >>>>>>>>>>>>>>>>> at >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>> >>>>>>>> steve(a)hibernate.org&gt;: >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> I am told that the bug does not affect the >>> >>>>>>>> JBoss->Central sync >>> >>>>>>>>>>>>>>>>>> process. So at some point the artifacts should all >>> be >>> >>>>>>>> available >>> >>>>>>>>>> in Central >>> >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>> >>>>>>>>>> steve(a)hibernate.org >>> >>>>>>>>>>>>>>>>>>> wrote: >>> >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> hibernate-core seems to be the only artifact that is >>> >>>>>>>> available >>> >>>>>>>>>> in >>> >>>>>>>>>>>>>>>>>>> JBoss Nexus. >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>> >>>>>>>>>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> So apparently the artifacts / repo issue is a Nexus >>> >>>>>>>> bug that is >>> >>>>>>>>>>>>>>>>>>>> effecting the JBoss repo (and therefore us)... >>> >>>>>>>>>>>>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> As I pointed out in the announcement, I am >>> managing the >>> >>>>>>>>>> "migration >>> >>>>>>>>>>>>>>>>>>>> guide" in source repo while I develop the Betas. >>> See >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>> >>>>>>>>>>>>>>>>>>>> As far are the new bootstrapping apis, see >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>> >>>>>>>>>>>>>>>>>>>> and >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>> >>>>>>>>>>>>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>> Hi guys, >>> >>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>> I just tried the latest beta and I cannot compile >>> my >>> >>>>>>>> project. >>> >>>>>>>>>>>>>>>>>>>>> With the >>> >>>>>>>>>>>>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>> >>>>>>>>>>>>>>>>>>>>> ------- >>> >>>>>>>>>>>>>>>>>>>>> final org.hibernate.cfg.Configuration >>> >>>>>>>> configuration = >>> >>>>>>>>>>>>>>>>>>>>> getHibernateConfiguration(); >>> >>>>>>>>>>>>>>>>>>>>> configuration.buildMappings(); >>> >>>>>>>>>>>>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>> >>>>>>>>>>>>>>>>>>>>> SchemaUpdate(configuration); >>> >>>>>>>>>>>>>>>>>>>>> ------- >>> >>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>> however it seems that the SchemaUpdate constructor >>> >>>>>>>> has been >>> >>>>>>>>>>>>>>>>>>>>> removed and now >>> >>>>>>>>>>>>>>>>>>>>> a new one is added: >>> >>>>>>>>>>>>>>>>>>>>> -------- >>> >>>>>>>>>>>>>>>>>>>>> public SchemaUpdate(MetadataImplementor >>> metadata) >>> >>>>>>>> { >>> >>>>>>>>>>>>>>>>>>>>> this( >>> >>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>> >>>>>>>>>>>>>>>>>>>>> metadata ); >>> >>>>>>>>>>>>>>>>>>>>> } >>> >>>>>>>>>>>>>>>>>>>>> --------- >>> >>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>> Also the configuration.buildMappings() method has >>> been >>> >>>>>>>>>>>>>>>>>>>>> deprecated. Where do >>> >>>>>>>>>>>>>>>>>>>>> I get the MetadataImplementor from? Also is there >>> any >>> >>>>>>>>>> changelog I >>> >>>>>>>>>>>>>>>>>>>>> can refer >>> >>>>>>>>>>>>>>>>>>>>> to? >>> >>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>> Thanks. >>> >>>>>>>>>>>>>>>>>>>>> -- >>> >>>>>>>>>>>>>>>>>>>>> Regards, Petar! >>> >>>>>>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>> >>>>>>>>>>>>>>>>>>>>> --- >>> >>>>>>>>>>>>>>>>>>>>> Public PGP Key at: >>> >>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> >>>>>>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>> 1965 >>> >>>>>>>> 8550 C311 >>> >>>>>>>>>>>>>>>>>>>>> 0611 >>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>>>>>>>>>>>> hibernate-dev mailing list >>> >>>>>>>>>>>>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>> >>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> -- >>> >>>>>>>>>>>>>>>>> Regards, Petar! >>> >>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>> >>>>>>>>>>>>>>>>> --- >>> >>>>>>>>>>>>>>>>> Public PGP Key at: >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> >>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>> 8550 >>> >>>>>>>> C311 >>> >>>>>>>>>> 0611 >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> -- >>> >>>>>>>>>>>>>>> Regards, Petar! >>> >>>>>>>>>>>>>>> Karlovo, Bulgaria. >>> >>>>>>>>>>>>>>> --- >>> >>>>>>>>>>>>>>> Public PGP Key at: >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> >>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>> 8550 >>> >>>>>>>> C311 0611 >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> -- >>> >>>>>>>>>>>>>> Regards, Petar! >>> >>>>>>>>>>>>>> Karlovo, Bulgaria. >>> >>>>>>>>>>>>>> --- >>> >>>>>>>>>>>>>> Public PGP Key at: >>> >>>>>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>> >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> >>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>> >>>>>>>> C311 0611 >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>> hibernate-dev mailing list >>> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>> _______________________________________________ >>> >>>>>>>> hibernate-dev mailing list >>> >>>>>>>> hibernate-dev(a)lists.jboss.org >>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>> >>> >>>>> >>> >>>> >>> >> >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> > > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611

Well there is a gigantic comment in org.hibernate.tool.schema. extract.internal.*legacy*.DatabaseInformationImpl that says how the tableInformationMap is not used, and why :) The problem is the HHH000262 log statement. That is saying that the tables are not found querying the database metadata. On Mon, Apr 6, 2015 at 1:34 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; wrote: > Just a quick follow-up here: SchemaMigratorImpl:125 is calling > existingDatabase.getTableInformation where existingDatabase is of type > org.hibernate.tool.schema.extract.internal.*legacy*.DatabaseInformationImpl > (I have no idea why is it using the legacy one), and If I step into it I > can see it's using a tableInformationMap which is empty - really weird as I > can see before that the hbm2ddl was reporting tables were not found so I > was expecting it to create them: > > 2015-04-06 09:29:40,608 > org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl > [main] INFO : HHH000262: Table not found: warehouse > 2015-04-06 09:29:40,610 > org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl > [main] INFO : HHH000262: Table not found: widget_title_lv > 2015-04-06 09:29:40,614 > org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl > [main] INFO : HHH000262: Table not found: wishlist > 2015-04-06 09:29:40,618 > org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl > [main] INFO : HHH000262: Table not found: wishlist_entry > 2015-04-06 09:29:40,622 > org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl > [main] INFO : HHH000262: Table not found: working_day > > > I'll try to create a test that reproduces the problem > > > 2015-04-06 5:20 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> I see you have a test repository reproducing the error. I will try to >> run from there. >> >> On Sun, Apr 5, 2015 at 3:02 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >> wrote: >> >>> Hi Steve, >>> >>> the test project that I created still fails with the latest SNAPSHOT >>> release, although the foreign keys are not created. Can you please >>> investigate if that is related to the same issue. The test repository is >>> here: >>> >>> https://github.com/paranoiabla/HHH-8805 >>> >>> >>> 2015-04-03 16:15 GMT+03:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >>> >>>> Steve, I think there is something fishy. >>>> I have created a branch with a blatant usage of a JDK 8 API in >>>> hibernate-core >>>> There is one commit above today’s master: >>>> >>>> protected EmptyInterceptor() { >>>> + final java.time.ZoneId id = >>>> java.time.ZoneId.systemDefault(); >>>> + System.out.println( id.getId() ); >>>> } >>>> >>>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer < >>>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer> >>>> >>>> >>>> And when I run ./gradlew clean build >>>> things do pass, i.e. Animal Sniffer is either not executed or it does >>>> not make the build fail. I did not see any Animal Sniffer reference in the >>>> console while it was running. >>>> >>>> Does it do the same for you if you clone my branch? >>>> >>>> Emmanuel >>>> >>>> PS: 18 mins here on a Mac + SSD. I guess Linux beats the crap out of >>>> Mac on FindBug executions ;) >>>> >>>> > On 01 Apr 2015, at 18:09, Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> > >>>> > I'm not going to argue with you man. AnimalSniffer *is* run. If >>>> you don't >>>> > believe that and don't want to verify it for yourself, oh well, >>>> nothing I >>>> > can do about that... >>>> > >>>> > On Wed, Apr 1, 2015 at 8:32 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; >>>> wrote: >>>> > >>>> >> Hum, you are not April-fooling me, right ;) >>>> >> >>>> >> There is something Java-8-specific in already: the usage of >>>> >> ConcurrentHashMap#keySet() (in >>>> >> SessionFactoryImpl#iterateEntityNameResolvers()) which - when >>>> compiled on >>>> >> Java 8 - adds a reference to the Java-8-only type KeySetView to the >>>> class >>>> >> file of SessionFactoryImpl. That's the issue pointed out by Petar >>>> >> originally. >>>> >> >>>> >> But when running "./gradlew build" on the current master, the build >>>> >> passes. I would expect it to fail though, as AnimalSniffer should >>>> detect >>>> >> that usage of Java 8's KeySetView class. So I don't see that AS is >>>> executed >>>> >> actually? Or are you saying it is run but it's findings don't cause >>>> the >>>> >> build to fail? >>>> >> >>>> >> If I go back to the original approach of using AS (via git checkout >>>> >> 5f6d1~1), it behaves as I'd expect it: "./gradlew build" fails due >>>> to that >>>> >> reference from SessionFactoryImpl#iterateEntityNameResolvers(). >>>> >> >>>> >> Do you actually see the build on master fail due to that reference >>>> being >>>> >> discovered by AS? >>>> >> >>>> >> >>>> >> 2015-04-01 15:03 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> >> >>>> >>> Gunnar, it is applied. Add something that is java 8 specific and >>>> see... >>>> >>> On Apr 1, 2015 7:59 AM, "Gunnar Morling" <gunnar(a)hibernate.org&gt; >>>> wrote: >>>> >>> >>>> >>>> I saw the plug-in, Steve. But how/when is it executed? >>>> >>>> >>>> >>>> Running "./gradlew build" used to execute AnimalSniffer and would >>>> have >>>> >>>> revealed that accidental usage of KeySetView. That's not the case >>>> anymore. >>>> >>>> It would be nice if that new plug-in could be applied >>>> automatically after >>>> >>>> compileJava as it used to be the case with the Ant-based approach. >>>> >>>> >>>> >>>> >>>> >>>> 2015-04-01 13:48 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> >>>> >>>> >>>>> Increase your Gradle-fu we must young apprentice :) >>>> >>>>> >>>> >>>>> AnimalSniffer is still run. I simply converted it to be a >>>> plugin. >>>> >>>>> Check out org.hibernate.build.animalsniffer.AnimalSnifferPlugin >>>> in ORM's >>>> >>>>> /buildSrc project >>>> >>>>> >>>> >>>>> AnimalSniffer will apparently not detect this :) >>>> >>>>> >>>> >>>>> On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling < >>>> gunnar(a)hibernate.org&gt; >>>> >>>>> wrote: >>>> >>>>> >>>> >>>>>>> Currently, AnimalSniffer is in place to prevent this very >>>> category >>>> >>>>>> of error and I'm wondering why it didn't detect the "usage" of >>>> KeySetView. >>>> >>>>>> >>>> >>>>>> Looked at this a bit closer. Turns out, AnimalSniffer *will* >>>> detect >>>> >>>>>> this issue if it actually is run. The problem is that AS >>>> apparently is >>>> >>>>>> not executed by default anymore, due to the recent change to >>>> how AS is used >>>> >>>>>> [1]. >>>> >>>>>> >>>> >>>>>> Prior to that change, running AS was done automatically after >>>> the compileJava >>>> >>>>>> task and would have reported that usage of KeySetView: >>>> >>>>>> >>>> >>>>>> Undefined reference: >>>> >>>>>> >>>> java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>> >>>>>> in >>>> >>>>>> >>>> [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class >>>> >>>>>> >>>> >>>>>> Unfortunately my Gradle Foo is rather limited, so I'm not sure >>>> how to >>>> >>>>>> re-establish that behaviour with the new AS plug-in. >>>> >>>>>> >>>> >>>>>> --Gunnar >>>> >>>>>> >>>> >>>>>> [1] >>>> >>>>>> >>>> https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb6... >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> 2015-04-01 9:39 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org >>>> >: >>>> >>>>>> >>>> >>>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org >>>> >: >>>> >>>>>>> >>>> >>>>>>>> Just to clarify... I *think* that as long as we run the >>>> build with >>>> >>>>>>>> Java 8 >>>> >>>>>>>> and set the bootclasspath to 6 or 7 we should be fine. >>>> >>>>>>>> >>>> >>>>>>> >>>> >>>>>>> Yes, setting the boot classpath to 6 (or 7) makes sure you >>>> only use >>>> >>>>>>> classes present in that JDK (be it explicitly or implicitly as >>>> in the >>>> >>>>>>> ConcurrentHashMap case), because it's that class library which >>>> will be used >>>> >>>>>>> for compilation then. It is cumbersome to use though as you >>>> need to specify >>>> >>>>>>> the location of a 6 or 7 JDK which makes the build less easily >>>> portable >>>> >>>>>>> between machines. >>>> >>>>>>> >>>> >>>>>>> Currently, AnimalSniffer is in place to prevent this very >>>> category of >>>> >>>>>>> error and I'm wondering why it didn't detect the "usage" of >>>> KeySetView. It >>>> >>>>>>> really should have detected it, assuming it analyses the byte >>>> code of >>>> >>>>>>> classes. But this makes me wonder now whether it only analyses >>>> the source >>>> >>>>>>> code actually. Then it wouldn't be usable to prevent this sort >>>> of issue. >>>> >>>>>>> >>>> >>>>>>> Coding against the ConcurrentMap interface is the best way to >>>> avoid >>>> >>>>>>> the issue. But of course there is no guarantee that it happens >>>> again, >>>> >>>>>>> unless e.g. having a build on CI which uses 6 or 7 on its boot >>>> classpath. >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>>> On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole < >>>> steve(a)hibernate.org&gt; >>>> >>>>>>>> wrote: >>>> >>>>>>>> >>>> >>>>>>>>> Well the idea is to run the Gradle process with Java 8 (the >>>> build >>>> >>>>>>>> itself >>>> >>>>>>>>> is a Java process too don't forget). We pass in the older >>>> JDK >>>> >>>>>>>> specifically >>>> >>>>>>>>> to be able to set the bootclasspath for compilation and the >>>> >>>>>>>> executable for >>>> >>>>>>>>> running tests. That's the theory. >>>> >>>>>>>>> >>>> >>>>>>>>> Interestingly I developed a simplified project to test these >>>> >>>>>>>> theories: >>>> >>>>>>>>> https://github.com/sebersole/gradle-mixed-jdk And of >>>> course this >>>> >>>>>>>> all >>>> >>>>>>>>> works there. As you'd expect right? >>>> >>>>>>>>> >>>> >>>>>>>>> I think the JAXB thing comes into play here as well. Gradle >>>> does >>>> >>>>>>>> not have >>>> >>>>>>>>> any XJC support built in, so we have to make use of its Ant >>>> >>>>>>>> support to run >>>> >>>>>>>>> the XJC Ant tasks for JAXB model generation. The problem >>>> there is >>>> >>>>>>>> that, >>>> >>>>>>>>> afaik, there is no way to tell Gradle's AntBuilder to use a >>>> JDK >>>> >>>>>>>> other than >>>> >>>>>>>>> the one that launched Gradle. I think this is why we see a >>>> JAXB >>>> >>>>>>>> model >>>> >>>>>>>>> defined for Java 7, rather than Java 6, because we >>>> essentially run >>>> >>>>>>>> XJC with >>>> >>>>>>>>> Java 8. >>>> >>>>>>>>> >>>> >>>>>>>>> Anyway, this certainly makes the build more complex and we >>>> >>>>>>>> definitely have >>>> >>>>>>>>> to think through all these scenarios. In fact after Beta1, >>>> one of >>>> >>>>>>>> my todos >>>> >>>>>>>>> is to build up the build "from scratch" using that >>>> >>>>>>>> gradle-mixed-jdk project >>>> >>>>>>>>> as a basis. >>>> >>>>>>>>> >>>> >>>>>>>>> In general the plan though is to run all the tests (other >>>> than >>>> >>>>>>>>> hibernate-java8, obviously) with the "baseline JDK, whether >>>> that >>>> >>>>>>>> be Java 6 >>>> >>>>>>>>> or 7. >>>> >>>>>>>>> >>>> >>>>>>>>> On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>> >>>>>>>> sanne(a)hibernate.org&gt; >>>> >>>>>>>>> wrote: >>>> >>>>>>>>> >>>> >>>>>>>>>> There are many similar issues discussed on the Lucene >>>> developer's >>>> >>>>>>>>>> mailing list, it's an interesting read: >>>> >>>>>>>>>> - >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>> >>>>>>>>>> >>>> >>>>>>>>>> I see no alternative than to have those test jobs actually >>>> >>>>>>>> exercising >>>> >>>>>>>>>> ORM with JDK6, or maybe even compile it all with JDK6 >>>> except the >>>> >>>>>>>> Java8 >>>> >>>>>>>>>> additional module to be compiled with JDK8 ? >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> On 1 April 2015 at 00:36, Steve Ebersole < >>>> steve(a)hibernate.org&gt; >>>> >>>>>>>> wrote: >>>> >>>>>>>>>>> Ahh, seems this may be an option to work around it: >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> <quote> >>>> >>>>>>>>>>> Using the general *Map* interface in place of the concrete >>>> >>>>>>>>>>> *ConcurrentHashMap* type here side-steps the coupling to >>>> the >>>> >>>>>>>> Java 8 >>>> >>>>>>>>>> return >>>> >>>>>>>>>>> type and will allow this code to be compiled with Java 8 >>>> and >>>> >>>>>>>> run on >>>> >>>>>>>>>> Java 7. >>>> >>>>>>>>>>> </quote> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> I had missed that part. >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>> >>>>>>>> steve(a)hibernate.org&gt; >>>> >>>>>>>>>> wrote: >>>> >>>>>>>>>>> >>>> >>>>>>>>>>>> When I say "internal" here, I mean internal to java >>>> classes. >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>> >>>>>>>> steve(a)hibernate.org&gt; >>>> >>>>>>>>>>>> wrote: >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>>> Nope. It just effects any code compiled with Java 8 even >>>> >>>>>>>> though the >>>> >>>>>>>>>>>>> change is internal. The problem is the generated >>>> bytecode >>>> >>>>>>>>>> incorporates >>>> >>>>>>>>>>>>> this change. Like I said, this should be compiled with >>>> 1.6 >>>> >>>>>>>>>> compatibility, >>>> >>>>>>>>>>>>> but that is apparently not working atm. I am having a >>>> >>>>>>>> struggle >>>> >>>>>>>>>> getting a >>>> >>>>>>>>>>>>> mixed JDK build working "just right". >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>> >>>>>>>>>> paranoiabla(a)gmail.com&gt; >>>> >>>>>>>>>>>>> wrote: >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> According to this: >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* >>>> returns a >>>> >>>>>>>> Set<K> >>>> >>>>>>>>>> while >>>> >>>>>>>>>>>>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>> >>>>>>>>>>>>>> ConcurrentHashMap.KeySetView<K,V>`. >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> I think you're using some Java8 API. >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>> >>>>>>>> paranoiabla(a)gmail.com&gt;: >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>> >>>>>>>>>>>>>>> java version "1.7.0_71" >>>> >>>>>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>> >>>>>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, >>>> mixed >>>> >>>>>>>> mode) >>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>> >>>>>>>>>>>>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic >>>> #44-Ubuntu >>>> >>>>>>>> SMP Thu >>>> >>>>>>>>>> Mar >>>> >>>>>>>>>>>>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>> >>>>>>>> steve(a)hibernate.org&gt;: >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> What JRE are you trying to use? This error: >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>> >>>>>>>>>>>>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>> >>>>>>>>>>>>>>>> ConcurrentHashMap$KeySetView; >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> is indicative of an issue in cross-jre support due to >>>> a >>>> >>>>>>>> change >>>> >>>>>>>>>>>>>>>> internal to java classes. >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>> >>>>>>>>>> paranoiabla(a)gmail.com >>>> >>>>>>>>>>>>>>>>> wrote: >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> Thanks Steve, >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> I managed to migrate my configuration to the new >>>> >>>>>>>>>>>>>>>>> MetamodelImplementor. Now when I run the scema >>>> export I >>>> >>>>>>>> get a lot >>>> >>>>>>>>>> of these >>>> >>>>>>>>>>>>>>>>> warning: >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> INFO : HHH000400: Using dialect: >>>> >>>>>>>>>> org.hibernate.dialect.MySQL5Dialect >>>> >>>>>>>>>>>>>>>>> WARN : JDBC Driver reports it stores quoted >>>> identifiers >>>> >>>>>>>> in both >>>> >>>>>>>>>> mixed >>>> >>>>>>>>>>>>>>>>> and upper case >>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> >>>>>>>>>>>>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>> >>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>> >>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>> >>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> and when I run some test I get the following >>>> exception: >>>> >>>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>> >>>>>>>>>>>>>>>>> at >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>> >>>>>>>>>>>>>>>>> at >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>> >>>>>>>>>>>>>>>>> at >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>> >>>>>>>>>>>>>>>>> at >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>> >>>>>>>>>>>>>>>>> at >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>> >>>>>>>>>>>>>>>>> at >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>> >>>>>>>>>>>>>>>>> at >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>> >>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>> >>>>>>>>>>>>>>>>> at >>>> >>>>>>>>>> >>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>> >>>>>>>>>>>>>>>>> at >>>> >>>>>>>>>> >>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>> >>>>>>>>>>>>>>>>> at >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>> >>>>>>>>>>>>>>>>> at >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>> >>>>>>>>>>>>>>>>> at >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>> >>>>>>>> steve(a)hibernate.org&gt;: >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>> I am told that the bug does not affect the >>>> >>>>>>>> JBoss->Central sync >>>> >>>>>>>>>>>>>>>>>> process. So at some point the artifacts should all >>>> be >>>> >>>>>>>> available >>>> >>>>>>>>>> in Central >>>> >>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>>> >>>>>>>>>> steve(a)hibernate.org >>>> >>>>>>>>>>>>>>>>>>> wrote: >>>> >>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>> hibernate-core seems to be the only artifact that >>>> is >>>> >>>>>>>> available >>>> >>>>>>>>>> in >>>> >>>>>>>>>>>>>>>>>>> JBoss Nexus. >>>> >>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>> >>>>>>>>>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>> >>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>> So apparently the artifacts / repo issue is a >>>> Nexus >>>> >>>>>>>> bug that is >>>> >>>>>>>>>>>>>>>>>>>> effecting the JBoss repo (and therefore us)... >>>> >>>>>>>>>>>>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>> >>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>> As I pointed out in the announcement, I am >>>> managing the >>>> >>>>>>>>>> "migration >>>> >>>>>>>>>>>>>>>>>>>> guide" in source repo while I develop the Betas. >>>> See >>>> >>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>> >>>>>>>>>>>>>>>>>>>> As far are the new bootstrapping apis, see >>>> >>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>> >>>>>>>>>>>>>>>>>>>> and >>>> >>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>> >>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>> >>>>>>>>>>>>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>> >>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>> Hi guys, >>>> >>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>> I just tried the latest beta and I cannot >>>> compile my >>>> >>>>>>>> project. >>>> >>>>>>>>>>>>>>>>>>>>> With the >>>> >>>>>>>>>>>>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>> >>>>>>>>>>>>>>>>>>>>> ------- >>>> >>>>>>>>>>>>>>>>>>>>> final org.hibernate.cfg.Configuration >>>> >>>>>>>> configuration = >>>> >>>>>>>>>>>>>>>>>>>>> getHibernateConfiguration(); >>>> >>>>>>>>>>>>>>>>>>>>> configuration.buildMappings(); >>>> >>>>>>>>>>>>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>> >>>>>>>>>>>>>>>>>>>>> SchemaUpdate(configuration); >>>> >>>>>>>>>>>>>>>>>>>>> ------- >>>> >>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>> however it seems that the SchemaUpdate >>>> constructor >>>> >>>>>>>> has been >>>> >>>>>>>>>>>>>>>>>>>>> removed and now >>>> >>>>>>>>>>>>>>>>>>>>> a new one is added: >>>> >>>>>>>>>>>>>>>>>>>>> -------- >>>> >>>>>>>>>>>>>>>>>>>>> public SchemaUpdate(MetadataImplementor >>>> metadata) >>>> >>>>>>>> { >>>> >>>>>>>>>>>>>>>>>>>>> this( >>>> >>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>> >>>>>>>>>>>>>>>>>>>>> metadata ); >>>> >>>>>>>>>>>>>>>>>>>>> } >>>> >>>>>>>>>>>>>>>>>>>>> --------- >>>> >>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>> Also the configuration.buildMappings() method >>>> has been >>>> >>>>>>>>>>>>>>>>>>>>> deprecated. Where do >>>> >>>>>>>>>>>>>>>>>>>>> I get the MetadataImplementor from? Also is >>>> there any >>>> >>>>>>>>>> changelog I >>>> >>>>>>>>>>>>>>>>>>>>> can refer >>>> >>>>>>>>>>>>>>>>>>>>> to? >>>> >>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>> Thanks. >>>> >>>>>>>>>>>>>>>>>>>>> -- >>>> >>>>>>>>>>>>>>>>>>>>> Regards, Petar! >>>> >>>>>>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>> >>>>>>>>>>>>>>>>>>>>> --- >>>> >>>>>>>>>>>>>>>>>>>>> Public PGP Key at: >>>> >>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> >>>>>>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>>> 1965 >>>> >>>>>>>> 8550 C311 >>>> >>>>>>>>>>>>>>>>>>>>> 0611 >>>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>> >>>>>>>>>>>>>>>>>>>>> hibernate-dev mailing list >>>> >>>>>>>>>>>>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>> >>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> -- >>>> >>>>>>>>>>>>>>>>> Regards, Petar! >>>> >>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>> >>>>>>>>>>>>>>>>> --- >>>> >>>>>>>>>>>>>>>>> Public PGP Key at: >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> >>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>> 8550 >>>> >>>>>>>> C311 >>>> >>>>>>>>>> 0611 >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> -- >>>> >>>>>>>>>>>>>>> Regards, Petar! >>>> >>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>> >>>>>>>>>>>>>>> --- >>>> >>>>>>>>>>>>>>> Public PGP Key at: >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> >>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>> 8550 >>>> >>>>>>>> C311 0611 >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> -- >>>> >>>>>>>>>>>>>> Regards, Petar! >>>> >>>>>>>>>>>>>> Karlovo, Bulgaria. >>>> >>>>>>>>>>>>>> --- >>>> >>>>>>>>>>>>>> Public PGP Key at: >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> >>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>> 8550 >>>> >>>>>>>> C311 0611 >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>> _______________________________________________ >>>> >>>>>>>>>>> hibernate-dev mailing list >>>> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>> _______________________________________________ >>>> >>>>>>>> hibernate-dev mailing list >>>> >>>>>>>> hibernate-dev(a)lists.jboss.org >>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>> >>>> >>>> >>>> >> >>>> > _______________________________________________ >>>> > hibernate-dev mailing list >>>> > hibernate-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> >>> >>> -- >>> Regards, Petar! >>> Karlovo, Bulgaria. >>> --- >>> Public PGP Key at: >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>> >> >> > > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >

So your repo is still trying to use Hibernate 4.3.8. So I cannot reproduce this. On top of that, it uses tons of dependencies not needed for a simple bug reproducer. On Mon, Apr 6, 2015 at 5:58 AM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > So on export the tables simply are not created due to lack of > privileges. So that explains why they are not found later. > > On Mon, Apr 6, 2015 at 5:56 AM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Well there is a gigantic comment in org.hibernate.tool.schema. >> extract.internal.*legacy*.DatabaseInformationImpl that says how the tableInformationMap >> is not used, and why :) >> >> The problem is the HHH000262 log statement. That is saying that the >> tables are not found querying the database metadata. >> >> On Mon, Apr 6, 2015 at 1:34 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >> wrote: >> >>> Just a quick follow-up here: SchemaMigratorImpl:125 is calling >>> existingDatabase.getTableInformation where existingDatabase is of type >>> org.hibernate.tool.schema.extract.internal.*legacy*.DatabaseInformationImpl >>> (I have no idea why is it using the legacy one), and If I step into it I >>> can see it's using a tableInformationMap which is empty - really weird as I >>> can see before that the hbm2ddl was reporting tables were not found so I >>> was expecting it to create them: >>> >>> 2015-04-06 09:29:40,608 >>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>> [main] INFO : HHH000262: Table not found: warehouse >>> 2015-04-06 09:29:40,610 >>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>> [main] INFO : HHH000262: Table not found: widget_title_lv >>> 2015-04-06 09:29:40,614 >>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>> [main] INFO : HHH000262: Table not found: wishlist >>> 2015-04-06 09:29:40,618 >>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>> [main] INFO : HHH000262: Table not found: wishlist_entry >>> 2015-04-06 09:29:40,622 >>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>> [main] INFO : HHH000262: Table not found: working_day >>> >>> >>> I'll try to create a test that reproduces the problem >>> >>> >>> 2015-04-06 5:20 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>> >>>> I see you have a test repository reproducing the error. I will try to >>>> run from there. >>>> >>>> On Sun, Apr 5, 2015 at 3:02 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >>>> wrote: >>>> >>>>> Hi Steve, >>>>> >>>>> the test project that I created still fails with the latest SNAPSHOT >>>>> release, although the foreign keys are not created. Can you please >>>>> investigate if that is related to the same issue. The test repository is >>>>> here: >>>>> >>>>> https://github.com/paranoiabla/HHH-8805 >>>>> >>>>> >>>>> 2015-04-03 16:15 GMT+03:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >>>>> >>>>>> Steve, I think there is something fishy. >>>>>> I have created a branch with a blatant usage of a JDK 8 API in >>>>>> hibernate-core >>>>>> There is one commit above today’s master: >>>>>> >>>>>> protected EmptyInterceptor() { >>>>>> + final java.time.ZoneId id = >>>>>> java.time.ZoneId.systemDefault(); >>>>>> + System.out.println( id.getId() ); >>>>>> } >>>>>> >>>>>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer >>>>>> < >>>>>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer >>>>>> > >>>>>> >>>>>> >>>>>> And when I run ./gradlew clean build >>>>>> things do pass, i.e. Animal Sniffer is either not executed or it >>>>>> does not make the build fail. I did not see any Animal Sniffer reference in >>>>>> the console while it was running. >>>>>> >>>>>> Does it do the same for you if you clone my branch? >>>>>> >>>>>> Emmanuel >>>>>> >>>>>> PS: 18 mins here on a Mac + SSD. I guess Linux beats the crap out of >>>>>> Mac on FindBug executions ;) >>>>>> >>>>>> > On 01 Apr 2015, at 18:09, Steve Ebersole <steve(a)hibernate.org&gt; >>>>>> wrote: >>>>>> > >>>>>> > I'm not going to argue with you man. AnimalSniffer *is* run. If >>>>>> you don't >>>>>> > believe that and don't want to verify it for yourself, oh well, >>>>>> nothing I >>>>>> > can do about that... >>>>>> > >>>>>> > On Wed, Apr 1, 2015 at 8:32 AM, Gunnar Morling < >>>>>> gunnar(a)hibernate.org&gt; wrote: >>>>>> > >>>>>> >> Hum, you are not April-fooling me, right ;) >>>>>> >> >>>>>> >> There is something Java-8-specific in already: the usage of >>>>>> >> ConcurrentHashMap#keySet() (in >>>>>> >> SessionFactoryImpl#iterateEntityNameResolvers()) which - when >>>>>> compiled on >>>>>> >> Java 8 - adds a reference to the Java-8-only type KeySetView to >>>>>> the class >>>>>> >> file of SessionFactoryImpl. That's the issue pointed out by Petar >>>>>> >> originally. >>>>>> >> >>>>>> >> But when running "./gradlew build" on the current master, the >>>>>> build >>>>>> >> passes. I would expect it to fail though, as AnimalSniffer should >>>>>> detect >>>>>> >> that usage of Java 8's KeySetView class. So I don't see that AS >>>>>> is executed >>>>>> >> actually? Or are you saying it is run but it's findings don't >>>>>> cause the >>>>>> >> build to fail? >>>>>> >> >>>>>> >> If I go back to the original approach of using AS (via git >>>>>> checkout >>>>>> >> 5f6d1~1), it behaves as I'd expect it: "./gradlew build" fails >>>>>> due to that >>>>>> >> reference from SessionFactoryImpl#iterateEntityNameResolvers(). >>>>>> >> >>>>>> >> Do you actually see the build on master fail due to that >>>>>> reference being >>>>>> >> discovered by AS? >>>>>> >> >>>>>> >> >>>>>> >> 2015-04-01 15:03 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>>> >> >>>>>> >>> Gunnar, it is applied. Add something that is java 8 specific >>>>>> and see... >>>>>> >>> On Apr 1, 2015 7:59 AM, "Gunnar Morling" <gunnar(a)hibernate.org&gt; >>>>>> wrote: >>>>>> >>> >>>>>> >>>> I saw the plug-in, Steve. But how/when is it executed? >>>>>> >>>> >>>>>> >>>> Running "./gradlew build" used to execute AnimalSniffer and >>>>>> would have >>>>>> >>>> revealed that accidental usage of KeySetView. That's not the >>>>>> case anymore. >>>>>> >>>> It would be nice if that new plug-in could be applied >>>>>> automatically after >>>>>> >>>> compileJava as it used to be the case with the Ant-based >>>>>> approach. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> 2015-04-01 13:48 GMT+02:00 Steve Ebersole <steve(a)hibernate.org >>>>>> >: >>>>>> >>>> >>>>>> >>>>> Increase your Gradle-fu we must young apprentice :) >>>>>> >>>>> >>>>>> >>>>> AnimalSniffer is still run. I simply converted it to be a >>>>>> plugin. >>>>>> >>>>> Check out >>>>>> org.hibernate.build.animalsniffer.AnimalSnifferPlugin in ORM's >>>>>> >>>>> /buildSrc project >>>>>> >>>>> >>>>>> >>>>> AnimalSniffer will apparently not detect this :) >>>>>> >>>>> >>>>>> >>>>> On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling < >>>>>> gunnar(a)hibernate.org&gt; >>>>>> >>>>> wrote: >>>>>> >>>>> >>>>>> >>>>>>> Currently, AnimalSniffer is in place to prevent this very >>>>>> category >>>>>> >>>>>> of error and I'm wondering why it didn't detect the "usage" >>>>>> of KeySetView. >>>>>> >>>>>> >>>>>> >>>>>> Looked at this a bit closer. Turns out, AnimalSniffer *will* >>>>>> detect >>>>>> >>>>>> this issue if it actually is run. The problem is that AS >>>>>> apparently is >>>>>> >>>>>> not executed by default anymore, due to the recent change to >>>>>> how AS is used >>>>>> >>>>>> [1]. >>>>>> >>>>>> >>>>>> >>>>>> Prior to that change, running AS was done automatically after >>>>>> the compileJava >>>>>> >>>>>> task and would have reported that usage of KeySetView: >>>>>> >>>>>> >>>>>> >>>>>> Undefined reference: >>>>>> >>>>>> >>>>>> java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>> >>>>>> in >>>>>> >>>>>> >>>>>> [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class >>>>>> >>>>>> >>>>>> >>>>>> Unfortunately my Gradle Foo is rather limited, so I'm not >>>>>> sure how to >>>>>> >>>>>> re-establish that behaviour with the new AS plug-in. >>>>>> >>>>>> >>>>>> >>>>>> --Gunnar >>>>>> >>>>>> >>>>>> >>>>>> [1] >>>>>> >>>>>> >>>>>> https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb6... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2015-04-01 9:39 GMT+02:00 Gunnar Morling < >>>>>> gunnar(a)hibernate.org&gt;: >>>>>> >>>>>> >>>>>> >>>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole < >>>>>> steve(a)hibernate.org&gt;: >>>>>> >>>>>>> >>>>>> >>>>>>>> Just to clarify... I *think* that as long as we run the >>>>>> build with >>>>>> >>>>>>>> Java 8 >>>>>> >>>>>>>> and set the bootclasspath to 6 or 7 we should be fine. >>>>>> >>>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> Yes, setting the boot classpath to 6 (or 7) makes sure you >>>>>> only use >>>>>> >>>>>>> classes present in that JDK (be it explicitly or implicitly >>>>>> as in the >>>>>> >>>>>>> ConcurrentHashMap case), because it's that class library >>>>>> which will be used >>>>>> >>>>>>> for compilation then. It is cumbersome to use though as you >>>>>> need to specify >>>>>> >>>>>>> the location of a 6 or 7 JDK which makes the build less >>>>>> easily portable >>>>>> >>>>>>> between machines. >>>>>> >>>>>>> >>>>>> >>>>>>> Currently, AnimalSniffer is in place to prevent this very >>>>>> category of >>>>>> >>>>>>> error and I'm wondering why it didn't detect the "usage" of >>>>>> KeySetView. It >>>>>> >>>>>>> really should have detected it, assuming it analyses the >>>>>> byte code of >>>>>> >>>>>>> classes. But this makes me wonder now whether it only >>>>>> analyses the source >>>>>> >>>>>>> code actually. Then it wouldn't be usable to prevent this >>>>>> sort of issue. >>>>>> >>>>>>> >>>>>> >>>>>>> Coding against the ConcurrentMap interface is the best way >>>>>> to avoid >>>>>> >>>>>>> the issue. But of course there is no guarantee that it >>>>>> happens again, >>>>>> >>>>>>> unless e.g. having a build on CI which uses 6 or 7 on its >>>>>> boot classpath. >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>>> On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole < >>>>>> steve(a)hibernate.org&gt; >>>>>> >>>>>>>> wrote: >>>>>> >>>>>>>> >>>>>> >>>>>>>>> Well the idea is to run the Gradle process with Java 8 >>>>>> (the build >>>>>> >>>>>>>> itself >>>>>> >>>>>>>>> is a Java process too don't forget). We pass in the older >>>>>> JDK >>>>>> >>>>>>>> specifically >>>>>> >>>>>>>>> to be able to set the bootclasspath for compilation and the >>>>>> >>>>>>>> executable for >>>>>> >>>>>>>>> running tests. That's the theory. >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> Interestingly I developed a simplified project to test >>>>>> these >>>>>> >>>>>>>> theories: >>>>>> >>>>>>>>> https://github.com/sebersole/gradle-mixed-jdk And of >>>>>> course this >>>>>> >>>>>>>> all >>>>>> >>>>>>>>> works there. As you'd expect right? >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> I think the JAXB thing comes into play here as well. >>>>>> Gradle does >>>>>> >>>>>>>> not have >>>>>> >>>>>>>>> any XJC support built in, so we have to make use of its Ant >>>>>> >>>>>>>> support to run >>>>>> >>>>>>>>> the XJC Ant tasks for JAXB model generation. The problem >>>>>> there is >>>>>> >>>>>>>> that, >>>>>> >>>>>>>>> afaik, there is no way to tell Gradle's AntBuilder to use >>>>>> a JDK >>>>>> >>>>>>>> other than >>>>>> >>>>>>>>> the one that launched Gradle. I think this is why we see >>>>>> a JAXB >>>>>> >>>>>>>> model >>>>>> >>>>>>>>> defined for Java 7, rather than Java 6, because we >>>>>> essentially run >>>>>> >>>>>>>> XJC with >>>>>> >>>>>>>>> Java 8. >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> Anyway, this certainly makes the build more complex and we >>>>>> >>>>>>>> definitely have >>>>>> >>>>>>>>> to think through all these scenarios. In fact after >>>>>> Beta1, one of >>>>>> >>>>>>>> my todos >>>>>> >>>>>>>>> is to build up the build "from scratch" using that >>>>>> >>>>>>>> gradle-mixed-jdk project >>>>>> >>>>>>>>> as a basis. >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> In general the plan though is to run all the tests (other >>>>>> than >>>>>> >>>>>>>>> hibernate-java8, obviously) with the "baseline JDK, >>>>>> whether that >>>>>> >>>>>>>> be Java 6 >>>>>> >>>>>>>>> or 7. >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>>>> >>>>>>>> sanne(a)hibernate.org&gt; >>>>>> >>>>>>>>> wrote: >>>>>> >>>>>>>>> >>>>>> >>>>>>>>>> There are many similar issues discussed on the Lucene >>>>>> developer's >>>>>> >>>>>>>>>> mailing list, it's an interesting read: >>>>>> >>>>>>>>>> - >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> I see no alternative than to have those test jobs actually >>>>>> >>>>>>>> exercising >>>>>> >>>>>>>>>> ORM with JDK6, or maybe even compile it all with JDK6 >>>>>> except the >>>>>> >>>>>>>> Java8 >>>>>> >>>>>>>>>> additional module to be compiled with JDK8 ? >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> On 1 April 2015 at 00:36, Steve Ebersole < >>>>>> steve(a)hibernate.org&gt; >>>>>> >>>>>>>> wrote: >>>>>> >>>>>>>>>>> Ahh, seems this may be an option to work around it: >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> <quote> >>>>>> >>>>>>>>>>> Using the general *Map* interface in place of the >>>>>> concrete >>>>>> >>>>>>>>>>> *ConcurrentHashMap* type here side-steps the coupling to >>>>>> the >>>>>> >>>>>>>> Java 8 >>>>>> >>>>>>>>>> return >>>>>> >>>>>>>>>>> type and will allow this code to be compiled with Java 8 >>>>>> and >>>>>> >>>>>>>> run on >>>>>> >>>>>>>>>> Java 7. >>>>>> >>>>>>>>>>> </quote> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> I had missed that part. >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>>>> >>>>>>>> steve(a)hibernate.org&gt; >>>>>> >>>>>>>>>> wrote: >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>>> When I say "internal" here, I mean internal to java >>>>>> classes. >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>>>> >>>>>>>> steve(a)hibernate.org&gt; >>>>>> >>>>>>>>>>>> wrote: >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> Nope. It just effects any code compiled with Java 8 >>>>>> even >>>>>> >>>>>>>> though the >>>>>> >>>>>>>>>>>>> change is internal. The problem is the generated >>>>>> bytecode >>>>>> >>>>>>>>>> incorporates >>>>>> >>>>>>>>>>>>> this change. Like I said, this should be compiled >>>>>> with 1.6 >>>>>> >>>>>>>>>> compatibility, >>>>>> >>>>>>>>>>>>> but that is apparently not working atm. I am having a >>>>>> >>>>>>>> struggle >>>>>> >>>>>>>>>> getting a >>>>>> >>>>>>>>>>>>> mixed JDK build working "just right". >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>>>> >>>>>>>>>> paranoiabla(a)gmail.com&gt; >>>>>> >>>>>>>>>>>>> wrote: >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> According to this: >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* >>>>>> returns a >>>>>> >>>>>>>> Set<K> >>>>>> >>>>>>>>>> while >>>>>> >>>>>>>>>>>>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>>>> >>>>>>>>>>>>>> ConcurrentHashMap.KeySetView<K,V>`. >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> I think you're using some Java8 API. >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>>>> >>>>>>>> paranoiabla(a)gmail.com&gt;: >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>>>> >>>>>>>>>>>>>>> java version "1.7.0_71" >>>>>> >>>>>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>>>> >>>>>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, >>>>>> mixed >>>>>> >>>>>>>> mode) >>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>>>> >>>>>>>>>>>>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic >>>>>> #44-Ubuntu >>>>>> >>>>>>>> SMP Thu >>>>>> >>>>>>>>>> Mar >>>>>> >>>>>>>>>>>>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>>>> >>>>>>>> steve(a)hibernate.org&gt;: >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> What JRE are you trying to use? This error: >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>>>> >>>>>>>>>>>>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>>>> >>>>>>>>>>>>>>>> ConcurrentHashMap$KeySetView; >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> is indicative of an issue in cross-jre support due >>>>>> to a >>>>>> >>>>>>>> change >>>>>> >>>>>>>>>>>>>>>> internal to java classes. >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>>>> >>>>>>>>>> paranoiabla(a)gmail.com >>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> Thanks Steve, >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> I managed to migrate my configuration to the new >>>>>> >>>>>>>>>>>>>>>>> MetamodelImplementor. Now when I run the scema >>>>>> export I >>>>>> >>>>>>>> get a lot >>>>>> >>>>>>>>>> of these >>>>>> >>>>>>>>>>>>>>>>> warning: >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> INFO : HHH000400: Using dialect: >>>>>> >>>>>>>>>> org.hibernate.dialect.MySQL5Dialect >>>>>> >>>>>>>>>>>>>>>>> WARN : JDBC Driver reports it stores quoted >>>>>> identifiers >>>>>> >>>>>>>> in both >>>>>> >>>>>>>>>> mixed >>>>>> >>>>>>>>>>>>>>>>> and upper case >>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> >>>>>>>>>>>>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>> >>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>> >>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>> >>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> and when I run some test I get the following >>>>>> exception: >>>>>> >>>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>> >>>>>>>>>>>>>>>>> at >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>>>> >>>>>>>>>>>>>>>>> at >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>>>> >>>>>>>>>>>>>>>>> at >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>>>> >>>>>>>>>>>>>>>>> at >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>>>> >>>>>>>>>>>>>>>>> at >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>>>> >>>>>>>>>>>>>>>>> at >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>>>> >>>>>>>>>>>>>>>>> at >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>> >>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>>>> >>>>>>>>>>>>>>>>> at >>>>>> >>>>>>>>>> >>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>>>> >>>>>>>>>>>>>>>>> at >>>>>> >>>>>>>>>> >>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>>>> >>>>>>>>>>>>>>>>> at >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>>>> >>>>>>>>>>>>>>>>> at >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>>>> >>>>>>>>>>>>>>>>> at >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>>>> >>>>>>>> steve(a)hibernate.org&gt;: >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> I am told that the bug does not affect the >>>>>> >>>>>>>> JBoss->Central sync >>>>>> >>>>>>>>>>>>>>>>>> process. So at some point the artifacts should >>>>>> all be >>>>>> >>>>>>>> available >>>>>> >>>>>>>>>> in Central >>>>>> >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>>>>> >>>>>>>>>> steve(a)hibernate.org >>>>>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>> >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> hibernate-core seems to be the only artifact >>>>>> that is >>>>>> >>>>>>>> available >>>>>> >>>>>>>>>> in >>>>>> >>>>>>>>>>>>>>>>>>> JBoss Nexus. >>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>>>> >>>>>>>>>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>>> So apparently the artifacts / repo issue is a >>>>>> Nexus >>>>>> >>>>>>>> bug that is >>>>>> >>>>>>>>>>>>>>>>>>>> effecting the JBoss repo (and therefore us)... >>>>>> >>>>>>>>>>>>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>>> As I pointed out in the announcement, I am >>>>>> managing the >>>>>> >>>>>>>>>> "migration >>>>>> >>>>>>>>>>>>>>>>>>>> guide" in source repo while I develop the >>>>>> Betas. See >>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>>> >>>>>>>>>>>>>>>>>>>> As far are the new bootstrapping apis, see >>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>>> >>>>>>>>>>>>>>>>>>>> and >>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev >>>>>> < >>>>>> >>>>>>>>>>>>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>>>> Hi guys, >>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>>>> I just tried the latest beta and I cannot >>>>>> compile my >>>>>> >>>>>>>> project. >>>>>> >>>>>>>>>>>>>>>>>>>>> With the >>>>>> >>>>>>>>>>>>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>>>> >>>>>>>>>>>>>>>>>>>>> ------- >>>>>> >>>>>>>>>>>>>>>>>>>>> final org.hibernate.cfg.Configuration >>>>>> >>>>>>>> configuration = >>>>>> >>>>>>>>>>>>>>>>>>>>> getHibernateConfiguration(); >>>>>> >>>>>>>>>>>>>>>>>>>>> configuration.buildMappings(); >>>>>> >>>>>>>>>>>>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>>>> >>>>>>>>>>>>>>>>>>>>> SchemaUpdate(configuration); >>>>>> >>>>>>>>>>>>>>>>>>>>> ------- >>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>>>> however it seems that the SchemaUpdate >>>>>> constructor >>>>>> >>>>>>>> has been >>>>>> >>>>>>>>>>>>>>>>>>>>> removed and now >>>>>> >>>>>>>>>>>>>>>>>>>>> a new one is added: >>>>>> >>>>>>>>>>>>>>>>>>>>> -------- >>>>>> >>>>>>>>>>>>>>>>>>>>> public SchemaUpdate(MetadataImplementor >>>>>> metadata) >>>>>> >>>>>>>> { >>>>>> >>>>>>>>>>>>>>>>>>>>> this( >>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>> >>>>>>>>>>>>>>>>>>>>> metadata ); >>>>>> >>>>>>>>>>>>>>>>>>>>> } >>>>>> >>>>>>>>>>>>>>>>>>>>> --------- >>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>>>> Also the configuration.buildMappings() method >>>>>> has been >>>>>> >>>>>>>>>>>>>>>>>>>>> deprecated. Where do >>>>>> >>>>>>>>>>>>>>>>>>>>> I get the MetadataImplementor from? Also is >>>>>> there any >>>>>> >>>>>>>>>> changelog I >>>>>> >>>>>>>>>>>>>>>>>>>>> can refer >>>>>> >>>>>>>>>>>>>>>>>>>>> to? >>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>> >>>>>>>>>>>>>>>>>>>>> Regards, Petar! >>>>>> >>>>>>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>> >>>>>>>>>>>>>>>>>>>>> --- >>>>>> >>>>>>>>>>>>>>>>>>>>> Public PGP Key at: >>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> >>>>>>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF >>>>>> 55A5 1965 >>>>>> >>>>>>>> 8550 C311 >>>>>> >>>>>>>>>>>>>>>>>>>>> 0611 >>>>>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>> >>>>>>>>>>>>>>>>>>>>> hibernate-dev mailing list >>>>>> >>>>>>>>>>>>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> -- >>>>>> >>>>>>>>>>>>>>>>> Regards, Petar! >>>>>> >>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>> >>>>>>>>>>>>>>>>> --- >>>>>> >>>>>>>>>>>>>>>>> Public PGP Key at: >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> >>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>>>>> 1965 8550 >>>>>> >>>>>>>> C311 >>>>>> >>>>>>>>>> 0611 >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> -- >>>>>> >>>>>>>>>>>>>>> Regards, Petar! >>>>>> >>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>> >>>>>>>>>>>>>>> --- >>>>>> >>>>>>>>>>>>>>> Public PGP Key at: >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> >>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>>>> 8550 >>>>>> >>>>>>>> C311 0611 >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> -- >>>>>> >>>>>>>>>>>>>> Regards, Petar! >>>>>> >>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>> >>>>>>>>>>>>>> --- >>>>>> >>>>>>>>>>>>>> Public PGP Key at: >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>> >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> >>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>>>> 8550 >>>>>> >>>>>>>> C311 0611 >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>> _______________________________________________ >>>>>> >>>>>>>>>>> hibernate-dev mailing list >>>>>> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>> _______________________________________________ >>>>>> >>>>>>>> hibernate-dev mailing list >>>>>> >>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>> >>>>>> >> >>>>>> > _______________________________________________ >>>>>> > hibernate-dev mailing list >>>>>> > hibernate-dev(a)lists.jboss.org >>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, Petar! >>>>> Karlovo, Bulgaria. >>>>> --- >>>>> Public PGP Key at: >>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>> >>>> >>>> >>> >>> >>> -- >>> Regards, Petar! >>> Karlovo, Bulgaria. >>> --- >>> Public PGP Key at: >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>> >> >> >

Because compiling told me that none of the 5.0 bootstrapping packages/classes could be found. Anyway, I am working on simplifying your demo thing into something simpler. On Mon, Apr 6, 2015 at 6:33 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; wrote: > Hmm.. here's the result of mvn dependency:tree -Dverbose > -Dincludes=org.hibernate > > [INFO] --- maven-dependency-plugin:2.9:tree (default-cli) @ HHH-8805 --- > [WARNING] Using Maven 2 dependency tree to get verbose output, which may > be inconsistent with actual Maven 3 resolution > [INFO] org.test:HHH-8805:jar:0.0.1-SNAPSHOT > [INFO] \- > org.springframework.boot:spring-boot-starter-data-jpa:jar:1.2.3.RELEASE:compile > [INFO] \- > org.hibernate:hibernate-entitymanager:jar:5.0.0-SNAPSHOT:compile (version > managed from 4.3.8.Final) > [INFO] \- org.hibernate:hibernate-core:jar:5.0.0-SNAPSHOT:compile > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > > How do you know it's using 4.3.8? > > 2015-04-06 14:25 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> So your repo is still trying to use Hibernate 4.3.8. So I cannot >> reproduce this. >> >> On top of that, it uses tons of dependencies not needed for a simple bug >> reproducer. >> >> On Mon, Apr 6, 2015 at 5:58 AM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> So on export the tables simply are not created due to lack of >>> privileges. So that explains why they are not found later. >>> >>> On Mon, Apr 6, 2015 at 5:56 AM, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> Well there is a gigantic comment in org.hibernate.tool.schema. >>>> extract.internal.*legacy*.DatabaseInformationImpl that says how the tableInformationMap >>>> is not used, and why :) >>>> >>>> The problem is the HHH000262 log statement. That is saying that the >>>> tables are not found querying the database metadata. >>>> >>>> On Mon, Apr 6, 2015 at 1:34 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >>>> wrote: >>>> >>>>> Just a quick follow-up here: SchemaMigratorImpl:125 is calling >>>>> existingDatabase.getTableInformation where existingDatabase is of type >>>>> org.hibernate.tool.schema.extract.internal.*legacy*.DatabaseInformationImpl >>>>> (I have no idea why is it using the legacy one), and If I step into it I >>>>> can see it's using a tableInformationMap which is empty - really weird as I >>>>> can see before that the hbm2ddl was reporting tables were not found so I >>>>> was expecting it to create them: >>>>> >>>>> 2015-04-06 09:29:40,608 >>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>> [main] INFO : HHH000262: Table not found: warehouse >>>>> 2015-04-06 09:29:40,610 >>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>> [main] INFO : HHH000262: Table not found: widget_title_lv >>>>> 2015-04-06 09:29:40,614 >>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>> [main] INFO : HHH000262: Table not found: wishlist >>>>> 2015-04-06 09:29:40,618 >>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>> [main] INFO : HHH000262: Table not found: wishlist_entry >>>>> 2015-04-06 09:29:40,622 >>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>> [main] INFO : HHH000262: Table not found: working_day >>>>> >>>>> >>>>> I'll try to create a test that reproduces the problem >>>>> >>>>> >>>>> 2015-04-06 5:20 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>> >>>>>> I see you have a test repository reproducing the error. I will try >>>>>> to run from there. >>>>>> >>>>>> On Sun, Apr 5, 2015 at 3:02 AM, Petar Tahchiev < >>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>> >>>>>>> Hi Steve, >>>>>>> >>>>>>> the test project that I created still fails with the latest >>>>>>> SNAPSHOT release, although the foreign keys are not created. Can you please >>>>>>> investigate if that is related to the same issue. The test repository is >>>>>>> here: >>>>>>> >>>>>>> https://github.com/paranoiabla/HHH-8805 >>>>>>> >>>>>>> >>>>>>> 2015-04-03 16:15 GMT+03:00 Emmanuel Bernard <emmanuel(a)hibernate.org >>>>>>> >: >>>>>>> >>>>>>>> Steve, I think there is something fishy. >>>>>>>> I have created a branch with a blatant usage of a JDK 8 API in >>>>>>>> hibernate-core >>>>>>>> There is one commit above today’s master: >>>>>>>> >>>>>>>> protected EmptyInterceptor() { >>>>>>>> + final java.time.ZoneId id = >>>>>>>> java.time.ZoneId.systemDefault(); >>>>>>>> + System.out.println( id.getId() ); >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer >>>>>>>> < >>>>>>>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> And when I run ./gradlew clean build >>>>>>>> things do pass, i.e. Animal Sniffer is either not executed or it >>>>>>>> does not make the build fail. I did not see any Animal Sniffer reference in >>>>>>>> the console while it was running. >>>>>>>> >>>>>>>> Does it do the same for you if you clone my branch? >>>>>>>> >>>>>>>> Emmanuel >>>>>>>> >>>>>>>> PS: 18 mins here on a Mac + SSD. I guess Linux beats the crap out >>>>>>>> of Mac on FindBug executions ;) >>>>>>>> >>>>>>>> > On 01 Apr 2015, at 18:09, Steve Ebersole <steve(a)hibernate.org&gt; >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > I'm not going to argue with you man. AnimalSniffer *is* run. >>>>>>>> If you don't >>>>>>>> > believe that and don't want to verify it for yourself, oh well, >>>>>>>> nothing I >>>>>>>> > can do about that... >>>>>>>> > >>>>>>>> > On Wed, Apr 1, 2015 at 8:32 AM, Gunnar Morling < >>>>>>>> gunnar(a)hibernate.org&gt; wrote: >>>>>>>> > >>>>>>>> >> Hum, you are not April-fooling me, right ;) >>>>>>>> >> >>>>>>>> >> There is something Java-8-specific in already: the usage of >>>>>>>> >> ConcurrentHashMap#keySet() (in >>>>>>>> >> SessionFactoryImpl#iterateEntityNameResolvers()) which - when >>>>>>>> compiled on >>>>>>>> >> Java 8 - adds a reference to the Java-8-only type KeySetView to >>>>>>>> the class >>>>>>>> >> file of SessionFactoryImpl. That's the issue pointed out by >>>>>>>> Petar >>>>>>>> >> originally. >>>>>>>> >> >>>>>>>> >> But when running "./gradlew build" on the current master, the >>>>>>>> build >>>>>>>> >> passes. I would expect it to fail though, as AnimalSniffer >>>>>>>> should detect >>>>>>>> >> that usage of Java 8's KeySetView class. So I don't see that AS >>>>>>>> is executed >>>>>>>> >> actually? Or are you saying it is run but it's findings don't >>>>>>>> cause the >>>>>>>> >> build to fail? >>>>>>>> >> >>>>>>>> >> If I go back to the original approach of using AS (via git >>>>>>>> checkout >>>>>>>> >> 5f6d1~1), it behaves as I'd expect it: "./gradlew build" fails >>>>>>>> due to that >>>>>>>> >> reference from SessionFactoryImpl#iterateEntityNameResolvers(). >>>>>>>> >> >>>>>>>> >> Do you actually see the build on master fail due to that >>>>>>>> reference being >>>>>>>> >> discovered by AS? >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> 2015-04-01 15:03 GMT+02:00 Steve Ebersole <steve(a)hibernate.org >>>>>>>> >: >>>>>>>> >> >>>>>>>> >>> Gunnar, it is applied. Add something that is java 8 specific >>>>>>>> and see... >>>>>>>> >>> On Apr 1, 2015 7:59 AM, "Gunnar Morling" <gunnar(a)hibernate.org&gt; >>>>>>>> wrote: >>>>>>>> >>> >>>>>>>> >>>> I saw the plug-in, Steve. But how/when is it executed? >>>>>>>> >>>> >>>>>>>> >>>> Running "./gradlew build" used to execute AnimalSniffer and >>>>>>>> would have >>>>>>>> >>>> revealed that accidental usage of KeySetView. That's not the >>>>>>>> case anymore. >>>>>>>> >>>> It would be nice if that new plug-in could be applied >>>>>>>> automatically after >>>>>>>> >>>> compileJava as it used to be the case with the Ant-based >>>>>>>> approach. >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> 2015-04-01 13:48 GMT+02:00 Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>> >>>> >>>>>>>> >>>>> Increase your Gradle-fu we must young apprentice :) >>>>>>>> >>>>> >>>>>>>> >>>>> AnimalSniffer is still run. I simply converted it to be a >>>>>>>> plugin. >>>>>>>> >>>>> Check out >>>>>>>> org.hibernate.build.animalsniffer.AnimalSnifferPlugin in ORM's >>>>>>>> >>>>> /buildSrc project >>>>>>>> >>>>> >>>>>>>> >>>>> AnimalSniffer will apparently not detect this :) >>>>>>>> >>>>> >>>>>>>> >>>>> On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling < >>>>>>>> gunnar(a)hibernate.org&gt; >>>>>>>> >>>>> wrote: >>>>>>>> >>>>> >>>>>>>> >>>>>>> Currently, AnimalSniffer is in place to prevent this very >>>>>>>> category >>>>>>>> >>>>>> of error and I'm wondering why it didn't detect the "usage" >>>>>>>> of KeySetView. >>>>>>>> >>>>>> >>>>>>>> >>>>>> Looked at this a bit closer. Turns out, AnimalSniffer >>>>>>>> *will* detect >>>>>>>> >>>>>> this issue if it actually is run. The problem is that AS >>>>>>>> apparently is >>>>>>>> >>>>>> not executed by default anymore, due to the recent change >>>>>>>> to how AS is used >>>>>>>> >>>>>> [1]. >>>>>>>> >>>>>> >>>>>>>> >>>>>> Prior to that change, running AS was done automatically >>>>>>>> after the compileJava >>>>>>>> >>>>>> task and would have reported that usage of KeySetView: >>>>>>>> >>>>>> >>>>>>>> >>>>>> Undefined reference: >>>>>>>> >>>>>> >>>>>>>> java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>>>> >>>>>> in >>>>>>>> >>>>>> >>>>>>>> [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class >>>>>>>> >>>>>> >>>>>>>> >>>>>> Unfortunately my Gradle Foo is rather limited, so I'm not >>>>>>>> sure how to >>>>>>>> >>>>>> re-establish that behaviour with the new AS plug-in. >>>>>>>> >>>>>> >>>>>>>> >>>>>> --Gunnar >>>>>>>> >>>>>> >>>>>>>> >>>>>> [1] >>>>>>>> >>>>>> >>>>>>>> https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb6... >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> 2015-04-01 9:39 GMT+02:00 Gunnar Morling < >>>>>>>> gunnar(a)hibernate.org&gt;: >>>>>>>> >>>>>> >>>>>>>> >>>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Just to clarify... I *think* that as long as we run the >>>>>>>> build with >>>>>>>> >>>>>>>> Java 8 >>>>>>>> >>>>>>>> and set the bootclasspath to 6 or 7 we should be fine. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Yes, setting the boot classpath to 6 (or 7) makes sure you >>>>>>>> only use >>>>>>>> >>>>>>> classes present in that JDK (be it explicitly or >>>>>>>> implicitly as in the >>>>>>>> >>>>>>> ConcurrentHashMap case), because it's that class library >>>>>>>> which will be used >>>>>>>> >>>>>>> for compilation then. It is cumbersome to use though as >>>>>>>> you need to specify >>>>>>>> >>>>>>> the location of a 6 or 7 JDK which makes the build less >>>>>>>> easily portable >>>>>>>> >>>>>>> between machines. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Currently, AnimalSniffer is in place to prevent this very >>>>>>>> category of >>>>>>>> >>>>>>> error and I'm wondering why it didn't detect the "usage" >>>>>>>> of KeySetView. It >>>>>>>> >>>>>>> really should have detected it, assuming it analyses the >>>>>>>> byte code of >>>>>>>> >>>>>>> classes. But this makes me wonder now whether it only >>>>>>>> analyses the source >>>>>>>> >>>>>>> code actually. Then it wouldn't be usable to prevent this >>>>>>>> sort of issue. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Coding against the ConcurrentMap interface is the best way >>>>>>>> to avoid >>>>>>>> >>>>>>> the issue. But of course there is no guarantee that it >>>>>>>> happens again, >>>>>>>> >>>>>>> unless e.g. having a build on CI which uses 6 or 7 on its >>>>>>>> boot classpath. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt; >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Well the idea is to run the Gradle process with Java 8 >>>>>>>> (the build >>>>>>>> >>>>>>>> itself >>>>>>>> >>>>>>>>> is a Java process too don't forget). We pass in the >>>>>>>> older JDK >>>>>>>> >>>>>>>> specifically >>>>>>>> >>>>>>>>> to be able to set the bootclasspath for compilation and >>>>>>>> the >>>>>>>> >>>>>>>> executable for >>>>>>>> >>>>>>>>> running tests. That's the theory. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> Interestingly I developed a simplified project to test >>>>>>>> these >>>>>>>> >>>>>>>> theories: >>>>>>>> >>>>>>>>> https://github.com/sebersole/gradle-mixed-jdk And of >>>>>>>> course this >>>>>>>> >>>>>>>> all >>>>>>>> >>>>>>>>> works there. As you'd expect right? >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> I think the JAXB thing comes into play here as well. >>>>>>>> Gradle does >>>>>>>> >>>>>>>> not have >>>>>>>> >>>>>>>>> any XJC support built in, so we have to make use of its >>>>>>>> Ant >>>>>>>> >>>>>>>> support to run >>>>>>>> >>>>>>>>> the XJC Ant tasks for JAXB model generation. The >>>>>>>> problem there is >>>>>>>> >>>>>>>> that, >>>>>>>> >>>>>>>>> afaik, there is no way to tell Gradle's AntBuilder to >>>>>>>> use a JDK >>>>>>>> >>>>>>>> other than >>>>>>>> >>>>>>>>> the one that launched Gradle. I think this is why we >>>>>>>> see a JAXB >>>>>>>> >>>>>>>> model >>>>>>>> >>>>>>>>> defined for Java 7, rather than Java 6, because we >>>>>>>> essentially run >>>>>>>> >>>>>>>> XJC with >>>>>>>> >>>>>>>>> Java 8. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> Anyway, this certainly makes the build more complex and >>>>>>>> we >>>>>>>> >>>>>>>> definitely have >>>>>>>> >>>>>>>>> to think through all these scenarios. In fact after >>>>>>>> Beta1, one of >>>>>>>> >>>>>>>> my todos >>>>>>>> >>>>>>>>> is to build up the build "from scratch" using that >>>>>>>> >>>>>>>> gradle-mixed-jdk project >>>>>>>> >>>>>>>>> as a basis. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> In general the plan though is to run all the tests >>>>>>>> (other than >>>>>>>> >>>>>>>>> hibernate-java8, obviously) with the "baseline JDK, >>>>>>>> whether that >>>>>>>> >>>>>>>> be Java 6 >>>>>>>> >>>>>>>>> or 7. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>>>>>> >>>>>>>> sanne(a)hibernate.org&gt; >>>>>>>> >>>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>>> There are many similar issues discussed on the Lucene >>>>>>>> developer's >>>>>>>> >>>>>>>>>> mailing list, it's an interesting read: >>>>>>>> >>>>>>>>>> - >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> I see no alternative than to have those test jobs >>>>>>>> actually >>>>>>>> >>>>>>>> exercising >>>>>>>> >>>>>>>>>> ORM with JDK6, or maybe even compile it all with JDK6 >>>>>>>> except the >>>>>>>> >>>>>>>> Java8 >>>>>>>> >>>>>>>>>> additional module to be compiled with JDK8 ? >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> On 1 April 2015 at 00:36, Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt; >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>>> Ahh, seems this may be an option to work around it: >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> <quote> >>>>>>>> >>>>>>>>>>> Using the general *Map* interface in place of the >>>>>>>> concrete >>>>>>>> >>>>>>>>>>> *ConcurrentHashMap* type here side-steps the coupling >>>>>>>> to the >>>>>>>> >>>>>>>> Java 8 >>>>>>>> >>>>>>>>>> return >>>>>>>> >>>>>>>>>>> type and will allow this code to be compiled with Java >>>>>>>> 8 and >>>>>>>> >>>>>>>> run on >>>>>>>> >>>>>>>>>> Java 7. >>>>>>>> >>>>>>>>>>> </quote> >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> I had missed that part. >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>>>>>> >>>>>>>> steve(a)hibernate.org&gt; >>>>>>>> >>>>>>>>>> wrote: >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> When I say "internal" here, I mean internal to java >>>>>>>> classes. >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>>>>>> >>>>>>>> steve(a)hibernate.org&gt; >>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Nope. It just effects any code compiled with Java 8 >>>>>>>> even >>>>>>>> >>>>>>>> though the >>>>>>>> >>>>>>>>>>>>> change is internal. The problem is the generated >>>>>>>> bytecode >>>>>>>> >>>>>>>>>> incorporates >>>>>>>> >>>>>>>>>>>>> this change. Like I said, this should be compiled >>>>>>>> with 1.6 >>>>>>>> >>>>>>>>>> compatibility, >>>>>>>> >>>>>>>>>>>>> but that is apparently not working atm. I am having >>>>>>>> a >>>>>>>> >>>>>>>> struggle >>>>>>>> >>>>>>>>>> getting a >>>>>>>> >>>>>>>>>>>>> mixed JDK build working "just right". >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>>>>>> >>>>>>>>>> paranoiabla(a)gmail.com&gt; >>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> According to this: >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* >>>>>>>> returns a >>>>>>>> >>>>>>>> Set<K> >>>>>>>> >>>>>>>>>> while >>>>>>>> >>>>>>>>>>>>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>>>>>> >>>>>>>>>>>>>> ConcurrentHashMap.KeySetView<K,V>`. >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> I think you're using some Java8 API. >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>>>>>> >>>>>>>> paranoiabla(a)gmail.com&gt;: >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>>>>>> >>>>>>>>>>>>>>> java version "1.7.0_71" >>>>>>>> >>>>>>>>>>>>>>> Java(TM) SE Runtime Environment (build >>>>>>>> 1.7.0_71-b14) >>>>>>>> >>>>>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>>>> 24.71-b01, mixed >>>>>>>> >>>>>>>> mode) >>>>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>>>>>> >>>>>>>>>>>>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic >>>>>>>> #44-Ubuntu >>>>>>>> >>>>>>>> SMP Thu >>>>>>>> >>>>>>>>>> Mar >>>>>>>> >>>>>>>>>>>>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>>>>>> >>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> What JRE are you trying to use? This error: >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>>>>>> >>>>>>>>>>>>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>>>>>> >>>>>>>>>>>>>>>> ConcurrentHashMap$KeySetView; >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> is indicative of an issue in cross-jre support >>>>>>>> due to a >>>>>>>> >>>>>>>> change >>>>>>>> >>>>>>>>>>>>>>>> internal to java classes. >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>>>>>> >>>>>>>>>> paranoiabla(a)gmail.com >>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> Thanks Steve, >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> I managed to migrate my configuration to the new >>>>>>>> >>>>>>>>>>>>>>>>> MetamodelImplementor. Now when I run the scema >>>>>>>> export I >>>>>>>> >>>>>>>> get a lot >>>>>>>> >>>>>>>>>> of these >>>>>>>> >>>>>>>>>>>>>>>>> warning: >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> INFO : HHH000400: Using dialect: >>>>>>>> >>>>>>>>>> org.hibernate.dialect.MySQL5Dialect >>>>>>>> >>>>>>>>>>>>>>>>> WARN : JDBC Driver reports it stores quoted >>>>>>>> identifiers >>>>>>>> >>>>>>>> in both >>>>>>>> >>>>>>>>>> mixed >>>>>>>> >>>>>>>>>>>>>>>>> and upper case >>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> >>>>>>>>>>>>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> and when I run some test I get the following >>>>>>>> exception: >>>>>>>> >>>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>> >>>>>>>>>> >>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>> >>>>>>>>>> >>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>>>>>> >>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> I am told that the bug does not affect the >>>>>>>> >>>>>>>> JBoss->Central sync >>>>>>>> >>>>>>>>>>>>>>>>>> process. So at some point the artifacts should >>>>>>>> all be >>>>>>>> >>>>>>>> available >>>>>>>> >>>>>>>>>> in Central >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole >>>>>>>> < >>>>>>>> >>>>>>>>>> steve(a)hibernate.org >>>>>>>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> hibernate-core seems to be the only artifact >>>>>>>> that is >>>>>>>> >>>>>>>> available >>>>>>>> >>>>>>>>>> in >>>>>>>> >>>>>>>>>>>>>>>>>>> JBoss Nexus. >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve >>>>>>>> Ebersole < >>>>>>>> >>>>>>>>>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>> So apparently the artifacts / repo issue is a >>>>>>>> Nexus >>>>>>>> >>>>>>>> bug that is >>>>>>>> >>>>>>>>>>>>>>>>>>>> effecting the JBoss repo (and therefore us)... >>>>>>>> >>>>>>>>>>>>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>> As I pointed out in the announcement, I am >>>>>>>> managing the >>>>>>>> >>>>>>>>>> "migration >>>>>>>> >>>>>>>>>>>>>>>>>>>> guide" in source repo while I develop the >>>>>>>> Betas. See >>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>>>>> >>>>>>>>>>>>>>>>>>>> As far are the new bootstrapping apis, see >>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>>>>> >>>>>>>>>>>>>>>>>>>> and >>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar >>>>>>>> Tahchiev < >>>>>>>> >>>>>>>>>>>>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi guys, >>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>> I just tried the latest beta and I cannot >>>>>>>> compile my >>>>>>>> >>>>>>>> project. >>>>>>>> >>>>>>>>>>>>>>>>>>>>> With the >>>>>>>> >>>>>>>>>>>>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>>>>>> >>>>>>>>>>>>>>>>>>>>> ------- >>>>>>>> >>>>>>>>>>>>>>>>>>>>> final org.hibernate.cfg.Configuration >>>>>>>> >>>>>>>> configuration = >>>>>>>> >>>>>>>>>>>>>>>>>>>>> getHibernateConfiguration(); >>>>>>>> >>>>>>>>>>>>>>>>>>>>> configuration.buildMappings(); >>>>>>>> >>>>>>>>>>>>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>>>>>> >>>>>>>>>>>>>>>>>>>>> SchemaUpdate(configuration); >>>>>>>> >>>>>>>>>>>>>>>>>>>>> ------- >>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>> however it seems that the SchemaUpdate >>>>>>>> constructor >>>>>>>> >>>>>>>> has been >>>>>>>> >>>>>>>>>>>>>>>>>>>>> removed and now >>>>>>>> >>>>>>>>>>>>>>>>>>>>> a new one is added: >>>>>>>> >>>>>>>>>>>>>>>>>>>>> -------- >>>>>>>> >>>>>>>>>>>>>>>>>>>>> public SchemaUpdate(MetadataImplementor >>>>>>>> metadata) >>>>>>>> >>>>>>>> { >>>>>>>> >>>>>>>>>>>>>>>>>>>>> this( >>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>>>> >>>>>>>>>>>>>>>>>>>>> metadata ); >>>>>>>> >>>>>>>>>>>>>>>>>>>>> } >>>>>>>> >>>>>>>>>>>>>>>>>>>>> --------- >>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>> Also the configuration.buildMappings() >>>>>>>> method has been >>>>>>>> >>>>>>>>>>>>>>>>>>>>> deprecated. Where do >>>>>>>> >>>>>>>>>>>>>>>>>>>>> I get the MetadataImplementor from? Also is >>>>>>>> there any >>>>>>>> >>>>>>>>>> changelog I >>>>>>>> >>>>>>>>>>>>>>>>>>>>> can refer >>>>>>>> >>>>>>>>>>>>>>>>>>>>> to? >>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards, Petar! >>>>>>>> >>>>>>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>> >>>>>>>>>>>>>>>>>>>>> --- >>>>>>>> >>>>>>>>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>> >>>>>>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF >>>>>>>> 55A5 1965 >>>>>>>> >>>>>>>> 8550 C311 >>>>>>>> >>>>>>>>>>>>>>>>>>>>> 0611 >>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> >>>>>>>>>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>> >>>>>>>>>>>>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>> >>>>>>>>>>>>>>>>> Regards, Petar! >>>>>>>> >>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>> >>>>>>>>>>>>>>>>> --- >>>>>>>> >>>>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>> >>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>>>>>>> 1965 8550 >>>>>>>> >>>>>>>> C311 >>>>>>>> >>>>>>>>>> 0611 >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>> >>>>>>>>>>>>>>> Regards, Petar! >>>>>>>> >>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>> >>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>> >>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>>>>>>> 1965 8550 >>>>>>>> >>>>>>>> C311 0611 >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>> >>>>>>>>>>>>>> Regards, Petar! >>>>>>>> >>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>> >>>>>>>>>>>>>> Public PGP Key at: >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>> >>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>>>>>>> 1965 8550 >>>>>>>> >>>>>>>> C311 0611 >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>> >>>>>>>>>>> hibernate-dev mailing list >>>>>>>> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> >>>>>>>> hibernate-dev mailing list >>>>>>>> >>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>> >>>>>>>> >>>> >>>>>>>> >> >>>>>>>> > _______________________________________________ >>>>>>>> > hibernate-dev mailing list >>>>>>>> > hibernate-dev(a)lists.jboss.org >>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> hibernate-dev mailing list >>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, Petar! >>>>>>> Karlovo, Bulgaria. >>>>>>> --- >>>>>>> Public PGP Key at: >>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, Petar! >>>>> Karlovo, Bulgaria. >>>>> --- >>>>> Public PGP Key at: >>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>> >>>> >>>> >>> >> > > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >

Hi Steve, thank you soo much for your support. I tried changing it but it had no effect. I also added a breakpoint in InformationExtractorJdbcDatabaseMetaDataImpl:135 and :151 but the flow never really goes through those breakpoints :( 2015-04-06 15:22 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > I am not fully aware of HSQLDB usage, but I wonder if you end up using 2 > different databases. I am fairly certain you are using an in-memory > database. In the test you are asking Hibernate to create a > ConnectionProvider explicitly (your buildHibernateConfiguration method). I > know absolutely zero about spring boot to know how in the heck it is > creating the the Hibernate EntityManager for you, but I suspect it somehow > causes a different HSQLDB instance to be started. > > The reason I say that is in my simplified version of your test I re-use > the same HSQLDB instance for sure and get different results. > > Still there does seem to be a problem > in org.hibernate.tool.schema.extract.internal.legacy.DatabaseInformationImpl > where it is not finding tables. If you have a local fork of Hibernate > could you try changing the determineCatalogFilter and determineSchemaFilter > in > org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl > to return ALL_CATALOGS_FILTER and ALL_SCHEMAS_FILTER instead of > SANS_CATALOG_FILTER and SANS_SCHEMA_FILTER as the fallback options and see > if that helps for you? > > > On Mon, Apr 6, 2015 at 6:34 AM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Because compiling told me that none of the 5.0 bootstrapping >> packages/classes could be found. >> >> Anyway, I am working on simplifying your demo thing into something >> simpler. >> >> On Mon, Apr 6, 2015 at 6:33 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >> wrote: >> >>> Hmm.. here's the result of mvn dependency:tree -Dverbose >>> -Dincludes=org.hibernate >>> >>> [INFO] --- maven-dependency-plugin:2.9:tree (default-cli) @ HHH-8805 --- >>> [WARNING] Using Maven 2 dependency tree to get verbose output, which >>> may be inconsistent with actual Maven 3 resolution >>> [INFO] org.test:HHH-8805:jar:0.0.1-SNAPSHOT >>> [INFO] \- >>> org.springframework.boot:spring-boot-starter-data-jpa:jar:1.2.3.RELEASE:compile >>> [INFO] \- >>> org.hibernate:hibernate-entitymanager:jar:5.0.0-SNAPSHOT:compile (version >>> managed from 4.3.8.Final) >>> [INFO] \- org.hibernate:hibernate-core:jar:5.0.0-SNAPSHOT:compile >>> [INFO] >>> ------------------------------------------------------------------------ >>> [INFO] BUILD SUCCESS >>> [INFO] >>> ------------------------------------------------------------------------ >>> >>> How do you know it's using 4.3.8? >>> >>> 2015-04-06 14:25 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>> >>>> So your repo is still trying to use Hibernate 4.3.8. So I cannot >>>> reproduce this. >>>> >>>> On top of that, it uses tons of dependencies not needed for a simple >>>> bug reproducer. >>>> >>>> On Mon, Apr 6, 2015 at 5:58 AM, Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> So on export the tables simply are not created due to lack of >>>>> privileges. So that explains why they are not found later. >>>>> >>>>> On Mon, Apr 6, 2015 at 5:56 AM, Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> Well there is a gigantic comment in org.hibernate.tool.schema. >>>>>> extract.internal.*legacy*.DatabaseInformationImpl that says how the tableInformationMap >>>>>> is not used, and why :) >>>>>> >>>>>> The problem is the HHH000262 log statement. That is saying that >>>>>> the tables are not found querying the database metadata. >>>>>> >>>>>> On Mon, Apr 6, 2015 at 1:34 AM, Petar Tahchiev < >>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>> >>>>>>> Just a quick follow-up here: SchemaMigratorImpl:125 is calling >>>>>>> existingDatabase.getTableInformation where existingDatabase is of type >>>>>>> org.hibernate.tool.schema.extract.internal.*legacy*.DatabaseInformationImpl >>>>>>> (I have no idea why is it using the legacy one), and If I step into it I >>>>>>> can see it's using a tableInformationMap which is empty - really weird as I >>>>>>> can see before that the hbm2ddl was reporting tables were not found so I >>>>>>> was expecting it to create them: >>>>>>> >>>>>>> 2015-04-06 09:29:40,608 >>>>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>>>> [main] INFO : HHH000262: Table not found: warehouse >>>>>>> 2015-04-06 09:29:40,610 >>>>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>>>> [main] INFO : HHH000262: Table not found: widget_title_lv >>>>>>> 2015-04-06 09:29:40,614 >>>>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>>>> [main] INFO : HHH000262: Table not found: wishlist >>>>>>> 2015-04-06 09:29:40,618 >>>>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>>>> [main] INFO : HHH000262: Table not found: wishlist_entry >>>>>>> 2015-04-06 09:29:40,622 >>>>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>>>> [main] INFO : HHH000262: Table not found: working_day >>>>>>> >>>>>>> >>>>>>> I'll try to create a test that reproduces the problem >>>>>>> >>>>>>> >>>>>>> 2015-04-06 5:20 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>>>> >>>>>>>> I see you have a test repository reproducing the error. I will >>>>>>>> try to run from there. >>>>>>>> >>>>>>>> On Sun, Apr 5, 2015 at 3:02 AM, Petar Tahchiev < >>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>>> >>>>>>>>> Hi Steve, >>>>>>>>> >>>>>>>>> the test project that I created still fails with the latest >>>>>>>>> SNAPSHOT release, although the foreign keys are not created. Can you please >>>>>>>>> investigate if that is related to the same issue. The test repository is >>>>>>>>> here: >>>>>>>>> >>>>>>>>> https://github.com/paranoiabla/HHH-8805 >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-04-03 16:15 GMT+03:00 Emmanuel Bernard < >>>>>>>>> emmanuel(a)hibernate.org&gt;: >>>>>>>>> >>>>>>>>>> Steve, I think there is something fishy. >>>>>>>>>> I have created a branch with a blatant usage of a JDK 8 API in >>>>>>>>>> hibernate-core >>>>>>>>>> There is one commit above today’s master: >>>>>>>>>> >>>>>>>>>> protected EmptyInterceptor() { >>>>>>>>>> + final java.time.ZoneId id = >>>>>>>>>> java.time.ZoneId.systemDefault(); >>>>>>>>>> + System.out.println( id.getId() ); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer >>>>>>>>>> < >>>>>>>>>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> And when I run ./gradlew clean build >>>>>>>>>> things do pass, i.e. Animal Sniffer is either not executed or it >>>>>>>>>> does not make the build fail. I did not see any Animal Sniffer reference in >>>>>>>>>> the console while it was running. >>>>>>>>>> >>>>>>>>>> Does it do the same for you if you clone my branch? >>>>>>>>>> >>>>>>>>>> Emmanuel >>>>>>>>>> >>>>>>>>>> PS: 18 mins here on a Mac + SSD. I guess Linux beats the crap >>>>>>>>>> out of Mac on FindBug executions ;) >>>>>>>>>> >>>>>>>>>> > On 01 Apr 2015, at 18:09, Steve Ebersole <steve(a)hibernate.org&gt; >>>>>>>>>> wrote: >>>>>>>>>> > >>>>>>>>>> > I'm not going to argue with you man. AnimalSniffer *is* run. >>>>>>>>>> If you don't >>>>>>>>>> > believe that and don't want to verify it for yourself, oh >>>>>>>>>> well, nothing I >>>>>>>>>> > can do about that... >>>>>>>>>> > >>>>>>>>>> > On Wed, Apr 1, 2015 at 8:32 AM, Gunnar Morling < >>>>>>>>>> gunnar(a)hibernate.org&gt; wrote: >>>>>>>>>> > >>>>>>>>>> >> Hum, you are not April-fooling me, right ;) >>>>>>>>>> >> >>>>>>>>>> >> There is something Java-8-specific in already: the usage of >>>>>>>>>> >> ConcurrentHashMap#keySet() (in >>>>>>>>>> >> SessionFactoryImpl#iterateEntityNameResolvers()) which - when >>>>>>>>>> compiled on >>>>>>>>>> >> Java 8 - adds a reference to the Java-8-only type KeySetView >>>>>>>>>> to the class >>>>>>>>>> >> file of SessionFactoryImpl. That's the issue pointed out by >>>>>>>>>> Petar >>>>>>>>>> >> originally. >>>>>>>>>> >> >>>>>>>>>> >> But when running "./gradlew build" on the current master, the >>>>>>>>>> build >>>>>>>>>> >> passes. I would expect it to fail though, as AnimalSniffer >>>>>>>>>> should detect >>>>>>>>>> >> that usage of Java 8's KeySetView class. So I don't see that >>>>>>>>>> AS is executed >>>>>>>>>> >> actually? Or are you saying it is run but it's findings don't >>>>>>>>>> cause the >>>>>>>>>> >> build to fail? >>>>>>>>>> >> >>>>>>>>>> >> If I go back to the original approach of using AS (via git >>>>>>>>>> checkout >>>>>>>>>> >> 5f6d1~1), it behaves as I'd expect it: "./gradlew build" >>>>>>>>>> fails due to that >>>>>>>>>> >> reference from >>>>>>>>>> SessionFactoryImpl#iterateEntityNameResolvers(). >>>>>>>>>> >> >>>>>>>>>> >> Do you actually see the build on master fail due to that >>>>>>>>>> reference being >>>>>>>>>> >> discovered by AS? >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> 2015-04-01 15:03 GMT+02:00 Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>> >> >>>>>>>>>> >>> Gunnar, it is applied. Add something that is java 8 >>>>>>>>>> specific and see... >>>>>>>>>> >>> On Apr 1, 2015 7:59 AM, "Gunnar Morling" < >>>>>>>>>> gunnar(a)hibernate.org&gt; wrote: >>>>>>>>>> >>> >>>>>>>>>> >>>> I saw the plug-in, Steve. But how/when is it executed? >>>>>>>>>> >>>> >>>>>>>>>> >>>> Running "./gradlew build" used to execute AnimalSniffer and >>>>>>>>>> would have >>>>>>>>>> >>>> revealed that accidental usage of KeySetView. That's not >>>>>>>>>> the case anymore. >>>>>>>>>> >>>> It would be nice if that new plug-in could be applied >>>>>>>>>> automatically after >>>>>>>>>> >>>> compileJava as it used to be the case with the Ant-based >>>>>>>>>> approach. >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> 2015-04-01 13:48 GMT+02:00 Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>> >>>> >>>>>>>>>> >>>>> Increase your Gradle-fu we must young apprentice :) >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> AnimalSniffer is still run. I simply converted it to be a >>>>>>>>>> plugin. >>>>>>>>>> >>>>> Check out >>>>>>>>>> org.hibernate.build.animalsniffer.AnimalSnifferPlugin in ORM's >>>>>>>>>> >>>>> /buildSrc project >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> AnimalSniffer will apparently not detect this :) >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling < >>>>>>>>>> gunnar(a)hibernate.org&gt; >>>>>>>>>> >>>>> wrote: >>>>>>>>>> >>>>> >>>>>>>>>> >>>>>>> Currently, AnimalSniffer is in place to prevent this >>>>>>>>>> very category >>>>>>>>>> >>>>>> of error and I'm wondering why it didn't detect the >>>>>>>>>> "usage" of KeySetView. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Looked at this a bit closer. Turns out, AnimalSniffer >>>>>>>>>> *will* detect >>>>>>>>>> >>>>>> this issue if it actually is run. The problem is that AS >>>>>>>>>> apparently is >>>>>>>>>> >>>>>> not executed by default anymore, due to the recent change >>>>>>>>>> to how AS is used >>>>>>>>>> >>>>>> [1]. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Prior to that change, running AS was done automatically >>>>>>>>>> after the compileJava >>>>>>>>>> >>>>>> task and would have reported that usage of KeySetView: >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Undefined reference: >>>>>>>>>> >>>>>> >>>>>>>>>> java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>>>>>> >>>>>> in >>>>>>>>>> >>>>>> >>>>>>>>>> [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Unfortunately my Gradle Foo is rather limited, so I'm not >>>>>>>>>> sure how to >>>>>>>>>> >>>>>> re-establish that behaviour with the new AS plug-in. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> --Gunnar >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> [1] >>>>>>>>>> >>>>>> >>>>>>>>>> https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb6... >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> 2015-04-01 9:39 GMT+02:00 Gunnar Morling < >>>>>>>>>> gunnar(a)hibernate.org&gt;: >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>>> Just to clarify... I *think* that as long as we run >>>>>>>>>> the build with >>>>>>>>>> >>>>>>>> Java 8 >>>>>>>>>> >>>>>>>> and set the bootclasspath to 6 or 7 we should be fine. >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Yes, setting the boot classpath to 6 (or 7) makes sure >>>>>>>>>> you only use >>>>>>>>>> >>>>>>> classes present in that JDK (be it explicitly or >>>>>>>>>> implicitly as in the >>>>>>>>>> >>>>>>> ConcurrentHashMap case), because it's that class library >>>>>>>>>> which will be used >>>>>>>>>> >>>>>>> for compilation then. It is cumbersome to use though as >>>>>>>>>> you need to specify >>>>>>>>>> >>>>>>> the location of a 6 or 7 JDK which makes the build less >>>>>>>>>> easily portable >>>>>>>>>> >>>>>>> between machines. >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Currently, AnimalSniffer is in place to prevent this >>>>>>>>>> very category of >>>>>>>>>> >>>>>>> error and I'm wondering why it didn't detect the "usage" >>>>>>>>>> of KeySetView. It >>>>>>>>>> >>>>>>> really should have detected it, assuming it analyses the >>>>>>>>>> byte code of >>>>>>>>>> >>>>>>> classes. But this makes me wonder now whether it only >>>>>>>>>> analyses the source >>>>>>>>>> >>>>>>> code actually. Then it wouldn't be usable to prevent >>>>>>>>>> this sort of issue. >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Coding against the ConcurrentMap interface is the best >>>>>>>>>> way to avoid >>>>>>>>>> >>>>>>> the issue. But of course there is no guarantee that it >>>>>>>>>> happens again, >>>>>>>>>> >>>>>>> unless e.g. having a build on CI which uses 6 or 7 on >>>>>>>>>> its boot classpath. >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>>> On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>> >>>>>>>> wrote: >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>> Well the idea is to run the Gradle process with Java 8 >>>>>>>>>> (the build >>>>>>>>>> >>>>>>>> itself >>>>>>>>>> >>>>>>>>> is a Java process too don't forget). We pass in the >>>>>>>>>> older JDK >>>>>>>>>> >>>>>>>> specifically >>>>>>>>>> >>>>>>>>> to be able to set the bootclasspath for compilation >>>>>>>>>> and the >>>>>>>>>> >>>>>>>> executable for >>>>>>>>>> >>>>>>>>> running tests. That's the theory. >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> Interestingly I developed a simplified project to test >>>>>>>>>> these >>>>>>>>>> >>>>>>>> theories: >>>>>>>>>> >>>>>>>>> https://github.com/sebersole/gradle-mixed-jdk And of >>>>>>>>>> course this >>>>>>>>>> >>>>>>>> all >>>>>>>>>> >>>>>>>>> works there. As you'd expect right? >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> I think the JAXB thing comes into play here as well. >>>>>>>>>> Gradle does >>>>>>>>>> >>>>>>>> not have >>>>>>>>>> >>>>>>>>> any XJC support built in, so we have to make use of >>>>>>>>>> its Ant >>>>>>>>>> >>>>>>>> support to run >>>>>>>>>> >>>>>>>>> the XJC Ant tasks for JAXB model generation. The >>>>>>>>>> problem there is >>>>>>>>>> >>>>>>>> that, >>>>>>>>>> >>>>>>>>> afaik, there is no way to tell Gradle's AntBuilder to >>>>>>>>>> use a JDK >>>>>>>>>> >>>>>>>> other than >>>>>>>>>> >>>>>>>>> the one that launched Gradle. I think this is why we >>>>>>>>>> see a JAXB >>>>>>>>>> >>>>>>>> model >>>>>>>>>> >>>>>>>>> defined for Java 7, rather than Java 6, because we >>>>>>>>>> essentially run >>>>>>>>>> >>>>>>>> XJC with >>>>>>>>>> >>>>>>>>> Java 8. >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> Anyway, this certainly makes the build more complex >>>>>>>>>> and we >>>>>>>>>> >>>>>>>> definitely have >>>>>>>>>> >>>>>>>>> to think through all these scenarios. In fact after >>>>>>>>>> Beta1, one of >>>>>>>>>> >>>>>>>> my todos >>>>>>>>>> >>>>>>>>> is to build up the build "from scratch" using that >>>>>>>>>> >>>>>>>> gradle-mixed-jdk project >>>>>>>>>> >>>>>>>>> as a basis. >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> In general the plan though is to run all the tests >>>>>>>>>> (other than >>>>>>>>>> >>>>>>>>> hibernate-java8, obviously) with the "baseline JDK, >>>>>>>>>> whether that >>>>>>>>>> >>>>>>>> be Java 6 >>>>>>>>>> >>>>>>>>> or 7. >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>>>>>>>> >>>>>>>> sanne(a)hibernate.org&gt; >>>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> There are many similar issues discussed on the Lucene >>>>>>>>>> developer's >>>>>>>>>> >>>>>>>>>> mailing list, it's an interesting read: >>>>>>>>>> >>>>>>>>>> - >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I see no alternative than to have those test jobs >>>>>>>>>> actually >>>>>>>>>> >>>>>>>> exercising >>>>>>>>>> >>>>>>>>>> ORM with JDK6, or maybe even compile it all with JDK6 >>>>>>>>>> except the >>>>>>>>>> >>>>>>>> Java8 >>>>>>>>>> >>>>>>>>>> additional module to be compiled with JDK8 ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 1 April 2015 at 00:36, Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>> >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Ahh, seems this may be an option to work around it: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> <quote> >>>>>>>>>> >>>>>>>>>>> Using the general *Map* interface in place of the >>>>>>>>>> concrete >>>>>>>>>> >>>>>>>>>>> *ConcurrentHashMap* type here side-steps the >>>>>>>>>> coupling to the >>>>>>>>>> >>>>>>>> Java 8 >>>>>>>>>> >>>>>>>>>> return >>>>>>>>>> >>>>>>>>>>> type and will allow this code to be compiled with >>>>>>>>>> Java 8 and >>>>>>>>>> >>>>>>>> run on >>>>>>>>>> >>>>>>>>>> Java 7. >>>>>>>>>> >>>>>>>>>>> </quote> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I had missed that part. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>>>>>>>> >>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> When I say "internal" here, I mean internal to java >>>>>>>>>> classes. >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>>>>>>>> >>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> Nope. It just effects any code compiled with Java >>>>>>>>>> 8 even >>>>>>>>>> >>>>>>>> though the >>>>>>>>>> >>>>>>>>>>>>> change is internal. The problem is the generated >>>>>>>>>> bytecode >>>>>>>>>> >>>>>>>>>> incorporates >>>>>>>>>> >>>>>>>>>>>>> this change. Like I said, this should be >>>>>>>>>> compiled with 1.6 >>>>>>>>>> >>>>>>>>>> compatibility, >>>>>>>>>> >>>>>>>>>>>>> but that is apparently not working atm. I am >>>>>>>>>> having a >>>>>>>>>> >>>>>>>> struggle >>>>>>>>>> >>>>>>>>>> getting a >>>>>>>>>> >>>>>>>>>>>>> mixed JDK build working "just right". >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>>>>>>>> >>>>>>>>>> paranoiabla(a)gmail.com&gt; >>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> According to this: >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* >>>>>>>>>> returns a >>>>>>>>>> >>>>>>>> Set<K> >>>>>>>>>> >>>>>>>>>> while >>>>>>>>>> >>>>>>>>>>>>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>>>>>>>> >>>>>>>>>>>>>> ConcurrentHashMap.KeySetView<K,V>`. >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> I think you're using some Java8 API. >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>>>>>>>> >>>>>>>> paranoiabla(a)gmail.com&gt;: >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>>>>>>>> >>>>>>>>>>>>>>> java version "1.7.0_71" >>>>>>>>>> >>>>>>>>>>>>>>> Java(TM) SE Runtime Environment (build >>>>>>>>>> 1.7.0_71-b14) >>>>>>>>>> >>>>>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>>>>>> 24.71-b01, mixed >>>>>>>>>> >>>>>>>> mode) >>>>>>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>>>>>>>> >>>>>>>>>>>>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic >>>>>>>>>> #44-Ubuntu >>>>>>>>>> >>>>>>>> SMP Thu >>>>>>>>>> >>>>>>>>>> Mar >>>>>>>>>> >>>>>>>>>>>>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 >>>>>>>>>> GNU/Linux >>>>>>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>>>>>>>> >>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> What JRE are you trying to use? This error: >>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: >>>>>>>>>> java.util.concurrent. >>>>>>>>>> >>>>>>>>>>>>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>>>>>>>> >>>>>>>>>>>>>>>> ConcurrentHashMap$KeySetView; >>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> is indicative of an issue in cross-jre support >>>>>>>>>> due to a >>>>>>>>>> >>>>>>>> change >>>>>>>>>> >>>>>>>>>>>>>>>> internal to java classes. >>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev >>>>>>>>>> < >>>>>>>>>> >>>>>>>>>> paranoiabla(a)gmail.com >>>>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks Steve, >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> I managed to migrate my configuration to the >>>>>>>>>> new >>>>>>>>>> >>>>>>>>>>>>>>>>> MetamodelImplementor. Now when I run the scema >>>>>>>>>> export I >>>>>>>>>> >>>>>>>> get a lot >>>>>>>>>> >>>>>>>>>> of these >>>>>>>>>> >>>>>>>>>>>>>>>>> warning: >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> INFO : HHH000400: Using dialect: >>>>>>>>>> >>>>>>>>>> org.hibernate.dialect.MySQL5Dialect >>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : JDBC Driver reports it stores quoted >>>>>>>>>> identifiers >>>>>>>>>> >>>>>>>> in both >>>>>>>>>> >>>>>>>>>> mixed >>>>>>>>>> >>>>>>>>>>>>>>>>> and upper case >>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> and when I run some test I get the following >>>>>>>>>> exception: >>>>>>>>>> >>>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>>>>>>>> >>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>> I am told that the bug does not affect the >>>>>>>>>> >>>>>>>> JBoss->Central sync >>>>>>>>>> >>>>>>>>>>>>>>>>>> process. So at some point the artifacts >>>>>>>>>> should all be >>>>>>>>>> >>>>>>>> available >>>>>>>>>> >>>>>>>>>> in Central >>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve >>>>>>>>>> Ebersole < >>>>>>>>>> >>>>>>>>>> steve(a)hibernate.org >>>>>>>>>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>> hibernate-core seems to be the only artifact >>>>>>>>>> that is >>>>>>>>>> >>>>>>>> available >>>>>>>>>> >>>>>>>>>> in >>>>>>>>>> >>>>>>>>>>>>>>>>>>> JBoss Nexus. >>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve >>>>>>>>>> Ebersole < >>>>>>>>>> >>>>>>>>>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> So apparently the artifacts / repo issue is >>>>>>>>>> a Nexus >>>>>>>>>> >>>>>>>> bug that is >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> effecting the JBoss repo (and therefore >>>>>>>>>> us)... >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> As I pointed out in the announcement, I am >>>>>>>>>> managing the >>>>>>>>>> >>>>>>>>>> "migration >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> guide" in source repo while I develop the >>>>>>>>>> Betas. See >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> As far are the new bootstrapping apis, see >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar >>>>>>>>>> Tahchiev < >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I just tried the latest beta and I cannot >>>>>>>>>> compile my >>>>>>>>>> >>>>>>>> project. >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> With the >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> latest hibernate 4.3.X I was able to do >>>>>>>>>> this: >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ------- >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> final >>>>>>>>>> org.hibernate.cfg.Configuration >>>>>>>>>> >>>>>>>> configuration = >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> getHibernateConfiguration(); >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> configuration.buildMappings(); >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> final SchemaUpdate schemaUpdate = >>>>>>>>>> new >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> SchemaUpdate(configuration); >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ------- >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> however it seems that the SchemaUpdate >>>>>>>>>> constructor >>>>>>>>>> >>>>>>>> has been >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> removed and now >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> a new one is added: >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -------- >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> public SchemaUpdate(MetadataImplementor >>>>>>>>>> metadata) >>>>>>>>>> >>>>>>>> { >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> this( >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> metadata ); >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> --------- >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Also the configuration.buildMappings() >>>>>>>>>> method has been >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> deprecated. Where do >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I get the MetadataImplementor from? Also >>>>>>>>>> is there any >>>>>>>>>> >>>>>>>>>> changelog I >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> can refer >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> to? >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF >>>>>>>>>> 55A5 1965 >>>>>>>>>> >>>>>>>> 8550 C311 >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 0611 >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>> >>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>> >>>>>>>>>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>> >>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF >>>>>>>>>> 55A5 1965 8550 >>>>>>>>>> >>>>>>>> C311 >>>>>>>>>> >>>>>>>>>> 0611 >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>> >>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>> >>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>>>>>>>>> 1965 8550 >>>>>>>>>> >>>>>>>> C311 0611 >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>> >>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>> >>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>>>>>>>>> 1965 8550 >>>>>>>>>> >>>>>>>> C311 0611 >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>> >>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>>>> >>>>>>>> hibernate-dev mailing list >>>>>>>>>> >>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>> >>>>>>>>>> >> >>>>>>>>>> > _______________________________________________ >>>>>>>>>> > hibernate-dev mailing list >>>>>>>>>> > hibernate-dev(a)lists.jboss.org >>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> hibernate-dev mailing list >>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards, Petar! >>>>>>>>> Karlovo, Bulgaria. >>>>>>>>> --- >>>>>>>>> Public PGP Key at: >>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >>>>>>>>> 0611 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, Petar! >>>>>>> Karlovo, Bulgaria. >>>>>>> --- >>>>>>> Public PGP Key at: >>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> Regards, Petar! >>> Karlovo, Bulgaria. >>> --- >>> Public PGP Key at: >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>> >> >> > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611

Petar, I just resolved HHH-9713 and it was working against my simplified version of your demo. Just fyi... On Mon, Apr 6, 2015 at 9:37 AM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Petar, not sure what to say. That sounds like a local set up problem. I > cannot really help with that. > > Anyway, I have a "stripped down" version of your test. I ripped out > Spring and added a Gradle build script. The actual test class/method > changed slightly to be just one test method: > > > public class Hhh8805ApplicationTests { > @Test > public void testIt() { > final StandardServiceRegistry standardRegistry = new > StandardServiceRegistryBuilder() > .loadProperties( "demo/hibernate.properties" ) > .build(); > > try { > final MetadataImplementor metadata = (MetadataImplementor) > new MetadataSources( standardRegistry ) > .addAnnotatedClass(AbstractEntityModel.class) > .addAnnotatedClass( AbstractFilteredEntityModel.class > ) > .addAnnotatedClass( AbstractFilterModel.class ) > .addAnnotatedClass( CategoryModel.class ) > .addAnnotatedClass( ProductModel.class ) > .addAnnotatedClass( DesktopFilter.class ) > .addAnnotatedClass( MobileFilter.class ) > .buildMetadata(); > > // export the schema > new SchemaExport( metadata ).execute( false, true, false, > false ); > > try { > // update the schema > new SchemaUpdate( metadata ).execute( false, true ); > } > finally { > // drop the schema > new SchemaExport( metadata ).execute( false, true, false, > false ); > } > > } > finally { > StandardServiceRegistryBuilder.destroy( standardRegistry ); > } > > } > } > > So basically, it does an explicit SchemaExport followed by an explicit > SchemaUpdate. Just like your tests, it does the initial SchemExport to > make sure that SchemaUpdate is finding the existing tables and altering > them. Anyway, this fails but it fails in a way I completely expect after > looking at it based on what is quite likely a bug but a bug that is in 4.3 > (at least) as well. The failure is an attempt to create the index you > specified in the mappings. Hibernate is trying to create the index, but > for your database it is generating the name to use in the CREATE INDEX > command incorrectly (this is the bug): > > 09:34:08,484 ERROR SchemaExport:458 - HHH000389: Unsuccessful: create > index entity_filters.IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters > (entity_pk) > 09:34:08,484 ERROR SchemaExport:459 - invalid schema name: ENTITY_FILTERS > > I need to investigate this one a bit. I created > https://hibernate.atlassian.net/browse/HHH-9713 to do that investigation. > > > On Mon, Apr 6, 2015 at 7:35 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; > wrote: > >> Hi Steve, >> >> thank you soo much for your support. I tried changing it but it had no >> effect. I also added a breakpoint in >> InformationExtractorJdbcDatabaseMetaDataImpl:135 and :151 but the flow >> never really goes through those breakpoints :( >> >> 2015-04-06 15:22 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> I am not fully aware of HSQLDB usage, but I wonder if you end up using >>> 2 different databases. I am fairly certain you are using an in-memory >>> database. In the test you are asking Hibernate to create a >>> ConnectionProvider explicitly (your buildHibernateConfiguration method). I >>> know absolutely zero about spring boot to know how in the heck it is >>> creating the the Hibernate EntityManager for you, but I suspect it somehow >>> causes a different HSQLDB instance to be started. >>> >>> The reason I say that is in my simplified version of your test I re-use >>> the same HSQLDB instance for sure and get different results. >>> >>> Still there does seem to be a problem >>> in org.hibernate.tool.schema.extract.internal.legacy.DatabaseInformationImpl >>> where it is not finding tables. If you have a local fork of Hibernate >>> could you try changing the determineCatalogFilter and determineSchemaFilter >>> in >>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>> to return ALL_CATALOGS_FILTER and ALL_SCHEMAS_FILTER instead of >>> SANS_CATALOG_FILTER and SANS_SCHEMA_FILTER as the fallback options and see >>> if that helps for you? >>> >>> >>> On Mon, Apr 6, 2015 at 6:34 AM, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> Because compiling told me that none of the 5.0 bootstrapping >>>> packages/classes could be found. >>>> >>>> Anyway, I am working on simplifying your demo thing into something >>>> simpler. >>>> >>>> On Mon, Apr 6, 2015 at 6:33 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >>>> wrote: >>>> >>>>> Hmm.. here's the result of mvn dependency:tree -Dverbose >>>>> -Dincludes=org.hibernate >>>>> >>>>> [INFO] --- maven-dependency-plugin:2.9:tree (default-cli) @ HHH-8805 >>>>> --- >>>>> [WARNING] Using Maven 2 dependency tree to get verbose output, which >>>>> may be inconsistent with actual Maven 3 resolution >>>>> [INFO] org.test:HHH-8805:jar:0.0.1-SNAPSHOT >>>>> [INFO] \- >>>>> org.springframework.boot:spring-boot-starter-data-jpa:jar:1.2.3.RELEASE:compile >>>>> [INFO] \- >>>>> org.hibernate:hibernate-entitymanager:jar:5.0.0-SNAPSHOT:compile (version >>>>> managed from 4.3.8.Final) >>>>> [INFO] \- >>>>> org.hibernate:hibernate-core:jar:5.0.0-SNAPSHOT:compile >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> [INFO] BUILD SUCCESS >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> >>>>> How do you know it's using 4.3.8? >>>>> >>>>> 2015-04-06 14:25 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>> >>>>>> So your repo is still trying to use Hibernate 4.3.8. So I cannot >>>>>> reproduce this. >>>>>> >>>>>> On top of that, it uses tons of dependencies not needed for a simple >>>>>> bug reproducer. >>>>>> >>>>>> On Mon, Apr 6, 2015 at 5:58 AM, Steve Ebersole <steve(a)hibernate.org&gt; >>>>>> wrote: >>>>>> >>>>>>> So on export the tables simply are not created due to lack of >>>>>>> privileges. So that explains why they are not found later. >>>>>>> >>>>>>> On Mon, Apr 6, 2015 at 5:56 AM, Steve Ebersole <steve(a)hibernate.org >>>>>>> > wrote: >>>>>>> >>>>>>>> Well there is a gigantic comment in org.hibernate.tool.schema. >>>>>>>> extract.internal.*legacy*.DatabaseInformationImpl that says how >>>>>>>> the tableInformationMap is not used, and why :) >>>>>>>> >>>>>>>> The problem is the HHH000262 log statement. That is saying that >>>>>>>> the tables are not found querying the database metadata. >>>>>>>> >>>>>>>> On Mon, Apr 6, 2015 at 1:34 AM, Petar Tahchiev < >>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>>> >>>>>>>>> Just a quick follow-up here: SchemaMigratorImpl:125 is calling >>>>>>>>> existingDatabase.getTableInformation where existingDatabase is of type >>>>>>>>> org.hibernate.tool.schema.extract.internal.*legacy*.DatabaseInformationImpl >>>>>>>>> (I have no idea why is it using the legacy one), and If I step into it I >>>>>>>>> can see it's using a tableInformationMap which is empty - really weird as I >>>>>>>>> can see before that the hbm2ddl was reporting tables were not found so I >>>>>>>>> was expecting it to create them: >>>>>>>>> >>>>>>>>> 2015-04-06 09:29:40,608 >>>>>>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>>>>>> [main] INFO : HHH000262: Table not found: warehouse >>>>>>>>> 2015-04-06 09:29:40,610 >>>>>>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>>>>>> [main] INFO : HHH000262: Table not found: widget_title_lv >>>>>>>>> 2015-04-06 09:29:40,614 >>>>>>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>>>>>> [main] INFO : HHH000262: Table not found: wishlist >>>>>>>>> 2015-04-06 09:29:40,618 >>>>>>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>>>>>> [main] INFO : HHH000262: Table not found: wishlist_entry >>>>>>>>> 2015-04-06 09:29:40,622 >>>>>>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>>>>>> [main] INFO : HHH000262: Table not found: working_day >>>>>>>>> >>>>>>>>> >>>>>>>>> I'll try to create a test that reproduces the problem >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-04-06 5:20 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>>>>>> >>>>>>>>>> I see you have a test repository reproducing the error. I will >>>>>>>>>> try to run from there. >>>>>>>>>> >>>>>>>>>> On Sun, Apr 5, 2015 at 3:02 AM, Petar Tahchiev < >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>>>>> >>>>>>>>>>> Hi Steve, >>>>>>>>>>> >>>>>>>>>>> the test project that I created still fails with the latest >>>>>>>>>>> SNAPSHOT release, although the foreign keys are not created. Can you please >>>>>>>>>>> investigate if that is related to the same issue. The test repository is >>>>>>>>>>> here: >>>>>>>>>>> >>>>>>>>>>> https://github.com/paranoiabla/HHH-8805 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2015-04-03 16:15 GMT+03:00 Emmanuel Bernard < >>>>>>>>>>> emmanuel(a)hibernate.org&gt;: >>>>>>>>>>> >>>>>>>>>>>> Steve, I think there is something fishy. >>>>>>>>>>>> I have created a branch with a blatant usage of a JDK 8 API in >>>>>>>>>>>> hibernate-core >>>>>>>>>>>> There is one commit above today’s master: >>>>>>>>>>>> >>>>>>>>>>>> protected EmptyInterceptor() { >>>>>>>>>>>> + final java.time.ZoneId id = >>>>>>>>>>>> java.time.ZoneId.systemDefault(); >>>>>>>>>>>> + System.out.println( id.getId() ); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer >>>>>>>>>>>> < >>>>>>>>>>>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> And when I run ./gradlew clean build >>>>>>>>>>>> things do pass, i.e. Animal Sniffer is either not executed or >>>>>>>>>>>> it does not make the build fail. I did not see any Animal Sniffer reference >>>>>>>>>>>> in the console while it was running. >>>>>>>>>>>> >>>>>>>>>>>> Does it do the same for you if you clone my branch? >>>>>>>>>>>> >>>>>>>>>>>> Emmanuel >>>>>>>>>>>> >>>>>>>>>>>> PS: 18 mins here on a Mac + SSD. I guess Linux beats the crap >>>>>>>>>>>> out of Mac on FindBug executions ;) >>>>>>>>>>>> >>>>>>>>>>>> > On 01 Apr 2015, at 18:09, Steve Ebersole < >>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > I'm not going to argue with you man. AnimalSniffer *is* >>>>>>>>>>>> run. If you don't >>>>>>>>>>>> > believe that and don't want to verify it for yourself, oh >>>>>>>>>>>> well, nothing I >>>>>>>>>>>> > can do about that... >>>>>>>>>>>> > >>>>>>>>>>>> > On Wed, Apr 1, 2015 at 8:32 AM, Gunnar Morling < >>>>>>>>>>>> gunnar(a)hibernate.org&gt; wrote: >>>>>>>>>>>> > >>>>>>>>>>>> >> Hum, you are not April-fooling me, right ;) >>>>>>>>>>>> >> >>>>>>>>>>>> >> There is something Java-8-specific in already: the usage of >>>>>>>>>>>> >> ConcurrentHashMap#keySet() (in >>>>>>>>>>>> >> SessionFactoryImpl#iterateEntityNameResolvers()) which - >>>>>>>>>>>> when compiled on >>>>>>>>>>>> >> Java 8 - adds a reference to the Java-8-only type >>>>>>>>>>>> KeySetView to the class >>>>>>>>>>>> >> file of SessionFactoryImpl. That's the issue pointed out by >>>>>>>>>>>> Petar >>>>>>>>>>>> >> originally. >>>>>>>>>>>> >> >>>>>>>>>>>> >> But when running "./gradlew build" on the current master, >>>>>>>>>>>> the build >>>>>>>>>>>> >> passes. I would expect it to fail though, as AnimalSniffer >>>>>>>>>>>> should detect >>>>>>>>>>>> >> that usage of Java 8's KeySetView class. So I don't see >>>>>>>>>>>> that AS is executed >>>>>>>>>>>> >> actually? Or are you saying it is run but it's findings >>>>>>>>>>>> don't cause the >>>>>>>>>>>> >> build to fail? >>>>>>>>>>>> >> >>>>>>>>>>>> >> If I go back to the original approach of using AS (via git >>>>>>>>>>>> checkout >>>>>>>>>>>> >> 5f6d1~1), it behaves as I'd expect it: "./gradlew build" >>>>>>>>>>>> fails due to that >>>>>>>>>>>> >> reference from >>>>>>>>>>>> SessionFactoryImpl#iterateEntityNameResolvers(). >>>>>>>>>>>> >> >>>>>>>>>>>> >> Do you actually see the build on master fail due to that >>>>>>>>>>>> reference being >>>>>>>>>>>> >> discovered by AS? >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> 2015-04-01 15:03 GMT+02:00 Steve Ebersole < >>>>>>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>>>> >> >>>>>>>>>>>> >>> Gunnar, it is applied. Add something that is java 8 >>>>>>>>>>>> specific and see... >>>>>>>>>>>> >>> On Apr 1, 2015 7:59 AM, "Gunnar Morling" < >>>>>>>>>>>> gunnar(a)hibernate.org&gt; wrote: >>>>>>>>>>>> >>> >>>>>>>>>>>> >>>> I saw the plug-in, Steve. But how/when is it executed? >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Running "./gradlew build" used to execute AnimalSniffer >>>>>>>>>>>> and would have >>>>>>>>>>>> >>>> revealed that accidental usage of KeySetView. That's not >>>>>>>>>>>> the case anymore. >>>>>>>>>>>> >>>> It would be nice if that new plug-in could be applied >>>>>>>>>>>> automatically after >>>>>>>>>>>> >>>> compileJava as it used to be the case with the Ant-based >>>>>>>>>>>> approach. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> 2015-04-01 13:48 GMT+02:00 Steve Ebersole < >>>>>>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>>> Increase your Gradle-fu we must young apprentice :) >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> AnimalSniffer is still run. I simply converted it to be >>>>>>>>>>>> a plugin. >>>>>>>>>>>> >>>>> Check out >>>>>>>>>>>> org.hibernate.build.animalsniffer.AnimalSnifferPlugin in ORM's >>>>>>>>>>>> >>>>> /buildSrc project >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> AnimalSniffer will apparently not detect this :) >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling < >>>>>>>>>>>> gunnar(a)hibernate.org&gt; >>>>>>>>>>>> >>>>> wrote: >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>>>> Currently, AnimalSniffer is in place to prevent this >>>>>>>>>>>> very category >>>>>>>>>>>> >>>>>> of error and I'm wondering why it didn't detect the >>>>>>>>>>>> "usage" of KeySetView. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Looked at this a bit closer. Turns out, AnimalSniffer >>>>>>>>>>>> *will* detect >>>>>>>>>>>> >>>>>> this issue if it actually is run. The problem is that >>>>>>>>>>>> AS apparently is >>>>>>>>>>>> >>>>>> not executed by default anymore, due to the recent >>>>>>>>>>>> change to how AS is used >>>>>>>>>>>> >>>>>> [1]. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Prior to that change, running AS was done automatically >>>>>>>>>>>> after the compileJava >>>>>>>>>>>> >>>>>> task and would have reported that usage of KeySetView: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Undefined reference: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>>>>>>>> >>>>>> in >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Unfortunately my Gradle Foo is rather limited, so I'm >>>>>>>>>>>> not sure how to >>>>>>>>>>>> >>>>>> re-establish that behaviour with the new AS plug-in. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> --Gunnar >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> [1] >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb6... >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> 2015-04-01 9:39 GMT+02:00 Gunnar Morling < >>>>>>>>>>>> gunnar(a)hibernate.org&gt;: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole < >>>>>>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>>> Just to clarify... I *think* that as long as we run >>>>>>>>>>>> the build with >>>>>>>>>>>> >>>>>>>> Java 8 >>>>>>>>>>>> >>>>>>>> and set the bootclasspath to 6 or 7 we should be fine. >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Yes, setting the boot classpath to 6 (or 7) makes sure >>>>>>>>>>>> you only use >>>>>>>>>>>> >>>>>>> classes present in that JDK (be it explicitly or >>>>>>>>>>>> implicitly as in the >>>>>>>>>>>> >>>>>>> ConcurrentHashMap case), because it's that class >>>>>>>>>>>> library which will be used >>>>>>>>>>>> >>>>>>> for compilation then. It is cumbersome to use though >>>>>>>>>>>> as you need to specify >>>>>>>>>>>> >>>>>>> the location of a 6 or 7 JDK which makes the build >>>>>>>>>>>> less easily portable >>>>>>>>>>>> >>>>>>> between machines. >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Currently, AnimalSniffer is in place to prevent this >>>>>>>>>>>> very category of >>>>>>>>>>>> >>>>>>> error and I'm wondering why it didn't detect the >>>>>>>>>>>> "usage" of KeySetView. It >>>>>>>>>>>> >>>>>>> really should have detected it, assuming it analyses >>>>>>>>>>>> the byte code of >>>>>>>>>>>> >>>>>>> classes. But this makes me wonder now whether it only >>>>>>>>>>>> analyses the source >>>>>>>>>>>> >>>>>>> code actually. Then it wouldn't be usable to prevent >>>>>>>>>>>> this sort of issue. >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Coding against the ConcurrentMap interface is the best >>>>>>>>>>>> way to avoid >>>>>>>>>>>> >>>>>>> the issue. But of course there is no guarantee that it >>>>>>>>>>>> happens again, >>>>>>>>>>>> >>>>>>> unless e.g. having a build on CI which uses 6 or 7 on >>>>>>>>>>>> its boot classpath. >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>>> On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole < >>>>>>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>>>> >>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>>> Well the idea is to run the Gradle process with Java >>>>>>>>>>>> 8 (the build >>>>>>>>>>>> >>>>>>>> itself >>>>>>>>>>>> >>>>>>>>> is a Java process too don't forget). We pass in the >>>>>>>>>>>> older JDK >>>>>>>>>>>> >>>>>>>> specifically >>>>>>>>>>>> >>>>>>>>> to be able to set the bootclasspath for compilation >>>>>>>>>>>> and the >>>>>>>>>>>> >>>>>>>> executable for >>>>>>>>>>>> >>>>>>>>> running tests. That's the theory. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> Interestingly I developed a simplified project to >>>>>>>>>>>> test these >>>>>>>>>>>> >>>>>>>> theories: >>>>>>>>>>>> >>>>>>>>> https://github.com/sebersole/gradle-mixed-jdk And >>>>>>>>>>>> of course this >>>>>>>>>>>> >>>>>>>> all >>>>>>>>>>>> >>>>>>>>> works there. As you'd expect right? >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> I think the JAXB thing comes into play here as >>>>>>>>>>>> well. Gradle does >>>>>>>>>>>> >>>>>>>> not have >>>>>>>>>>>> >>>>>>>>> any XJC support built in, so we have to make use of >>>>>>>>>>>> its Ant >>>>>>>>>>>> >>>>>>>> support to run >>>>>>>>>>>> >>>>>>>>> the XJC Ant tasks for JAXB model generation. The >>>>>>>>>>>> problem there is >>>>>>>>>>>> >>>>>>>> that, >>>>>>>>>>>> >>>>>>>>> afaik, there is no way to tell Gradle's AntBuilder >>>>>>>>>>>> to use a JDK >>>>>>>>>>>> >>>>>>>> other than >>>>>>>>>>>> >>>>>>>>> the one that launched Gradle. I think this is why >>>>>>>>>>>> we see a JAXB >>>>>>>>>>>> >>>>>>>> model >>>>>>>>>>>> >>>>>>>>> defined for Java 7, rather than Java 6, because we >>>>>>>>>>>> essentially run >>>>>>>>>>>> >>>>>>>> XJC with >>>>>>>>>>>> >>>>>>>>> Java 8. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> Anyway, this certainly makes the build more complex >>>>>>>>>>>> and we >>>>>>>>>>>> >>>>>>>> definitely have >>>>>>>>>>>> >>>>>>>>> to think through all these scenarios. In fact after >>>>>>>>>>>> Beta1, one of >>>>>>>>>>>> >>>>>>>> my todos >>>>>>>>>>>> >>>>>>>>> is to build up the build "from scratch" using that >>>>>>>>>>>> >>>>>>>> gradle-mixed-jdk project >>>>>>>>>>>> >>>>>>>>> as a basis. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> In general the plan though is to run all the tests >>>>>>>>>>>> (other than >>>>>>>>>>>> >>>>>>>>> hibernate-java8, obviously) with the "baseline JDK, >>>>>>>>>>>> whether that >>>>>>>>>>>> >>>>>>>> be Java 6 >>>>>>>>>>>> >>>>>>>>> or 7. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>>>>>>>>>> >>>>>>>> sanne(a)hibernate.org&gt; >>>>>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> There are many similar issues discussed on the >>>>>>>>>>>> Lucene developer's >>>>>>>>>>>> >>>>>>>>>> mailing list, it's an interesting read: >>>>>>>>>>>> >>>>>>>>>> - >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> I see no alternative than to have those test jobs >>>>>>>>>>>> actually >>>>>>>>>>>> >>>>>>>> exercising >>>>>>>>>>>> >>>>>>>>>> ORM with JDK6, or maybe even compile it all with >>>>>>>>>>>> JDK6 except the >>>>>>>>>>>> >>>>>>>> Java8 >>>>>>>>>>>> >>>>>>>>>> additional module to be compiled with JDK8 ? >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> On 1 April 2015 at 00:36, Steve Ebersole < >>>>>>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>>>> >>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>> Ahh, seems this may be an option to work around it: >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> <quote> >>>>>>>>>>>> >>>>>>>>>>> Using the general *Map* interface in place of the >>>>>>>>>>>> concrete >>>>>>>>>>>> >>>>>>>>>>> *ConcurrentHashMap* type here side-steps the >>>>>>>>>>>> coupling to the >>>>>>>>>>>> >>>>>>>> Java 8 >>>>>>>>>>>> >>>>>>>>>> return >>>>>>>>>>>> >>>>>>>>>>> type and will allow this code to be compiled with >>>>>>>>>>>> Java 8 and >>>>>>>>>>>> >>>>>>>> run on >>>>>>>>>>>> >>>>>>>>>> Java 7. >>>>>>>>>>>> >>>>>>>>>>> </quote> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> I had missed that part. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>>>>>>>>>> >>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> When I say "internal" here, I mean internal to >>>>>>>>>>>> java classes. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>>>>>>>>>> >>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Nope. It just effects any code compiled with >>>>>>>>>>>> Java 8 even >>>>>>>>>>>> >>>>>>>> though the >>>>>>>>>>>> >>>>>>>>>>>>> change is internal. The problem is the >>>>>>>>>>>> generated bytecode >>>>>>>>>>>> >>>>>>>>>> incorporates >>>>>>>>>>>> >>>>>>>>>>>>> this change. Like I said, this should be >>>>>>>>>>>> compiled with 1.6 >>>>>>>>>>>> >>>>>>>>>> compatibility, >>>>>>>>>>>> >>>>>>>>>>>>> but that is apparently not working atm. I am >>>>>>>>>>>> having a >>>>>>>>>>>> >>>>>>>> struggle >>>>>>>>>>>> >>>>>>>>>> getting a >>>>>>>>>>>> >>>>>>>>>>>>> mixed JDK build working "just right". >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>>>>>>>>>> >>>>>>>>>> paranoiabla(a)gmail.com&gt; >>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> According to this: >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> Notably the Java 1.7 >>>>>>>>>>>> *ConcurrentHashMap#keySet()* returns a >>>>>>>>>>>> >>>>>>>> Set<K> >>>>>>>>>>>> >>>>>>>>>> while >>>>>>>>>>>> >>>>>>>>>>>>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>>>>>>>>>> >>>>>>>>>>>>>> ConcurrentHashMap.KeySetView<K,V>`. >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> I think you're using some Java8 API. >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>>>>>>>>>> >>>>>>>> paranoiabla(a)gmail.com&gt;: >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ java >>>>>>>>>>>> -version >>>>>>>>>>>> >>>>>>>>>>>>>>> java version "1.7.0_71" >>>>>>>>>>>> >>>>>>>>>>>>>>> Java(TM) SE Runtime Environment (build >>>>>>>>>>>> 1.7.0_71-b14) >>>>>>>>>>>> >>>>>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>>>>>>>> 24.71-b01, mixed >>>>>>>>>>>> >>>>>>>> mode) >>>>>>>>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>>>>>>>>>> >>>>>>>>>>>>>>> Linux petar-ThinkPad-X1-Carbon >>>>>>>>>>>> 3.16.0-33-generic #44-Ubuntu >>>>>>>>>>>> >>>>>>>> SMP Thu >>>>>>>>>>>> >>>>>>>>>> Mar >>>>>>>>>>>> >>>>>>>>>>>>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 >>>>>>>>>>>> GNU/Linux >>>>>>>>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>>>>>>>>>> >>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> What JRE are you trying to use? This error: >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: >>>>>>>>>>>> java.util.concurrent. >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>>>>>>>>>> >>>>>>>>>>>>>>>> ConcurrentHashMap$KeySetView; >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> is indicative of an issue in cross-jre >>>>>>>>>>>> support due to a >>>>>>>>>>>> >>>>>>>> change >>>>>>>>>>>> >>>>>>>>>>>>>>>> internal to java classes. >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar >>>>>>>>>>>> Tahchiev < >>>>>>>>>>>> >>>>>>>>>> paranoiabla(a)gmail.com >>>>>>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks Steve, >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> I managed to migrate my configuration to the >>>>>>>>>>>> new >>>>>>>>>>>> >>>>>>>>>>>>>>>>> MetamodelImplementor. Now when I run the >>>>>>>>>>>> scema export I >>>>>>>>>>>> >>>>>>>> get a lot >>>>>>>>>>>> >>>>>>>>>> of these >>>>>>>>>>>> >>>>>>>>>>>>>>>>> warning: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> INFO : HHH000400: Using dialect: >>>>>>>>>>>> >>>>>>>>>> org.hibernate.dialect.MySQL5Dialect >>>>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : JDBC Driver reports it stores quoted >>>>>>>>>>>> identifiers >>>>>>>>>>>> >>>>>>>> in both >>>>>>>>>>>> >>>>>>>>>> mixed >>>>>>>>>>>> >>>>>>>>>>>>>>>>> and upper case >>>>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>>>>>>>>>> >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> and when I run some test I get the following >>>>>>>>>>>> exception: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>>>>>>>>>> >>>>>>>>>>>>>>>>> at >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>>>>>>>>>> >>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I am told that the bug does not affect the >>>>>>>>>>>> >>>>>>>> JBoss->Central sync >>>>>>>>>>>> >>>>>>>>>>>>>>>>>> process. So at some point the artifacts >>>>>>>>>>>> should all be >>>>>>>>>>>> >>>>>>>> available >>>>>>>>>>>> >>>>>>>>>> in Central >>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve >>>>>>>>>>>> Ebersole < >>>>>>>>>>>> >>>>>>>>>> steve(a)hibernate.org >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> hibernate-core seems to be the only >>>>>>>>>>>> artifact that is >>>>>>>>>>>> >>>>>>>> available >>>>>>>>>>>> >>>>>>>>>> in >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> JBoss Nexus. >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve >>>>>>>>>>>> Ebersole < >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> So apparently the artifacts / repo issue >>>>>>>>>>>> is a Nexus >>>>>>>>>>>> >>>>>>>> bug that is >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> effecting the JBoss repo (and therefore >>>>>>>>>>>> us)... >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> As I pointed out in the announcement, I >>>>>>>>>>>> am managing the >>>>>>>>>>>> >>>>>>>>>> "migration >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> guide" in source repo while I develop the >>>>>>>>>>>> Betas. See >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> As far are the new bootstrapping apis, see >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar >>>>>>>>>>>> Tahchiev < >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I just tried the latest beta and I >>>>>>>>>>>> cannot compile my >>>>>>>>>>>> >>>>>>>> project. >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> With the >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> latest hibernate 4.3.X I was able to do >>>>>>>>>>>> this: >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ------- >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> final >>>>>>>>>>>> org.hibernate.cfg.Configuration >>>>>>>>>>>> >>>>>>>> configuration = >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> getHibernateConfiguration(); >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> configuration.buildMappings(); >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> final SchemaUpdate schemaUpdate = >>>>>>>>>>>> new >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> SchemaUpdate(configuration); >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ------- >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> however it seems that the SchemaUpdate >>>>>>>>>>>> constructor >>>>>>>>>>>> >>>>>>>> has been >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> removed and now >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> a new one is added: >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -------- >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> public >>>>>>>>>>>> SchemaUpdate(MetadataImplementor metadata) >>>>>>>>>>>> >>>>>>>> { >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> this( >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> metadata ); >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> --------- >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Also the configuration.buildMappings() >>>>>>>>>>>> method has been >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> deprecated. Where do >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I get the MetadataImplementor from? Also >>>>>>>>>>>> is there any >>>>>>>>>>>> >>>>>>>>>> changelog I >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> can refer >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> to? >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 >>>>>>>>>>>> CDFF 55A5 1965 >>>>>>>>>>>> >>>>>>>> 8550 C311 >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 0611 >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>>>> >>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>>> >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>>> >>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF >>>>>>>>>>>> 55A5 1965 8550 >>>>>>>>>>>> >>>>>>>> C311 >>>>>>>>>>>> >>>>>>>>>> 0611 >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>>>> >>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>>> >>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF >>>>>>>>>>>> 55A5 1965 8550 >>>>>>>>>>>> >>>>>>>> C311 0611 >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>>>> >>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>>> >>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>>>>>>>>>>> 1965 8550 >>>>>>>>>>>> >>>>>>>> C311 0611 >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>> hibernate-dev mailing list >>>>>>>>>>>> >>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >> >>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>> > hibernate-dev mailing list >>>>>>>>>>>> > hibernate-dev(a)lists.jboss.org >>>>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Regards, Petar! >>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>> --- >>>>>>>>>>> Public PGP Key at: >>>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >>>>>>>>>>> 0611 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards, Petar! >>>>>>>>> Karlovo, Bulgaria. >>>>>>>>> --- >>>>>>>>> Public PGP Key at: >>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >>>>>>>>> 0611 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, Petar! >>>>> Karlovo, Bulgaria. >>>>> --- >>>>> Public PGP Key at: >>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>> >>>> >>>> >>> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> > >

2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: > Just to clarify... I *think* that as long as we run the build with Java 8 > and set the bootclasspath to 6 or 7 we should be fine. > Yes, setting the boot classpath to 6 (or 7) makes sure you only use classes present in that JDK (be it explicitly or implicitly as in the ConcurrentHashMap case), because it's that class library which will be used for compilation then. It is cumbersome to use though as you need to specify the location of a 6 or 7 JDK which makes the build less easily portable between machines. Currently, AnimalSniffer is in place to prevent this very category of error and I'm wondering why it didn't detect the "usage" of KeySetView. It really should have detected it, assuming it analyses the byte code of classes. But this makes me wonder now whether it only analyses the source code actually. Then it wouldn't be usable to prevent this sort of issue. Coding against the ConcurrentMap interface is the best way to avoid the issue. But of course there is no guarantee that it happens again, unless e.g. having a build on CI which uses 6 or 7 on its boot classpath. > On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > > > Well the idea is to run the Gradle process with Java 8 (the build itself > > is a Java process too don't forget). We pass in the older JDK > specifically > > to be able to set the bootclasspath for compilation and the executable > for > > running tests. That's the theory. > > > > Interestingly I developed a simplified project to test these theories: > > https://github.com/sebersole/gradle-mixed-jdk And of course this all > > works there. As you'd expect right? > > > > I think the JAXB thing comes into play here as well. Gradle does not > have > > any XJC support built in, so we have to make use of its Ant support to > run > > the XJC Ant tasks for JAXB model generation. The problem there is that, > > afaik, there is no way to tell Gradle's AntBuilder to use a JDK other > than > > the one that launched Gradle. I think this is why we see a JAXB model > > defined for Java 7, rather than Java 6, because we essentially run XJC > with > > Java 8. > > > > Anyway, this certainly makes the build more complex and we definitely > have > > to think through all these scenarios. In fact after Beta1, one of my > todos > > is to build up the build "from scratch" using that gradle-mixed-jdk > project > > as a basis. > > > > In general the plan though is to run all the tests (other than > > hibernate-java8, obviously) with the "baseline JDK, whether that be Java > 6 > > or 7. > > > > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; > > wrote: > > > >> There are many similar issues discussed on the Lucene developer's > >> mailing list, it's an interesting read: > >> - > >> > http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... > >> > >> I see no alternative than to have those test jobs actually exercising > >> ORM with JDK6, or maybe even compile it all with JDK6 except the Java8 > >> additional module to be compiled with JDK8 ? > >> > >> > >> > >> On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > >> > Ahh, seems this may be an option to work around it: > >> > > >> > <quote> > >> > Using the general *Map* interface in place of the concrete > >> > *ConcurrentHashMap* type here side-steps the coupling to the Java 8 > >> return > >> > type and will allow this code to be compiled with Java 8 and run on > >> Java 7. > >> > </quote> > >> > > >> > I had missed that part. > >> > > >> > > >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < steve(a)hibernate.org&gt; > >> wrote: > >> > > >> >> When I say "internal" here, I mean internal to java classes. > >> >> > >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < steve(a)hibernate.org > > > >> >> wrote: > >> >> > >> >>> Nope. It just effects any code compiled with Java 8 even though the > >> >>> change is internal. The problem is the generated bytecode > >> incorporates > >> >>> this change. Like I said, this should be compiled with 1.6 > >> compatibility, > >> >>> but that is apparently not working atm. I am having a struggle > >> getting a > >> >>> mixed JDK build working "just right". > >> >>> > >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < > >> paranoiabla(a)gmail.com&gt; > >> >>> wrote: > >> >>> > >> >>>> According to this: > >> >>>> > >> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 > >> >>>> > >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K> > >> while > >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a > >> >>>> ConcurrentHashMap.KeySetView<K,V>`. > >> >>>> > >> >>>> I think you're using some Java8 API. > >> >>>> > >> >>>> > >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com >: > >> >>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version > >> >>>>> java version "1.7.0_71" > >> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) > >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a > >> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP > Thu > >> Mar > >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ > >> >>>>> > >> >>>>> > >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> >>>>> > >> >>>>>> What JRE are you trying to use? This error: > >> >>>>>> > >> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. > >> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ > >> >>>>>> ConcurrentHashMap$KeySetView; > >> >>>>>> > >> >>>>>> is indicative of an issue in cross-jre support due to a change > >> >>>>>> internal to java classes. > >> >>>>>> > >> >>>>>> > >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < > >> paranoiabla(a)gmail.com > >> >>>>>> > wrote: > >> >>>>>> > >> >>>>>>> Thanks Steve, > >> >>>>>>> > >> >>>>>>> I managed to migrate my configuration to the new > >> >>>>>>> MetamodelImplementor. Now when I run the scema export I get a > lot > >> of these > >> >>>>>>> warning: > >> >>>>>>> > >> >>>>>>> INFO : HHH000400: Using dialect: > >> org.hibernate.dialect.MySQL5Dialect > >> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both > >> mixed > >> >>>>>>> and upper case > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: > >> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: > >> >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: > >> >>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: > >> >>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: > >> >>>>>>> > >> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: > >> >>>>>>> > com.xxx.platform.module.search.core.model.SearchPageRedirectModel > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: > >> >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel > >> >>>>>>> > >> >>>>>>> and when I run some test I get the following exception: > >> >>>>>>> java.lang.NoSuchMethodError: > >> >>>>>>> > >> > java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; > >> >>>>>>> at > >> >>>>>>> > >> > org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) > >> >>>>>>> at > >> >>>>>>> > >> > org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) > >> >>>>>>> at > >> >>>>>>> > >> > org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) > >> >>>>>>> at > >> >>>>>>> > >> > org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) > >> >>>>>>> at > >> >>>>>>> > >> > org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) > >> >>>>>>> at > >> >>>>>>> > >> > org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) > >> >>>>>>> at > >> >>>>>>> > org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) > >> >>>>>>> at > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) > >> >>>>>>> at > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) > >> >>>>>>> at > >> >>>>>>> > >> > org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) > >> >>>>>>> at > >> >>>>>>> > >> > org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) > >> >>>>>>> at > >> >>>>>>> > >> > org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve(a)hibernate.org >: > >> >>>>>>> > >> >>>>>>>> I am told that the bug does not affect the JBoss->Central sync > >> >>>>>>>> process. So at some point the artifacts should all be > available > >> in Central > >> >>>>>>>> > >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < > >> steve(a)hibernate.org > >> >>>>>>>> > wrote: > >> >>>>>>>> > >> >>>>>>>>> hibernate-core seems to be the only artifact that is available > >> in > >> >>>>>>>>> JBoss Nexus. > >> >>>>>>>>> > >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < > >> >>>>>>>>> steve(a)hibernate.org&gt; wrote: > >> >>>>>>>>> > >> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug that > is > >> >>>>>>>>>> effecting the JBoss repo (and therefore us)... > >> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 > >> >>>>>>>>>> > >> >>>>>>>>>> As I pointed out in the announcement, I am managing the > >> "migration > >> >>>>>>>>>> guide" in source repo while I develop the Betas. See > >> >>>>>>>>>> > >> > https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... > >> >>>>>>>>>> As far are the new bootstrapping apis, see > >> >>>>>>>>>> > >> > http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... > >> >>>>>>>>>> and > >> >>>>>>>>>> > >> > http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... > >> >>>>>>>>>> > >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < > >> >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: > >> >>>>>>>>>> > >> >>>>>>>>>>> Hi guys, > >> >>>>>>>>>>> > >> >>>>>>>>>>> I just tried the latest beta and I cannot compile my > project. > >> >>>>>>>>>>> With the > >> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: > >> >>>>>>>>>>> ------- > >> >>>>>>>>>>> final org.hibernate.cfg.Configuration configuration > = > >> >>>>>>>>>>> getHibernateConfiguration(); > >> >>>>>>>>>>> configuration.buildMappings(); > >> >>>>>>>>>>> final SchemaUpdate schemaUpdate = new > >> >>>>>>>>>>> SchemaUpdate(configuration); > >> >>>>>>>>>>> ------- > >> >>>>>>>>>>> > >> >>>>>>>>>>> however it seems that the SchemaUpdate constructor has been > >> >>>>>>>>>>> removed and now > >> >>>>>>>>>>> a new one is added: > >> >>>>>>>>>>> -------- > >> >>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) { > >> >>>>>>>>>>> this( > >> >>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), > >> >>>>>>>>>>> metadata ); > >> >>>>>>>>>>> } > >> >>>>>>>>>>> --------- > >> >>>>>>>>>>> > >> >>>>>>>>>>> Also the configuration.buildMappings() method has been > >> >>>>>>>>>>> deprecated. Where do > >> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any > >> changelog I > >> >>>>>>>>>>> can refer > >> >>>>>>>>>>> to? > >> >>>>>>>>>>> > >> >>>>>>>>>>> Thanks. > >> >>>>>>>>>>> -- > >> >>>>>>>>>>> Regards, Petar! > >> >>>>>>>>>>> Karlovo, Bulgaria. > >> >>>>>>>>>>> --- > >> >>>>>>>>>>> Public PGP Key at: > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 > C311 > >> >>>>>>>>>>> 0611 > >> >>>>>>>>>>> _______________________________________________ > >> >>>>>>>>>>> hibernate-dev mailing list > >> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org > >> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >>>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> -- > >> >>>>>>> Regards, Petar! > >> >>>>>>> Karlovo, Bulgaria. > >> >>>>>>> --- > >> >>>>>>> Public PGP Key at: > >> >>>>>>> > >> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 > >> 0611 > >> >>>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>>>> -- > >> >>>>> Regards, Petar! > >> >>>>> Karlovo, Bulgaria. > >> >>>>> --- > >> >>>>> Public PGP Key at: > >> >>>>> > >> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 > 0611 > >> >>>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> -- > >> >>>> Regards, Petar! > >> >>>> Karlovo, Bulgaria. > >> >>>> --- > >> >>>> Public PGP Key at: > >> >>>> > >> > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > >> >>>> > >> >>> > >> >>> > >> >> > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Oh, and one last thing: I don't think this is fixed: https://hibernate.atlassian.net/browse/HHH-8805 Here's my mapping: @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, fetch = FetchType.LAZY) @JoinTable(indexes = { @Index(unique = false, columnList = "entity_pk") }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), inverseJoinColumns = { @JoinColumn(unique = false, nullable = true, insertable = true, updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "filter_pk") }, joinColumns = { @JoinColumn(unique = false, nullable = true, insertable = true, updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "entity_pk") }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "entity_filters") private Collection<AbstractFilterModelDefinition> filters; As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it is possible to add it. However here's what the schema tool generates: create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters (entity_pk); alter table entity_filters add constraint FKra38l70n01disvkge7i9ff5ym foreign key (filter_pk) references abstract_filter (pk); alter table entity_filters add constraint FKderx50xtd0lkeeblrj3o0ipq9 foreign key (entity_pk) references stock_level (pk); alter table entity_filters add constraint FK7ery3yx4pg32ogvv1wpr150oq foreign key (entity_pk) references content_slot (pk); alter table entity_filters add constraint FKse5m2mj7rrwj8ndimynfnr2px foreign key (entity_pk) references blog_entry (pk); alter table entity_filters add constraint FK9nubqtdhrmefjv2a5oab2fcr2 foreign key (entity_pk) references price (pk); alter table entity_filters add constraint FKcsuwqm524wu4u41oatrcalxvh foreign key (entity_pk) references tax (pk); alter table entity_filters add constraint FKmd3mm5pw9naa05ype38m6x1eo foreign key (entity_pk) references abstract_template (pk); alter table entity_filters add constraint FKsx6vnh2tga70pkne44dnq8kp0 foreign key (entity_pk) references discount (pk); alter table entity_filters add constraint FK6yx2wc1w1yb6qa1cx4byv7mju foreign key (entity_pk) references classification_feature (pk); alter table entity_filters add constraint FKpoh168do203hfqwb7so7c4c79 foreign key (entity_pk) references cms_navigation_node (pk); alter table entity_filters add constraint FKi85fkvbm7otl679ijlr6oyoff foreign key (entity_pk) references product (pk); alter table entity_filters add constraint FKi8semxf3lq0n12lm05v7oydeq foreign key (entity_pk) references abstract_page (pk); alter table entity_filters add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b foreign key (entity_pk) references promotion (pk); alter table entity_filters add constraint FKfw64whfl6vgbqehj20qmc39i3 foreign key (entity_pk) references simple_cms_widget (pk); The foreign keys are all different (in Hibernate 4.3.x they were the same), but I just don't want them. Shall I reopen the issue? 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com&gt;: > One other thing I noticed: > hibernate-core-5 depends on > > <groupId>org.jboss.logging</groupId> > <artifactId>jboss-logging</artifactId> > <version>3.2.1.Final</version> > > and if you have hibernate-validator 5.1.3.Final (the last stable), it > will depend on > > <groupId>org.jboss.logging</groupId> > <artifactId>jboss-logging</artifactId> > <version>3.1.4.GA</version> > > So you will get an exception of method not found on some jboss-logging > API. I excluded the jboss-loggin from the hibernate-validator > dependency, but now I get a ton of these TRACE statements (literally > every millisecond): > > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > > > But at least it works.. I guess the only real solution is to have > hibernate-validator use the same jboss-logging version. > > > 2015-04-01 10:39 GMT+03:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: > >> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >> > Just to clarify... I *think* that as long as we run the build with >> Java 8 >> > and set the bootclasspath to 6 or 7 we should be fine. >> > >> >> Yes, setting the boot classpath to 6 (or 7) makes sure you only use >> classes >> present in that JDK (be it explicitly or implicitly as in the >> ConcurrentHashMap case), because it's that class library which will be >> used >> for compilation then. It is cumbersome to use though as you need to >> specify >> the location of a 6 or 7 JDK which makes the build less easily portable >> between machines. >> >> Currently, AnimalSniffer is in place to prevent this very category of >> error >> and I'm wondering why it didn't detect the "usage" of KeySetView. It >> really >> should have detected it, assuming it analyses the byte code of classes. >> But >> this makes me wonder now whether it only analyses the source code >> actually. >> Then it wouldn't be usable to prevent this sort of issue. >> >> Coding against the ConcurrentMap interface is the best way to avoid the >> issue. But of course there is no guarantee that it happens again, unless >> e.g. having a build on CI which uses 6 or 7 on its boot classpath. >> >> >> > On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole <steve(a)hibernate.org&gt; >> > wrote: >> > >> > > Well the idea is to run the Gradle process with Java 8 (the build >> itself >> > > is a Java process too don't forget). We pass in the older JDK >> > specifically >> > > to be able to set the bootclasspath for compilation and the >> executable >> > for >> > > running tests. That's the theory. >> > > >> > > Interestingly I developed a simplified project to test these >> theories: >> > > https://github.com/sebersole/gradle-mixed-jdk And of course this >> all >> > > works there. As you'd expect right? >> > > >> > > I think the JAXB thing comes into play here as well. Gradle does not >> > have >> > > any XJC support built in, so we have to make use of its Ant support >> to >> > run >> > > the XJC Ant tasks for JAXB model generation. The problem there is >> that, >> > > afaik, there is no way to tell Gradle's AntBuilder to use a JDK other >> > than >> > > the one that launched Gradle. I think this is why we see a JAXB >> model >> > > defined for Java 7, rather than Java 6, because we essentially run >> XJC >> > with >> > > Java 8. >> > > >> > > Anyway, this certainly makes the build more complex and we definitely >> > have >> > > to think through all these scenarios. In fact after Beta1, one of my >> > todos >> > > is to build up the build "from scratch" using that gradle-mixed-jdk >> > project >> > > as a basis. >> > > >> > > In general the plan though is to run all the tests (other than >> > > hibernate-java8, obviously) with the "baseline JDK, whether that be >> Java >> > 6 >> > > or 7. >> > > >> > > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >> sanne(a)hibernate.org&gt; >> > > wrote: >> > > >> > >> There are many similar issues discussed on the Lucene developer's >> > >> mailing list, it's an interesting read: >> > >> - >> > >> >> > >> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >> > >> >> > >> I see no alternative than to have those test jobs actually >> exercising >> > >> ORM with JDK6, or maybe even compile it all with JDK6 except the >> Java8 >> > >> additional module to be compiled with JDK8 ? >> > >> >> > >> >> > >> >> > >> On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> > >> > Ahh, seems this may be an option to work around it: >> > >> > >> > >> > <quote> >> > >> > Using the general *Map* interface in place of the concrete >> > >> > *ConcurrentHashMap* type here side-steps the coupling to the Java >> 8 >> > >> return >> > >> > type and will allow this code to be compiled with Java 8 and run >> on >> > >> Java 7. >> > >> > </quote> >> > >> > >> > >> > I had missed that part. >> > >> > >> > >> > >> > >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >> steve(a)hibernate.org&gt; >> > >> wrote: >> > >> > >> > >> >> When I say "internal" here, I mean internal to java classes. >> > >> >> >> > >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >> steve(a)hibernate.org >> > > >> > >> >> wrote: >> > >> >> >> > >> >>> Nope. It just effects any code compiled with Java 8 even >> though the >> > >> >>> change is internal. The problem is the generated bytecode >> > >> incorporates >> > >> >>> this change. Like I said, this should be compiled with 1.6 >> > >> compatibility, >> > >> >>> but that is apparently not working atm. I am having a struggle >> > >> getting a >> > >> >>> mixed JDK build working "just right". >> > >> >>> >> > >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >> > >> paranoiabla(a)gmail.com&gt; >> > >> >>> wrote: >> > >> >>> >> > >> >>>> According to this: >> > >> >>>> >> > >> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >> > >> >>>> >> > >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a >> Set<K> >> > >> while >> > >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a >> > >> >>>> ConcurrentHashMap.KeySetView<K,V>`. >> > >> >>>> >> > >> >>>> I think you're using some Java8 API. >> > >> >>>> >> > >> >>>> >> > >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >> paranoiabla(a)gmail.com&gt;: >> > >> >>>> >> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >> > >> >>>>> java version "1.7.0_71" >> > >> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >> > >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed >> mode) >> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >> > >> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu >> SMP >> > Thu >> > >> Mar >> > >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve(a)hibernate.org >> >: >> > >> >>>>> >> > >> >>>>>> What JRE are you trying to use? This error: >> > >> >>>>>> >> > >> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >> > >> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >> > >> >>>>>> ConcurrentHashMap$KeySetView; >> > >> >>>>>> >> > >> >>>>>> is indicative of an issue in cross-jre support due to a >> change >> > >> >>>>>> internal to java classes. >> > >> >>>>>> >> > >> >>>>>> >> > >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >> > >> paranoiabla(a)gmail.com >> > >> >>>>>> > wrote: >> > >> >>>>>> >> > >> >>>>>>> Thanks Steve, >> > >> >>>>>>> >> > >> >>>>>>> I managed to migrate my configuration to the new >> > >> >>>>>>> MetamodelImplementor. Now when I run the scema export I get >> a >> > lot >> > >> of these >> > >> >>>>>>> warning: >> > >> >>>>>>> >> > >> >>>>>>> INFO : HHH000400: Using dialect: >> > >> org.hibernate.dialect.MySQL5Dialect >> > >> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in >> both >> > >> mixed >> > >> >>>>>>> and upper case >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> >> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> >> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> >> > >> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> >> > com.xxx.platform.module.search.core.model.SearchPageRedirectModel >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >> > >> >>>>>>> >> > >> >>>>>>> and when I run some test I get the following exception: >> > >> >>>>>>> java.lang.NoSuchMethodError: >> > >> >>>>>>> >> > >> >> > >> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >> > >> >>>>>>> at >> > >> >>>>>>> >> > org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >> > >> >>>>>>> at >> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >> > >> >>>>>>> at >> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >> > >> >>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >> steve(a)hibernate.org&gt;: >> > >> >>>>>>> >> > >> >>>>>>>> I am told that the bug does not affect the JBoss->Central >> sync >> > >> >>>>>>>> process. So at some point the artifacts should all be >> > available >> > >> in Central >> > >> >>>>>>>> >> > >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >> > >> steve(a)hibernate.org >> > >> >>>>>>>> > wrote: >> > >> >>>>>>>> >> > >> >>>>>>>>> hibernate-core seems to be the only artifact that is >> available >> > >> in >> > >> >>>>>>>>> JBoss Nexus. >> > >> >>>>>>>>> >> > >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >> > >> >>>>>>>>> steve(a)hibernate.org&gt; wrote: >> > >> >>>>>>>>> >> > >> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug >> that >> > is >> > >> >>>>>>>>>> effecting the JBoss repo (and therefore us)... >> > >> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> As I pointed out in the announcement, I am managing the >> > >> "migration >> > >> >>>>>>>>>> guide" in source repo while I develop the Betas. See >> > >> >>>>>>>>>> >> > >> >> > >> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >> > >> >>>>>>>>>> As far are the new bootstrapping apis, see >> > >> >>>>>>>>>> >> > >> >> > >> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >> > >> >>>>>>>>>> and >> > >> >>>>>>>>>> >> > >> >> > >> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >> > >> >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >> > >> >>>>>>>>>> >> > >> >>>>>>>>>>> Hi guys, >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> I just tried the latest beta and I cannot compile my >> > project. >> > >> >>>>>>>>>>> With the >> > >> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >> > >> >>>>>>>>>>> ------- >> > >> >>>>>>>>>>> final org.hibernate.cfg.Configuration >> configuration >> > = >> > >> >>>>>>>>>>> getHibernateConfiguration(); >> > >> >>>>>>>>>>> configuration.buildMappings(); >> > >> >>>>>>>>>>> final SchemaUpdate schemaUpdate = new >> > >> >>>>>>>>>>> SchemaUpdate(configuration); >> > >> >>>>>>>>>>> ------- >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> however it seems that the SchemaUpdate constructor has >> been >> > >> >>>>>>>>>>> removed and now >> > >> >>>>>>>>>>> a new one is added: >> > >> >>>>>>>>>>> -------- >> > >> >>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) { >> > >> >>>>>>>>>>> this( >> > >> >>>>>>>>>>> >> metadata.getMetadataBuildingOptions().getServiceRegistry(), >> > >> >>>>>>>>>>> metadata ); >> > >> >>>>>>>>>>> } >> > >> >>>>>>>>>>> --------- >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> Also the configuration.buildMappings() method has been >> > >> >>>>>>>>>>> deprecated. Where do >> > >> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any >> > >> changelog I >> > >> >>>>>>>>>>> can refer >> > >> >>>>>>>>>>> to? >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> Thanks. >> > >> >>>>>>>>>>> -- >> > >> >>>>>>>>>>> Regards, Petar! >> > >> >>>>>>>>>>> Karlovo, Bulgaria. >> > >> >>>>>>>>>>> --- >> > >> >>>>>>>>>>> Public PGP Key at: >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> >> > >> >> > >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> > >> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >> 8550 >> > C311 >> > >> >>>>>>>>>>> 0611 >> > >> >>>>>>>>>>> _______________________________________________ >> > >> >>>>>>>>>>> hibernate-dev mailing list >> > >> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >> > >> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> >> > >> >>>>>>>>> >> > >> >>>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> -- >> > >> >>>>>>> Regards, Petar! >> > >> >>>>>>> Karlovo, Bulgaria. >> > >> >>>>>>> --- >> > >> >>>>>>> Public PGP Key at: >> > >> >>>>>>> >> > >> >> > >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> > >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >> C311 >> > >> 0611 >> > >> >>>>>>> >> > >> >>>>>> >> > >> >>>>>> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> -- >> > >> >>>>> Regards, Petar! >> > >> >>>>> Karlovo, Bulgaria. >> > >> >>>>> --- >> > >> >>>>> Public PGP Key at: >> > >> >>>>> >> > >> >> > >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> > >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >> > 0611 >> > >> >>>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> -- >> > >> >>>> Regards, Petar! >> > >> >>>> Karlovo, Bulgaria. >> > >> >>>> --- >> > >> >>>> Public PGP Key at: >> > >> >>>> >> > >> >> > >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> > >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >> 0611 >> > >> >>>> >> > >> >>> >> > >> >>> >> > >> >> >> > >> > _______________________________________________ >> > >> > hibernate-dev mailing list >> > >> > hibernate-dev(a)lists.jboss.org >> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> >> > > >> > > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611

And no, we generally do not reopen issues from Closed state. And here, given the different branches, I'd be more inclined to create a different issue referencing the original. On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Hmm, it seems I inadvertently set the wrong fix version on HHH-8805. It > is fixed in our metamodel branch which is 6.0. I pulled the necessary > metamodel (org.hibernate.mapping) changes back to master (5.0), but only > the hbm.xml form of naming the FK "none" (magic value) is supported to > truly disable generation. For the time being you can use this as well from > annotations; just name the FK "none". > > If you can write some tests for this, it will make it easier for me to > implement. > > > > On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; > wrote: > >> Oh, >> >> and one last thing: I don't think this is fixed: >> https://hibernate.atlassian.net/browse/HHH-8805 >> >> Here's my mapping: >> >> @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = { >> CascadeType.PERSIST, >> CascadeType.MERGE, >> CascadeType.REFRESH >> }, fetch = FetchType.LAZY) >> @JoinTable(indexes = { >> @Index(unique = false, columnList = "entity_pk") >> }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), >> inverseJoinColumns = { >> @JoinColumn(unique = false, nullable = true, insertable = true, >> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), >> name = "filter_pk") >> }, joinColumns = { >> @JoinColumn(unique = false, nullable = true, insertable = true, >> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), >> name = "entity_pk") >> }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = >> "entity_filters") >> private Collection<AbstractFilterModelDefinition> filters; >> >> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it is >> possible to add it. However here's what the schema tool generates: >> >> create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters >> (entity_pk); >> >> alter table entity_filters >> add constraint FKra38l70n01disvkge7i9ff5ym >> foreign key (filter_pk) >> references abstract_filter (pk); >> >> alter table entity_filters >> add constraint FKderx50xtd0lkeeblrj3o0ipq9 >> foreign key (entity_pk) >> references stock_level (pk); >> >> alter table entity_filters >> add constraint FK7ery3yx4pg32ogvv1wpr150oq >> foreign key (entity_pk) >> references content_slot (pk); >> >> alter table entity_filters >> add constraint FKse5m2mj7rrwj8ndimynfnr2px >> foreign key (entity_pk) >> references blog_entry (pk); >> >> alter table entity_filters >> add constraint FK9nubqtdhrmefjv2a5oab2fcr2 >> foreign key (entity_pk) >> references price (pk); >> >> alter table entity_filters >> add constraint FKcsuwqm524wu4u41oatrcalxvh >> foreign key (entity_pk) >> references tax (pk); >> >> alter table entity_filters >> add constraint FKmd3mm5pw9naa05ype38m6x1eo >> foreign key (entity_pk) >> references abstract_template (pk); >> >> alter table entity_filters >> add constraint FKsx6vnh2tga70pkne44dnq8kp0 >> foreign key (entity_pk) >> references discount (pk); >> >> alter table entity_filters >> add constraint FK6yx2wc1w1yb6qa1cx4byv7mju >> foreign key (entity_pk) >> references classification_feature (pk); >> >> alter table entity_filters >> add constraint FKpoh168do203hfqwb7so7c4c79 >> foreign key (entity_pk) >> references cms_navigation_node (pk); >> >> alter table entity_filters >> add constraint FKi85fkvbm7otl679ijlr6oyoff >> foreign key (entity_pk) >> references product (pk); >> >> alter table entity_filters >> add constraint FKi8semxf3lq0n12lm05v7oydeq >> foreign key (entity_pk) >> references abstract_page (pk); >> >> alter table entity_filters >> add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b >> foreign key (entity_pk) >> references promotion (pk); >> >> alter table entity_filters >> add constraint FKfw64whfl6vgbqehj20qmc39i3 >> foreign key (entity_pk) >> references simple_cms_widget (pk); >> >> The foreign keys are all different (in Hibernate 4.3.x they were the >> same), but I just don't want them. Shall I reopen the issue? >> >> >> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com&gt;: >> >>> One other thing I noticed: >>> hibernate-core-5 depends on >>> >>> <groupId>org.jboss.logging</groupId> >>> <artifactId>jboss-logging</artifactId> >>> <version>3.2.1.Final</version> >>> >>> and if you have hibernate-validator 5.1.3.Final (the last stable), it >>> will depend on >>> >>> <groupId>org.jboss.logging</groupId> >>> <artifactId>jboss-logging</artifactId> >>> <version>3.1.4.GA</version> >>> >>> So you will get an exception of method not found on some jboss-logging >>> API. I excluded the jboss-loggin from the hibernate-validator >>> dependency, but now I get a ton of these TRACE statements (literally >>> every millisecond): >>> >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> >>> >>> But at least it works.. I guess the only real solution is to have >>> hibernate-validator use the same jboss-logging version. >>> >>> >>> 2015-04-01 10:39 GMT+03:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: >>> >>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> >>>> > Just to clarify... I *think* that as long as we run the build with >>>> Java 8 >>>> > and set the bootclasspath to 6 or 7 we should be fine. >>>> > >>>> >>>> Yes, setting the boot classpath to 6 (or 7) makes sure you only use >>>> classes >>>> present in that JDK (be it explicitly or implicitly as in the >>>> ConcurrentHashMap case), because it's that class library which will be >>>> used >>>> for compilation then. It is cumbersome to use though as you need to >>>> specify >>>> the location of a 6 or 7 JDK which makes the build less easily portable >>>> between machines. >>>> >>>> Currently, AnimalSniffer is in place to prevent this very category of >>>> error >>>> and I'm wondering why it didn't detect the "usage" of KeySetView. It >>>> really >>>> should have detected it, assuming it analyses the byte code of >>>> classes. But >>>> this makes me wonder now whether it only analyses the source code >>>> actually. >>>> Then it wouldn't be usable to prevent this sort of issue. >>>> >>>> Coding against the ConcurrentMap interface is the best way to avoid the >>>> issue. But of course there is no guarantee that it happens again, >>>> unless >>>> e.g. having a build on CI which uses 6 or 7 on its boot classpath. >>>> >>>> >>>> > On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole <steve(a)hibernate.org >>>> > >>>> > wrote: >>>> > >>>> > > Well the idea is to run the Gradle process with Java 8 (the build >>>> itself >>>> > > is a Java process too don't forget). We pass in the older JDK >>>> > specifically >>>> > > to be able to set the bootclasspath for compilation and the >>>> executable >>>> > for >>>> > > running tests. That's the theory. >>>> > > >>>> > > Interestingly I developed a simplified project to test these >>>> theories: >>>> > > https://github.com/sebersole/gradle-mixed-jdk And of course this >>>> all >>>> > > works there. As you'd expect right? >>>> > > >>>> > > I think the JAXB thing comes into play here as well. Gradle does >>>> not >>>> > have >>>> > > any XJC support built in, so we have to make use of its Ant >>>> support to >>>> > run >>>> > > the XJC Ant tasks for JAXB model generation. The problem there is >>>> that, >>>> > > afaik, there is no way to tell Gradle's AntBuilder to use a JDK >>>> other >>>> > than >>>> > > the one that launched Gradle. I think this is why we see a JAXB >>>> model >>>> > > defined for Java 7, rather than Java 6, because we essentially run >>>> XJC >>>> > with >>>> > > Java 8. >>>> > > >>>> > > Anyway, this certainly makes the build more complex and we >>>> definitely >>>> > have >>>> > > to think through all these scenarios. In fact after Beta1, one of >>>> my >>>> > todos >>>> > > is to build up the build "from scratch" using that gradle-mixed-jdk >>>> > project >>>> > > as a basis. >>>> > > >>>> > > In general the plan though is to run all the tests (other than >>>> > > hibernate-java8, obviously) with the "baseline JDK, whether that >>>> be Java >>>> > 6 >>>> > > or 7. >>>> > > >>>> > > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>> sanne(a)hibernate.org&gt; >>>> > > wrote: >>>> > > >>>> > >> There are many similar issues discussed on the Lucene developer's >>>> > >> mailing list, it's an interesting read: >>>> > >> - >>>> > >> >>>> > >>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>> > >> >>>> > >> I see no alternative than to have those test jobs actually >>>> exercising >>>> > >> ORM with JDK6, or maybe even compile it all with JDK6 except the >>>> Java8 >>>> > >> additional module to be compiled with JDK8 ? >>>> > >> >>>> > >> >>>> > >> >>>> > >> On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> > >> > Ahh, seems this may be an option to work around it: >>>> > >> > >>>> > >> > <quote> >>>> > >> > Using the general *Map* interface in place of the concrete >>>> > >> > *ConcurrentHashMap* type here side-steps the coupling to the >>>> Java 8 >>>> > >> return >>>> > >> > type and will allow this code to be compiled with Java 8 and >>>> run on >>>> > >> Java 7. >>>> > >> > </quote> >>>> > >> > >>>> > >> > I had missed that part. >>>> > >> > >>>> > >> > >>>> > >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>> steve(a)hibernate.org&gt; >>>> > >> wrote: >>>> > >> > >>>> > >> >> When I say "internal" here, I mean internal to java classes. >>>> > >> >> >>>> > >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>> steve(a)hibernate.org >>>> > > >>>> > >> >> wrote: >>>> > >> >> >>>> > >> >>> Nope. It just effects any code compiled with Java 8 even >>>> though the >>>> > >> >>> change is internal. The problem is the generated bytecode >>>> > >> incorporates >>>> > >> >>> this change. Like I said, this should be compiled with 1.6 >>>> > >> compatibility, >>>> > >> >>> but that is apparently not working atm. I am having a >>>> struggle >>>> > >> getting a >>>> > >> >>> mixed JDK build working "just right". >>>> > >> >>> >>>> > >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>> > >> paranoiabla(a)gmail.com&gt; >>>> > >> >>> wrote: >>>> > >> >>> >>>> > >> >>>> According to this: >>>> > >> >>>> >>>> > >> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>> > >> >>>> >>>> > >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a >>>> Set<K> >>>> > >> while >>>> > >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>> > >> >>>> ConcurrentHashMap.KeySetView<K,V>`. >>>> > >> >>>> >>>> > >> >>>> I think you're using some Java8 API. >>>> > >> >>>> >>>> > >> >>>> >>>> > >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>> paranoiabla(a)gmail.com&gt;: >>>> > >> >>>> >>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>> > >> >>>>> java version "1.7.0_71" >>>> > >> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>> > >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed >>>> mode) >>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>> > >> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu >>>> SMP >>>> > Thu >>>> > >> Mar >>>> > >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>> steve(a)hibernate.org&gt;: >>>> > >> >>>>> >>>> > >> >>>>>> What JRE are you trying to use? This error: >>>> > >> >>>>>> >>>> > >> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>> > >> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>> > >> >>>>>> ConcurrentHashMap$KeySetView; >>>> > >> >>>>>> >>>> > >> >>>>>> is indicative of an issue in cross-jre support due to a >>>> change >>>> > >> >>>>>> internal to java classes. >>>> > >> >>>>>> >>>> > >> >>>>>> >>>> > >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>> > >> paranoiabla(a)gmail.com >>>> > >> >>>>>> > wrote: >>>> > >> >>>>>> >>>> > >> >>>>>>> Thanks Steve, >>>> > >> >>>>>>> >>>> > >> >>>>>>> I managed to migrate my configuration to the new >>>> > >> >>>>>>> MetamodelImplementor. Now when I run the scema export I >>>> get a >>>> > lot >>>> > >> of these >>>> > >> >>>>>>> warning: >>>> > >> >>>>>>> >>>> > >> >>>>>>> INFO : HHH000400: Using dialect: >>>> > >> org.hibernate.dialect.MySQL5Dialect >>>> > >> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers >>>> in both >>>> > >> mixed >>>> > >> >>>>>>> and upper case >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> > >> >>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> > com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>> > >> >>>>>>> >>>> > >> >>>>>>> and when I run some test I get the following exception: >>>> > >> >>>>>>> java.lang.NoSuchMethodError: >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>> > >> >>>>>>> at >>>> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>> > >> >>>>>>> at >>>> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>> steve(a)hibernate.org&gt;: >>>> > >> >>>>>>> >>>> > >> >>>>>>>> I am told that the bug does not affect the >>>> JBoss->Central sync >>>> > >> >>>>>>>> process. So at some point the artifacts should all be >>>> > available >>>> > >> in Central >>>> > >> >>>>>>>> >>>> > >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>>> > >> steve(a)hibernate.org >>>> > >> >>>>>>>> > wrote: >>>> > >> >>>>>>>> >>>> > >> >>>>>>>>> hibernate-core seems to be the only artifact that is >>>> available >>>> > >> in >>>> > >> >>>>>>>>> JBoss Nexus. >>>> > >> >>>>>>>>> >>>> > >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>> > >> >>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>> > >> >>>>>>>>> >>>> > >> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus >>>> bug that >>>> > is >>>> > >> >>>>>>>>>> effecting the JBoss repo (and therefore us)... >>>> > >> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>>> As I pointed out in the announcement, I am managing the >>>> > >> "migration >>>> > >> >>>>>>>>>> guide" in source repo while I develop the Betas. See >>>> > >> >>>>>>>>>> >>>> > >> >>>> > >>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>> > >> >>>>>>>>>> As far are the new bootstrapping apis, see >>>> > >> >>>>>>>>>> >>>> > >> >>>> > >>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>> > >> >>>>>>>>>> and >>>> > >> >>>>>>>>>> >>>> > >> >>>> > >>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>> > >> >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>>>> Hi guys, >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> I just tried the latest beta and I cannot compile my >>>> > project. >>>> > >> >>>>>>>>>>> With the >>>> > >> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>> > >> >>>>>>>>>>> ------- >>>> > >> >>>>>>>>>>> final org.hibernate.cfg.Configuration >>>> configuration >>>> > = >>>> > >> >>>>>>>>>>> getHibernateConfiguration(); >>>> > >> >>>>>>>>>>> configuration.buildMappings(); >>>> > >> >>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>> > >> >>>>>>>>>>> SchemaUpdate(configuration); >>>> > >> >>>>>>>>>>> ------- >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> however it seems that the SchemaUpdate constructor >>>> has been >>>> > >> >>>>>>>>>>> removed and now >>>> > >> >>>>>>>>>>> a new one is added: >>>> > >> >>>>>>>>>>> -------- >>>> > >> >>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) >>>> { >>>> > >> >>>>>>>>>>> this( >>>> > >> >>>>>>>>>>> >>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>> > >> >>>>>>>>>>> metadata ); >>>> > >> >>>>>>>>>>> } >>>> > >> >>>>>>>>>>> --------- >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> Also the configuration.buildMappings() method has been >>>> > >> >>>>>>>>>>> deprecated. Where do >>>> > >> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any >>>> > >> changelog I >>>> > >> >>>>>>>>>>> can refer >>>> > >> >>>>>>>>>>> to? >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> Thanks. >>>> > >> >>>>>>>>>>> -- >>>> > >> >>>>>>>>>>> Regards, Petar! >>>> > >> >>>>>>>>>>> Karlovo, Bulgaria. >>>> > >> >>>>>>>>>>> --- >>>> > >> >>>>>>>>>>> Public PGP Key at: >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> >>>> > >> >>>> > >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> > >> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>> 8550 >>>> > C311 >>>> > >> >>>>>>>>>>> 0611 >>>> > >> >>>>>>>>>>> _______________________________________________ >>>> > >> >>>>>>>>>>> hibernate-dev mailing list >>>> > >> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>> > >> >>>>>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>> >>>> > >> >>>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> -- >>>> > >> >>>>>>> Regards, Petar! >>>> > >> >>>>>>> Karlovo, Bulgaria. >>>> > >> >>>>>>> --- >>>> > >> >>>>>>> Public PGP Key at: >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> > >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>> C311 >>>> > >> 0611 >>>> > >> >>>>>>> >>>> > >> >>>>>> >>>> > >> >>>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> -- >>>> > >> >>>>> Regards, Petar! >>>> > >> >>>>> Karlovo, Bulgaria. >>>> > >> >>>>> --- >>>> > >> >>>>> Public PGP Key at: >>>> > >> >>>>> >>>> > >> >>>> > >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> > >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>> C311 >>>> > 0611 >>>> > >> >>>>> >>>> > >> >>>> >>>> > >> >>>> >>>> > >> >>>> >>>> > >> >>>> -- >>>> > >> >>>> Regards, Petar! >>>> > >> >>>> Karlovo, Bulgaria. >>>> > >> >>>> --- >>>> > >> >>>> Public PGP Key at: >>>> > >> >>>> >>>> > >> >>>> > >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> > >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>> C311 0611 >>>> > >> >>>> >>>> > >> >>> >>>> > >> >>> >>>> > >> >> >>>> > >> > _______________________________________________ >>>> > >> > hibernate-dev mailing list >>>> > >> > hibernate-dev(a)lists.jboss.org >>>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >> >>>> > > >>>> > > >>>> > _______________________________________________ >>>> > hibernate-dev mailing list >>>> > hibernate-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> >>> >>> -- >>> Regards, Petar! >>> Karlovo, Bulgaria. >>> --- >>> Public PGP Key at: >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>> >> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> > >

OK, maybe I'm doing something wrong. I also tried setting the foreign key name to "none" like this: @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, fetch = FetchType.LAZY) @JoinTable(inverseJoinColumns = { @JoinColumn(unique = false, nullable = true, insertable = true, updatable = true, foreignKey = @ForeignKey(name = "none", value = ConstraintMode.NO_CONSTRAINT), name = "filter_pk") }, indexes = { @Index(unique = false, columnList = "entity_pk") }, inverseForeignKey = @ForeignKey(name = "none", value = ConstraintMode.NO_CONSTRAINT), foreignKey = @ForeignKey(name = "none", value = ConstraintMode.NO_CONSTRAINT), joinColumns = { @JoinColumn(unique = false, nullable = true, insertable = true, updatable = true, foreignKey = @ForeignKey(name = "none", value = ConstraintMode.NO_CONSTRAINT), name = "entity_pk") }, name = "entity_filters") it didn't help - the foreign keys are still generated. I prepared a sample project with 2 tests: 1) will try to create an entity and fail because of the foreign key 2) will export the schema.sql so you can see the foregin keys are still generated. Sample project is here: https://github.com/paranoiabla/HHH-8805 2015-04-01 14:36 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > > https://hibernate.atlassian.net/browse/HHH-8805?focusedCommentId=66093&am... > > On Wed, Apr 1, 2015 at 6:20 AM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> And no, we generally do not reopen issues from Closed state. And here, >> given the different branches, I'd be more inclined to create a different >> issue referencing the original. >> >> On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> Hmm, it seems I inadvertently set the wrong fix version on HHH-8805. >>> It is fixed in our metamodel branch which is 6.0. I pulled the necessary >>> metamodel (org.hibernate.mapping) changes back to master (5.0), but only >>> the hbm.xml form of naming the FK "none" (magic value) is supported to >>> truly disable generation. For the time being you can use this as well from >>> annotations; just name the FK "none". >>> >>> If you can write some tests for this, it will make it easier for me to >>> implement. >>> >>> >>> >>> On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >>> wrote: >>> >>>> Oh, >>>> >>>> and one last thing: I don't think this is fixed: >>>> https://hibernate.atlassian.net/browse/HHH-8805 >>>> >>>> Here's my mapping: >>>> >>>> @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = { >>>> CascadeType.PERSIST, >>>> CascadeType.MERGE, >>>> CascadeType.REFRESH >>>> }, fetch = FetchType.LAZY) >>>> @JoinTable(indexes = { >>>> @Index(unique = false, columnList = "entity_pk") >>>> }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), >>>> inverseJoinColumns = { >>>> @JoinColumn(unique = false, nullable = true, insertable = >>>> true, updatable = true, foreignKey = >>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "filter_pk") >>>> }, joinColumns = { >>>> @JoinColumn(unique = false, nullable = true, insertable = >>>> true, updatable = true, foreignKey = >>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "entity_pk") >>>> }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = >>>> "entity_filters") >>>> private Collection<AbstractFilterModelDefinition> filters; >>>> >>>> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it >>>> is possible to add it. However here's what the schema tool generates: >>>> >>>> create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters >>>> (entity_pk); >>>> >>>> alter table entity_filters >>>> add constraint FKra38l70n01disvkge7i9ff5ym >>>> foreign key (filter_pk) >>>> references abstract_filter (pk); >>>> >>>> alter table entity_filters >>>> add constraint FKderx50xtd0lkeeblrj3o0ipq9 >>>> foreign key (entity_pk) >>>> references stock_level (pk); >>>> >>>> alter table entity_filters >>>> add constraint FK7ery3yx4pg32ogvv1wpr150oq >>>> foreign key (entity_pk) >>>> references content_slot (pk); >>>> >>>> alter table entity_filters >>>> add constraint FKse5m2mj7rrwj8ndimynfnr2px >>>> foreign key (entity_pk) >>>> references blog_entry (pk); >>>> >>>> alter table entity_filters >>>> add constraint FK9nubqtdhrmefjv2a5oab2fcr2 >>>> foreign key (entity_pk) >>>> references price (pk); >>>> >>>> alter table entity_filters >>>> add constraint FKcsuwqm524wu4u41oatrcalxvh >>>> foreign key (entity_pk) >>>> references tax (pk); >>>> >>>> alter table entity_filters >>>> add constraint FKmd3mm5pw9naa05ype38m6x1eo >>>> foreign key (entity_pk) >>>> references abstract_template (pk); >>>> >>>> alter table entity_filters >>>> add constraint FKsx6vnh2tga70pkne44dnq8kp0 >>>> foreign key (entity_pk) >>>> references discount (pk); >>>> >>>> alter table entity_filters >>>> add constraint FK6yx2wc1w1yb6qa1cx4byv7mju >>>> foreign key (entity_pk) >>>> references classification_feature (pk); >>>> >>>> alter table entity_filters >>>> add constraint FKpoh168do203hfqwb7so7c4c79 >>>> foreign key (entity_pk) >>>> references cms_navigation_node (pk); >>>> >>>> alter table entity_filters >>>> add constraint FKi85fkvbm7otl679ijlr6oyoff >>>> foreign key (entity_pk) >>>> references product (pk); >>>> >>>> alter table entity_filters >>>> add constraint FKi8semxf3lq0n12lm05v7oydeq >>>> foreign key (entity_pk) >>>> references abstract_page (pk); >>>> >>>> alter table entity_filters >>>> add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b >>>> foreign key (entity_pk) >>>> references promotion (pk); >>>> >>>> alter table entity_filters >>>> add constraint FKfw64whfl6vgbqehj20qmc39i3 >>>> foreign key (entity_pk) >>>> references simple_cms_widget (pk); >>>> >>>> The foreign keys are all different (in Hibernate 4.3.x they were the >>>> same), but I just don't want them. Shall I reopen the issue? >>>> >>>> >>>> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com&gt;: >>>> >>>>> One other thing I noticed: >>>>> hibernate-core-5 depends on >>>>> >>>>> <groupId>org.jboss.logging</groupId> >>>>> <artifactId>jboss-logging</artifactId> >>>>> <version>3.2.1.Final</version> >>>>> >>>>> and if you have hibernate-validator 5.1.3.Final (the last stable), it >>>>> will depend on >>>>> >>>>> <groupId>org.jboss.logging</groupId> >>>>> <artifactId>jboss-logging</artifactId> >>>>> <version>3.1.4.GA</version> >>>>> >>>>> So you will get an exception of method not found on some >>>>> jboss-logging API. I excluded the jboss-loggin from the hibernate-validator >>>>> dependency, but now I get a ton of these TRACE statements (literally >>>>> every millisecond): >>>>> >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> 2015-04-01 13:28:02,090 >>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>> >>>>> >>>>> But at least it works.. I guess the only real solution is to have >>>>> hibernate-validator use the same jboss-logging version. >>>>> >>>>> >>>>> 2015-04-01 10:39 GMT+03:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: >>>>> >>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>>> >>>>>> > Just to clarify... I *think* that as long as we run the build >>>>>> with Java 8 >>>>>> > and set the bootclasspath to 6 or 7 we should be fine. >>>>>> > >>>>>> >>>>>> Yes, setting the boot classpath to 6 (or 7) makes sure you only use >>>>>> classes >>>>>> present in that JDK (be it explicitly or implicitly as in the >>>>>> ConcurrentHashMap case), because it's that class library which will >>>>>> be used >>>>>> for compilation then. It is cumbersome to use though as you need to >>>>>> specify >>>>>> the location of a 6 or 7 JDK which makes the build less easily >>>>>> portable >>>>>> between machines. >>>>>> >>>>>> Currently, AnimalSniffer is in place to prevent this very category >>>>>> of error >>>>>> and I'm wondering why it didn't detect the "usage" of KeySetView. It >>>>>> really >>>>>> should have detected it, assuming it analyses the byte code of >>>>>> classes. But >>>>>> this makes me wonder now whether it only analyses the source code >>>>>> actually. >>>>>> Then it wouldn't be usable to prevent this sort of issue. >>>>>> >>>>>> Coding against the ConcurrentMap interface is the best way to avoid >>>>>> the >>>>>> issue. But of course there is no guarantee that it happens again, >>>>>> unless >>>>>> e.g. having a build on CI which uses 6 or 7 on its boot classpath. >>>>>> >>>>>> >>>>>> > On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole < >>>>>> steve(a)hibernate.org&gt; >>>>>> > wrote: >>>>>> > >>>>>> > > Well the idea is to run the Gradle process with Java 8 (the >>>>>> build itself >>>>>> > > is a Java process too don't forget). We pass in the older JDK >>>>>> > specifically >>>>>> > > to be able to set the bootclasspath for compilation and the >>>>>> executable >>>>>> > for >>>>>> > > running tests. That's the theory. >>>>>> > > >>>>>> > > Interestingly I developed a simplified project to test these >>>>>> theories: >>>>>> > > https://github.com/sebersole/gradle-mixed-jdk And of course >>>>>> this all >>>>>> > > works there. As you'd expect right? >>>>>> > > >>>>>> > > I think the JAXB thing comes into play here as well. Gradle >>>>>> does not >>>>>> > have >>>>>> > > any XJC support built in, so we have to make use of its Ant >>>>>> support to >>>>>> > run >>>>>> > > the XJC Ant tasks for JAXB model generation. The problem there >>>>>> is that, >>>>>> > > afaik, there is no way to tell Gradle's AntBuilder to use a JDK >>>>>> other >>>>>> > than >>>>>> > > the one that launched Gradle. I think this is why we see a JAXB >>>>>> model >>>>>> > > defined for Java 7, rather than Java 6, because we essentially >>>>>> run XJC >>>>>> > with >>>>>> > > Java 8. >>>>>> > > >>>>>> > > Anyway, this certainly makes the build more complex and we >>>>>> definitely >>>>>> > have >>>>>> > > to think through all these scenarios. In fact after Beta1, one >>>>>> of my >>>>>> > todos >>>>>> > > is to build up the build "from scratch" using that >>>>>> gradle-mixed-jdk >>>>>> > project >>>>>> > > as a basis. >>>>>> > > >>>>>> > > In general the plan though is to run all the tests (other than >>>>>> > > hibernate-java8, obviously) with the "baseline JDK, whether that >>>>>> be Java >>>>>> > 6 >>>>>> > > or 7. >>>>>> > > >>>>>> > > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>>>> sanne(a)hibernate.org&gt; >>>>>> > > wrote: >>>>>> > > >>>>>> > >> There are many similar issues discussed on the Lucene >>>>>> developer's >>>>>> > >> mailing list, it's an interesting read: >>>>>> > >> - >>>>>> > >> >>>>>> > >>>>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>>>> > >> >>>>>> > >> I see no alternative than to have those test jobs actually >>>>>> exercising >>>>>> > >> ORM with JDK6, or maybe even compile it all with JDK6 except >>>>>> the Java8 >>>>>> > >> additional module to be compiled with JDK8 ? >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; >>>>>> wrote: >>>>>> > >> > Ahh, seems this may be an option to work around it: >>>>>> > >> > >>>>>> > >> > <quote> >>>>>> > >> > Using the general *Map* interface in place of the concrete >>>>>> > >> > *ConcurrentHashMap* type here side-steps the coupling to the >>>>>> Java 8 >>>>>> > >> return >>>>>> > >> > type and will allow this code to be compiled with Java 8 and >>>>>> run on >>>>>> > >> Java 7. >>>>>> > >> > </quote> >>>>>> > >> > >>>>>> > >> > I had missed that part. >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>>>> steve(a)hibernate.org&gt; >>>>>> > >> wrote: >>>>>> > >> > >>>>>> > >> >> When I say "internal" here, I mean internal to java classes. >>>>>> > >> >> >>>>>> > >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>>>> steve(a)hibernate.org >>>>>> > > >>>>>> > >> >> wrote: >>>>>> > >> >> >>>>>> > >> >>> Nope. It just effects any code compiled with Java 8 even >>>>>> though the >>>>>> > >> >>> change is internal. The problem is the generated bytecode >>>>>> > >> incorporates >>>>>> > >> >>> this change. Like I said, this should be compiled with 1.6 >>>>>> > >> compatibility, >>>>>> > >> >>> but that is apparently not working atm. I am having a >>>>>> struggle >>>>>> > >> getting a >>>>>> > >> >>> mixed JDK build working "just right". >>>>>> > >> >>> >>>>>> > >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>>>> > >> paranoiabla(a)gmail.com&gt; >>>>>> > >> >>> wrote: >>>>>> > >> >>> >>>>>> > >> >>>> According to this: >>>>>> > >> >>>> >>>>>> > >> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>>>> > >> >>>> >>>>>> > >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns >>>>>> a Set<K> >>>>>> > >> while >>>>>> > >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>>>> > >> >>>> ConcurrentHashMap.KeySetView<K,V>`. >>>>>> > >> >>>> >>>>>> > >> >>>> I think you're using some Java8 API. >>>>>> > >> >>>> >>>>>> > >> >>>> >>>>>> > >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>>>> paranoiabla(a)gmail.com&gt;: >>>>>> > >> >>>> >>>>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>>>> > >> >>>>> java version "1.7.0_71" >>>>>> > >> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>>>> > >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed >>>>>> mode) >>>>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>>>> > >> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic >>>>>> #44-Ubuntu SMP >>>>>> > Thu >>>>>> > >> Mar >>>>>> > >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>>>> > >> >>>>> >>>>>> > >> >>>>> >>>>>> > >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>>>> steve(a)hibernate.org&gt;: >>>>>> > >> >>>>> >>>>>> > >> >>>>>> What JRE are you trying to use? This error: >>>>>> > >> >>>>>> >>>>>> > >> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>>>> > >> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>>>> > >> >>>>>> ConcurrentHashMap$KeySetView; >>>>>> > >> >>>>>> >>>>>> > >> >>>>>> is indicative of an issue in cross-jre support due to a >>>>>> change >>>>>> > >> >>>>>> internal to java classes. >>>>>> > >> >>>>>> >>>>>> > >> >>>>>> >>>>>> > >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>>>> > >> paranoiabla(a)gmail.com >>>>>> > >> >>>>>> > wrote: >>>>>> > >> >>>>>> >>>>>> > >> >>>>>>> Thanks Steve, >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>>> I managed to migrate my configuration to the new >>>>>> > >> >>>>>>> MetamodelImplementor. Now when I run the scema export I >>>>>> get a >>>>>> > lot >>>>>> > >> of these >>>>>> > >> >>>>>>> warning: >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>>> INFO : HHH000400: Using dialect: >>>>>> > >> org.hibernate.dialect.MySQL5Dialect >>>>>> > >> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers >>>>>> in both >>>>>> > >> mixed >>>>>> > >> >>>>>>> and upper case >>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> > >> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> > >> >>>>>>> >>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> > >> >>>>>>> >>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> > >> >>>>>>> >>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> > >> >>>>>>> >>>>>> > com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>> > >> >>>>>>> >>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>>> and when I run some test I get the following exception: >>>>>> > >> >>>>>>> java.lang.NoSuchMethodError: >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> > >>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>> > >> >>>>>>> at >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> > >>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>>>> > >> >>>>>>> at >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> > >>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>>>> > >> >>>>>>> at >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> > >>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>>>> > >> >>>>>>> at >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> > >>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>>>> > >> >>>>>>> at >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> > >>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>>>> > >> >>>>>>> at >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> > >>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>>>> > >> >>>>>>> at >>>>>> > >> >>>>>>> >>>>>> > org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>>>> > >> >>>>>>> at >>>>>> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>>>> > >> >>>>>>> at >>>>>> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>>>> > >> >>>>>>> at >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> > >>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>>>> > >> >>>>>>> at >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> > >>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>>>> > >> >>>>>>> at >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> > >>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>>>> steve(a)hibernate.org&gt;: >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>>>> I am told that the bug does not affect the >>>>>> JBoss->Central sync >>>>>> > >> >>>>>>>> process. So at some point the artifacts should all be >>>>>> > available >>>>>> > >> in Central >>>>>> > >> >>>>>>>> >>>>>> > >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>>>>> > >> steve(a)hibernate.org >>>>>> > >> >>>>>>>> > wrote: >>>>>> > >> >>>>>>>> >>>>>> > >> >>>>>>>>> hibernate-core seems to be the only artifact that is >>>>>> available >>>>>> > >> in >>>>>> > >> >>>>>>>>> JBoss Nexus. >>>>>> > >> >>>>>>>>> >>>>>> > >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>>>> > >> >>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>> > >> >>>>>>>>> >>>>>> > >> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus >>>>>> bug that >>>>>> > is >>>>>> > >> >>>>>>>>>> effecting the JBoss repo (and therefore us)... >>>>>> > >> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>>> > >> >>>>>>>>>> >>>>>> > >> >>>>>>>>>> As I pointed out in the announcement, I am managing >>>>>> the >>>>>> > >> "migration >>>>>> > >> >>>>>>>>>> guide" in source repo while I develop the Betas. See >>>>>> > >> >>>>>>>>>> >>>>>> > >> >>>>>> > >>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>>> > >> >>>>>>>>>> As far are the new bootstrapping apis, see >>>>>> > >> >>>>>>>>>> >>>>>> > >> >>>>>> > >>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>>> > >> >>>>>>>>>> and >>>>>> > >> >>>>>>>>>> >>>>>> > >> >>>>>> > >>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>>> > >> >>>>>>>>>> >>>>>> > >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>>>> > >> >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>> > >> >>>>>>>>>> >>>>>> > >> >>>>>>>>>>> Hi guys, >>>>>> > >> >>>>>>>>>>> >>>>>> > >> >>>>>>>>>>> I just tried the latest beta and I cannot compile my >>>>>> > project. >>>>>> > >> >>>>>>>>>>> With the >>>>>> > >> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>>>> > >> >>>>>>>>>>> ------- >>>>>> > >> >>>>>>>>>>> final org.hibernate.cfg.Configuration >>>>>> configuration >>>>>> > = >>>>>> > >> >>>>>>>>>>> getHibernateConfiguration(); >>>>>> > >> >>>>>>>>>>> configuration.buildMappings(); >>>>>> > >> >>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>>>> > >> >>>>>>>>>>> SchemaUpdate(configuration); >>>>>> > >> >>>>>>>>>>> ------- >>>>>> > >> >>>>>>>>>>> >>>>>> > >> >>>>>>>>>>> however it seems that the SchemaUpdate constructor >>>>>> has been >>>>>> > >> >>>>>>>>>>> removed and now >>>>>> > >> >>>>>>>>>>> a new one is added: >>>>>> > >> >>>>>>>>>>> -------- >>>>>> > >> >>>>>>>>>>> public SchemaUpdate(MetadataImplementor >>>>>> metadata) { >>>>>> > >> >>>>>>>>>>> this( >>>>>> > >> >>>>>>>>>>> >>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>> > >> >>>>>>>>>>> metadata ); >>>>>> > >> >>>>>>>>>>> } >>>>>> > >> >>>>>>>>>>> --------- >>>>>> > >> >>>>>>>>>>> >>>>>> > >> >>>>>>>>>>> Also the configuration.buildMappings() method has >>>>>> been >>>>>> > >> >>>>>>>>>>> deprecated. Where do >>>>>> > >> >>>>>>>>>>> I get the MetadataImplementor from? Also is there >>>>>> any >>>>>> > >> changelog I >>>>>> > >> >>>>>>>>>>> can refer >>>>>> > >> >>>>>>>>>>> to? >>>>>> > >> >>>>>>>>>>> >>>>>> > >> >>>>>>>>>>> Thanks. >>>>>> > >> >>>>>>>>>>> -- >>>>>> > >> >>>>>>>>>>> Regards, Petar! >>>>>> > >> >>>>>>>>>>> Karlovo, Bulgaria. >>>>>> > >> >>>>>>>>>>> --- >>>>>> > >> >>>>>>>>>>> Public PGP Key at: >>>>>> > >> >>>>>>>>>>> >>>>>> > >> >>>>>>>>>>> >>>>>> > >> >>>>>> > >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> > >> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>>>>> 1965 8550 >>>>>> > C311 >>>>>> > >> >>>>>>>>>>> 0611 >>>>>> > >> >>>>>>>>>>> _______________________________________________ >>>>>> > >> >>>>>>>>>>> hibernate-dev mailing list >>>>>> > >> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>> > >> >>>>>>>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> > >> >>>>>>>>>>> >>>>>> > >> >>>>>>>>>> >>>>>> > >> >>>>>>>>>> >>>>>> > >> >>>>>>>>> >>>>>> > >> >>>>>>>> >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>>> -- >>>>>> > >> >>>>>>> Regards, Petar! >>>>>> > >> >>>>>>> Karlovo, Bulgaria. >>>>>> > >> >>>>>>> --- >>>>>> > >> >>>>>>> Public PGP Key at: >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> > >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> > >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>>>> 8550 C311 >>>>>> > >> 0611 >>>>>> > >> >>>>>>> >>>>>> > >> >>>>>> >>>>>> > >> >>>>>> >>>>>> > >> >>>>> >>>>>> > >> >>>>> >>>>>> > >> >>>>> -- >>>>>> > >> >>>>> Regards, Petar! >>>>>> > >> >>>>> Karlovo, Bulgaria. >>>>>> > >> >>>>> --- >>>>>> > >> >>>>> Public PGP Key at: >>>>>> > >> >>>>> >>>>>> > >> >>>>>> > >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> > >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>>>> C311 >>>>>> > 0611 >>>>>> > >> >>>>> >>>>>> > >> >>>> >>>>>> > >> >>>> >>>>>> > >> >>>> >>>>>> > >> >>>> -- >>>>>> > >> >>>> Regards, Petar! >>>>>> > >> >>>> Karlovo, Bulgaria. >>>>>> > >> >>>> --- >>>>>> > >> >>>> Public PGP Key at: >>>>>> > >> >>>> >>>>>> > >> >>>>>> > >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> > >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>>>> C311 0611 >>>>>> > >> >>>> >>>>>> > >> >>> >>>>>> > >> >>> >>>>>> > >> >> >>>>>> > >> > _______________________________________________ >>>>>> > >> > hibernate-dev mailing list >>>>>> > >> > hibernate-dev(a)lists.jboss.org >>>>>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> > >> >>>>>> > > >>>>>> > > >>>>>> > _______________________________________________ >>>>>> > hibernate-dev mailing list >>>>>> > hibernate-dev(a)lists.jboss.org >>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> > >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, Petar! >>>>> Karlovo, Bulgaria. >>>>> --- >>>>> Public PGP Key at: >>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, Petar! >>>> Karlovo, Bulgaria. >>>> --- >>>> Public PGP Key at: >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>> >>> >>> >> > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611

Cool, ping me once resolved - I'm eager to test it :) 2015-04-02 21:57 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > Petar, so I was unfortunately remembering the work done for 6.0 when > saying that wrt the FK name. What I found is that binding support for JPA > @FK is, lets say "spotty" at best: > https://hibernate.atlassian.net/browse/HHH-9709 > > On Wed, Apr 1, 2015 at 8:02 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; > wrote: > >> >> OK, maybe I'm doing something wrong. I also tried setting the foreign >> key name to "none" like this: >> >> @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = { >> CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, fetch = >> FetchType.LAZY) >> @JoinTable(inverseJoinColumns = { >> @JoinColumn(unique = false, nullable = true, >> insertable = true, updatable = true, foreignKey = @ForeignKey(name = >> "none", value = ConstraintMode.NO_CONSTRAINT), name = "filter_pk") }, >> indexes = { >> @Index(unique = false, columnList = "entity_pk") }, >> inverseForeignKey = @ForeignKey(name = "none", value = >> ConstraintMode.NO_CONSTRAINT), foreignKey = @ForeignKey(name = "none", >> value = ConstraintMode.NO_CONSTRAINT), joinColumns = { >> @JoinColumn(unique = false, nullable = true, >> insertable = true, updatable = true, foreignKey = @ForeignKey(name = >> "none", value = ConstraintMode.NO_CONSTRAINT), name = "entity_pk") }, name >> = "entity_filters") >> >> >> it didn't help - the foreign keys are still generated. I prepared a >> sample project with 2 tests: >> 1) will try to create an entity and fail because of the foreign key >> 2) will export the schema.sql so you can see the foregin keys are still >> generated. >> >> Sample project is here: https://github.com/paranoiabla/HHH-8805 >> >> >> 2015-04-01 14:36 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> >>> https://hibernate.atlassian.net/browse/HHH-8805?focusedCommentId=66093&am... >>> >>> On Wed, Apr 1, 2015 at 6:20 AM, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> And no, we generally do not reopen issues from Closed state. And >>>> here, given the different branches, I'd be more inclined to create a >>>> different issue referencing the original. >>>> >>>> On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> Hmm, it seems I inadvertently set the wrong fix version on HHH-8805. >>>>> It is fixed in our metamodel branch which is 6.0. I pulled the necessary >>>>> metamodel (org.hibernate.mapping) changes back to master (5.0), but only >>>>> the hbm.xml form of naming the FK "none" (magic value) is supported to >>>>> truly disable generation. For the time being you can use this as well from >>>>> annotations; just name the FK "none". >>>>> >>>>> If you can write some tests for this, it will make it easier for me >>>>> to implement. >>>>> >>>>> >>>>> >>>>> On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoiabla(a)gmail.com >>>>> > wrote: >>>>> >>>>>> Oh, >>>>>> >>>>>> and one last thing: I don't think this is fixed: >>>>>> https://hibernate.atlassian.net/browse/HHH-8805 >>>>>> >>>>>> Here's my mapping: >>>>>> >>>>>> @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = { >>>>>> CascadeType.PERSIST, >>>>>> CascadeType.MERGE, >>>>>> CascadeType.REFRESH >>>>>> }, fetch = FetchType.LAZY) >>>>>> @JoinTable(indexes = { >>>>>> @Index(unique = false, columnList = "entity_pk") >>>>>> }, inverseForeignKey = >>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), inverseJoinColumns = { >>>>>> @JoinColumn(unique = false, nullable = true, insertable = >>>>>> true, updatable = true, foreignKey = >>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "filter_pk") >>>>>> }, joinColumns = { >>>>>> @JoinColumn(unique = false, nullable = true, insertable = >>>>>> true, updatable = true, foreignKey = >>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "entity_pk") >>>>>> }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name >>>>>> = "entity_filters") >>>>>> private Collection<AbstractFilterModelDefinition> filters; >>>>>> >>>>>> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it >>>>>> is possible to add it. However here's what the schema tool generates: >>>>>> >>>>>> create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters >>>>>> (entity_pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FKra38l70n01disvkge7i9ff5ym >>>>>> foreign key (filter_pk) >>>>>> references abstract_filter (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FKderx50xtd0lkeeblrj3o0ipq9 >>>>>> foreign key (entity_pk) >>>>>> references stock_level (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FK7ery3yx4pg32ogvv1wpr150oq >>>>>> foreign key (entity_pk) >>>>>> references content_slot (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FKse5m2mj7rrwj8ndimynfnr2px >>>>>> foreign key (entity_pk) >>>>>> references blog_entry (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FK9nubqtdhrmefjv2a5oab2fcr2 >>>>>> foreign key (entity_pk) >>>>>> references price (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FKcsuwqm524wu4u41oatrcalxvh >>>>>> foreign key (entity_pk) >>>>>> references tax (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FKmd3mm5pw9naa05ype38m6x1eo >>>>>> foreign key (entity_pk) >>>>>> references abstract_template (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FKsx6vnh2tga70pkne44dnq8kp0 >>>>>> foreign key (entity_pk) >>>>>> references discount (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FK6yx2wc1w1yb6qa1cx4byv7mju >>>>>> foreign key (entity_pk) >>>>>> references classification_feature (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FKpoh168do203hfqwb7so7c4c79 >>>>>> foreign key (entity_pk) >>>>>> references cms_navigation_node (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FKi85fkvbm7otl679ijlr6oyoff >>>>>> foreign key (entity_pk) >>>>>> references product (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FKi8semxf3lq0n12lm05v7oydeq >>>>>> foreign key (entity_pk) >>>>>> references abstract_page (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b >>>>>> foreign key (entity_pk) >>>>>> references promotion (pk); >>>>>> >>>>>> alter table entity_filters >>>>>> add constraint FKfw64whfl6vgbqehj20qmc39i3 >>>>>> foreign key (entity_pk) >>>>>> references simple_cms_widget (pk); >>>>>> >>>>>> The foreign keys are all different (in Hibernate 4.3.x they were the >>>>>> same), but I just don't want them. Shall I reopen the issue? >>>>>> >>>>>> >>>>>> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com&gt;: >>>>>> >>>>>>> One other thing I noticed: >>>>>>> hibernate-core-5 depends on >>>>>>> >>>>>>> <groupId>org.jboss.logging</groupId> >>>>>>> <artifactId>jboss-logging</artifactId> >>>>>>> <version>3.2.1.Final</version> >>>>>>> >>>>>>> and if you have hibernate-validator 5.1.3.Final (the last stable), >>>>>>> it will depend on >>>>>>> >>>>>>> <groupId>org.jboss.logging</groupId> >>>>>>> <artifactId>jboss-logging</artifactId> >>>>>>> <version>3.1.4.GA</version> >>>>>>> >>>>>>> So you will get an exception of method not found on some >>>>>>> jboss-logging API. I excluded the jboss-loggin from the hibernate-validator >>>>>>> dependency, but now I get a ton of these TRACE statements >>>>>>> (literally every millisecond): >>>>>>> >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> 2015-04-01 13:28:02,090 >>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>> >>>>>>> >>>>>>> But at least it works.. I guess the only real solution is to have >>>>>>> hibernate-validator use the same jboss-logging version. >>>>>>> >>>>>>> >>>>>>> 2015-04-01 10:39 GMT+03:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: >>>>>>> >>>>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>>>>> >>>>>>>> > Just to clarify... I *think* that as long as we run the build >>>>>>>> with Java 8 >>>>>>>> > and set the bootclasspath to 6 or 7 we should be fine. >>>>>>>> > >>>>>>>> >>>>>>>> Yes, setting the boot classpath to 6 (or 7) makes sure you only >>>>>>>> use classes >>>>>>>> present in that JDK (be it explicitly or implicitly as in the >>>>>>>> ConcurrentHashMap case), because it's that class library which >>>>>>>> will be used >>>>>>>> for compilation then. It is cumbersome to use though as you need >>>>>>>> to specify >>>>>>>> the location of a 6 or 7 JDK which makes the build less easily >>>>>>>> portable >>>>>>>> between machines. >>>>>>>> >>>>>>>> Currently, AnimalSniffer is in place to prevent this very category >>>>>>>> of error >>>>>>>> and I'm wondering why it didn't detect the "usage" of KeySetView. >>>>>>>> It really >>>>>>>> should have detected it, assuming it analyses the byte code of >>>>>>>> classes. But >>>>>>>> this makes me wonder now whether it only analyses the source code >>>>>>>> actually. >>>>>>>> Then it wouldn't be usable to prevent this sort of issue. >>>>>>>> >>>>>>>> Coding against the ConcurrentMap interface is the best way to >>>>>>>> avoid the >>>>>>>> issue. But of course there is no guarantee that it happens again, >>>>>>>> unless >>>>>>>> e.g. having a build on CI which uses 6 or 7 on its boot classpath. >>>>>>>> >>>>>>>> >>>>>>>> > On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt; >>>>>>>> > wrote: >>>>>>>> > >>>>>>>> > > Well the idea is to run the Gradle process with Java 8 (the >>>>>>>> build itself >>>>>>>> > > is a Java process too don't forget). We pass in the older JDK >>>>>>>> > specifically >>>>>>>> > > to be able to set the bootclasspath for compilation and the >>>>>>>> executable >>>>>>>> > for >>>>>>>> > > running tests. That's the theory. >>>>>>>> > > >>>>>>>> > > Interestingly I developed a simplified project to test these >>>>>>>> theories: >>>>>>>> > > https://github.com/sebersole/gradle-mixed-jdk And of course >>>>>>>> this all >>>>>>>> > > works there. As you'd expect right? >>>>>>>> > > >>>>>>>> > > I think the JAXB thing comes into play here as well. Gradle >>>>>>>> does not >>>>>>>> > have >>>>>>>> > > any XJC support built in, so we have to make use of its Ant >>>>>>>> support to >>>>>>>> > run >>>>>>>> > > the XJC Ant tasks for JAXB model generation. The problem >>>>>>>> there is that, >>>>>>>> > > afaik, there is no way to tell Gradle's AntBuilder to use a >>>>>>>> JDK other >>>>>>>> > than >>>>>>>> > > the one that launched Gradle. I think this is why we see a >>>>>>>> JAXB model >>>>>>>> > > defined for Java 7, rather than Java 6, because we essentially >>>>>>>> run XJC >>>>>>>> > with >>>>>>>> > > Java 8. >>>>>>>> > > >>>>>>>> > > Anyway, this certainly makes the build more complex and we >>>>>>>> definitely >>>>>>>> > have >>>>>>>> > > to think through all these scenarios. In fact after Beta1, >>>>>>>> one of my >>>>>>>> > todos >>>>>>>> > > is to build up the build "from scratch" using that >>>>>>>> gradle-mixed-jdk >>>>>>>> > project >>>>>>>> > > as a basis. >>>>>>>> > > >>>>>>>> > > In general the plan though is to run all the tests (other than >>>>>>>> > > hibernate-java8, obviously) with the "baseline JDK, whether >>>>>>>> that be Java >>>>>>>> > 6 >>>>>>>> > > or 7. >>>>>>>> > > >>>>>>>> > > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>>>>>> sanne(a)hibernate.org&gt; >>>>>>>> > > wrote: >>>>>>>> > > >>>>>>>> > >> There are many similar issues discussed on the Lucene >>>>>>>> developer's >>>>>>>> > >> mailing list, it's an interesting read: >>>>>>>> > >> - >>>>>>>> > >> >>>>>>>> > >>>>>>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>>>>>> > >> >>>>>>>> > >> I see no alternative than to have those test jobs actually >>>>>>>> exercising >>>>>>>> > >> ORM with JDK6, or maybe even compile it all with JDK6 except >>>>>>>> the Java8 >>>>>>>> > >> additional module to be compiled with JDK8 ? >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; >>>>>>>> wrote: >>>>>>>> > >> > Ahh, seems this may be an option to work around it: >>>>>>>> > >> > >>>>>>>> > >> > <quote> >>>>>>>> > >> > Using the general *Map* interface in place of the concrete >>>>>>>> > >> > *ConcurrentHashMap* type here side-steps the coupling to >>>>>>>> the Java 8 >>>>>>>> > >> return >>>>>>>> > >> > type and will allow this code to be compiled with Java 8 >>>>>>>> and run on >>>>>>>> > >> Java 7. >>>>>>>> > >> > </quote> >>>>>>>> > >> > >>>>>>>> > >> > I had missed that part. >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> > >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt; >>>>>>>> > >> wrote: >>>>>>>> > >> > >>>>>>>> > >> >> When I say "internal" here, I mean internal to java >>>>>>>> classes. >>>>>>>> > >> >> >>>>>>>> > >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>>>>>> steve(a)hibernate.org >>>>>>>> > > >>>>>>>> > >> >> wrote: >>>>>>>> > >> >> >>>>>>>> > >> >>> Nope. It just effects any code compiled with Java 8 even >>>>>>>> though the >>>>>>>> > >> >>> change is internal. The problem is the generated bytecode >>>>>>>> > >> incorporates >>>>>>>> > >> >>> this change. Like I said, this should be compiled with >>>>>>>> 1.6 >>>>>>>> > >> compatibility, >>>>>>>> > >> >>> but that is apparently not working atm. I am having a >>>>>>>> struggle >>>>>>>> > >> getting a >>>>>>>> > >> >>> mixed JDK build working "just right". >>>>>>>> > >> >>> >>>>>>>> > >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>>>>>> > >> paranoiabla(a)gmail.com&gt; >>>>>>>> > >> >>> wrote: >>>>>>>> > >> >>> >>>>>>>> > >> >>>> According to this: >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* >>>>>>>> returns a Set<K> >>>>>>>> > >> while >>>>>>>> > >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>>>>>> > >> >>>> ConcurrentHashMap.KeySetView<K,V>`. >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> I think you're using some Java8 API. >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>>>>>> paranoiabla(a)gmail.com&gt;: >>>>>>>> > >> >>>> >>>>>>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>>>>>> > >> >>>>> java version "1.7.0_71" >>>>>>>> > >> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>>>>>> > >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, >>>>>>>> mixed mode) >>>>>>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>>>>>> > >> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic >>>>>>>> #44-Ubuntu SMP >>>>>>>> > Thu >>>>>>>> > >> Mar >>>>>>>> > >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>>>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>>>>>> > >> >>>>> >>>>>>>> > >> >>>>> >>>>>>>> > >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>> > >> >>>>> >>>>>>>> > >> >>>>>> What JRE are you trying to use? This error: >>>>>>>> > >> >>>>>> >>>>>>>> > >> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>>>>>> > >> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>>>>>> > >> >>>>>> ConcurrentHashMap$KeySetView; >>>>>>>> > >> >>>>>> >>>>>>>> > >> >>>>>> is indicative of an issue in cross-jre support due to >>>>>>>> a change >>>>>>>> > >> >>>>>> internal to java classes. >>>>>>>> > >> >>>>>> >>>>>>>> > >> >>>>>> >>>>>>>> > >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>>>>>> > >> paranoiabla(a)gmail.com >>>>>>>> > >> >>>>>> > wrote: >>>>>>>> > >> >>>>>> >>>>>>>> > >> >>>>>>> Thanks Steve, >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>> I managed to migrate my configuration to the new >>>>>>>> > >> >>>>>>> MetamodelImplementor. Now when I run the scema export >>>>>>>> I get a >>>>>>>> > lot >>>>>>>> > >> of these >>>>>>>> > >> >>>>>>> warning: >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>> INFO : HHH000400: Using dialect: >>>>>>>> > >> org.hibernate.dialect.MySQL5Dialect >>>>>>>> > >> >>>>>>> WARN : JDBC Driver reports it stores quoted >>>>>>>> identifiers in both >>>>>>>> > >> mixed >>>>>>>> > >> >>>>>>> and upper case >>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> > >> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> > >> >>>>>>> >>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> > >> >>>>>>> >>>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> > >> >>>>>>> >>>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> > >> >>>>>>> >>>>>>>> > com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>> > >> >>>>>>> >>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>> and when I run some test I get the following >>>>>>>> exception: >>>>>>>> > >> >>>>>>> java.lang.NoSuchMethodError: >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>>>> > >> >>>>>>> at >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>>>>>> > >> >>>>>>> at >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>>>>>> > >> >>>>>>> at >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>>>>>> > >> >>>>>>> at >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>>>>>> > >> >>>>>>> at >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>>>>>> > >> >>>>>>> at >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>>>>>> > >> >>>>>>> at >>>>>>>> > >> >>>>>>> >>>>>>>> > >>>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>>>>>> > >> >>>>>>> at >>>>>>>> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>>>>>> > >> >>>>>>> at >>>>>>>> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>>>>>> > >> >>>>>>> at >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>>>>>> > >> >>>>>>> at >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>>>>>> > >> >>>>>>> at >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> I am told that the bug does not affect the >>>>>>>> JBoss->Central sync >>>>>>>> > >> >>>>>>>> process. So at some point the artifacts should all >>>>>>>> be >>>>>>>> > available >>>>>>>> > >> in Central >>>>>>>> > >> >>>>>>>> >>>>>>>> > >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>>>>>>> > >> steve(a)hibernate.org >>>>>>>> > >> >>>>>>>> > wrote: >>>>>>>> > >> >>>>>>>> >>>>>>>> > >> >>>>>>>>> hibernate-core seems to be the only artifact that >>>>>>>> is available >>>>>>>> > >> in >>>>>>>> > >> >>>>>>>>> JBoss Nexus. >>>>>>>> > >> >>>>>>>>> >>>>>>>> > >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>>>>>> > >> >>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>> > >> >>>>>>>>> >>>>>>>> > >> >>>>>>>>>> So apparently the artifacts / repo issue is a >>>>>>>> Nexus bug that >>>>>>>> > is >>>>>>>> > >> >>>>>>>>>> effecting the JBoss repo (and therefore us)... >>>>>>>> > >> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>>>>> > >> >>>>>>>>>> >>>>>>>> > >> >>>>>>>>>> As I pointed out in the announcement, I am >>>>>>>> managing the >>>>>>>> > >> "migration >>>>>>>> > >> >>>>>>>>>> guide" in source repo while I develop the Betas. >>>>>>>> See >>>>>>>> > >> >>>>>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>>>>> > >> >>>>>>>>>> As far are the new bootstrapping apis, see >>>>>>>> > >> >>>>>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>>>>> > >> >>>>>>>>>> and >>>>>>>> > >> >>>>>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>>>>> > >> >>>>>>>>>> >>>>>>>> > >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>>>>>> > >> >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>>> > >> >>>>>>>>>> >>>>>>>> > >> >>>>>>>>>>> Hi guys, >>>>>>>> > >> >>>>>>>>>>> >>>>>>>> > >> >>>>>>>>>>> I just tried the latest beta and I cannot compile >>>>>>>> my >>>>>>>> > project. >>>>>>>> > >> >>>>>>>>>>> With the >>>>>>>> > >> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>>>>>> > >> >>>>>>>>>>> ------- >>>>>>>> > >> >>>>>>>>>>> final org.hibernate.cfg.Configuration >>>>>>>> configuration >>>>>>>> > = >>>>>>>> > >> >>>>>>>>>>> getHibernateConfiguration(); >>>>>>>> > >> >>>>>>>>>>> configuration.buildMappings(); >>>>>>>> > >> >>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>>>>>> > >> >>>>>>>>>>> SchemaUpdate(configuration); >>>>>>>> > >> >>>>>>>>>>> ------- >>>>>>>> > >> >>>>>>>>>>> >>>>>>>> > >> >>>>>>>>>>> however it seems that the SchemaUpdate >>>>>>>> constructor has been >>>>>>>> > >> >>>>>>>>>>> removed and now >>>>>>>> > >> >>>>>>>>>>> a new one is added: >>>>>>>> > >> >>>>>>>>>>> -------- >>>>>>>> > >> >>>>>>>>>>> public SchemaUpdate(MetadataImplementor >>>>>>>> metadata) { >>>>>>>> > >> >>>>>>>>>>> this( >>>>>>>> > >> >>>>>>>>>>> >>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>>>> > >> >>>>>>>>>>> metadata ); >>>>>>>> > >> >>>>>>>>>>> } >>>>>>>> > >> >>>>>>>>>>> --------- >>>>>>>> > >> >>>>>>>>>>> >>>>>>>> > >> >>>>>>>>>>> Also the configuration.buildMappings() method has >>>>>>>> been >>>>>>>> > >> >>>>>>>>>>> deprecated. Where do >>>>>>>> > >> >>>>>>>>>>> I get the MetadataImplementor from? Also is there >>>>>>>> any >>>>>>>> > >> changelog I >>>>>>>> > >> >>>>>>>>>>> can refer >>>>>>>> > >> >>>>>>>>>>> to? >>>>>>>> > >> >>>>>>>>>>> >>>>>>>> > >> >>>>>>>>>>> Thanks. >>>>>>>> > >> >>>>>>>>>>> -- >>>>>>>> > >> >>>>>>>>>>> Regards, Petar! >>>>>>>> > >> >>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>> > >> >>>>>>>>>>> --- >>>>>>>> > >> >>>>>>>>>>> Public PGP Key at: >>>>>>>> > >> >>>>>>>>>>> >>>>>>>> > >> >>>>>>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>> > >> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>>>>>>> 1965 8550 >>>>>>>> > C311 >>>>>>>> > >> >>>>>>>>>>> 0611 >>>>>>>> > >> >>>>>>>>>>> _______________________________________________ >>>>>>>> > >> >>>>>>>>>>> hibernate-dev mailing list >>>>>>>> > >> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>> > >> >>>>>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> > >> >>>>>>>>>>> >>>>>>>> > >> >>>>>>>>>> >>>>>>>> > >> >>>>>>>>>> >>>>>>>> > >> >>>>>>>>> >>>>>>>> > >> >>>>>>>> >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>> -- >>>>>>>> > >> >>>>>>> Regards, Petar! >>>>>>>> > >> >>>>>>> Karlovo, Bulgaria. >>>>>>>> > >> >>>>>>> --- >>>>>>>> > >> >>>>>>> Public PGP Key at: >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>> > >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>>>>>> 8550 C311 >>>>>>>> > >> 0611 >>>>>>>> > >> >>>>>>> >>>>>>>> > >> >>>>>> >>>>>>>> > >> >>>>>> >>>>>>>> > >> >>>>> >>>>>>>> > >> >>>>> >>>>>>>> > >> >>>>> -- >>>>>>>> > >> >>>>> Regards, Petar! >>>>>>>> > >> >>>>> Karlovo, Bulgaria. >>>>>>>> > >> >>>>> --- >>>>>>>> > >> >>>>> Public PGP Key at: >>>>>>>> > >> >>>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>> > >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>>>>>> 8550 C311 >>>>>>>> > 0611 >>>>>>>> > >> >>>>> >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> -- >>>>>>>> > >> >>>> Regards, Petar! >>>>>>>> > >> >>>> Karlovo, Bulgaria. >>>>>>>> > >> >>>> --- >>>>>>>> > >> >>>> Public PGP Key at: >>>>>>>> > >> >>>> >>>>>>>> > >> >>>>>>>> > >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>> > >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>>>>>> 8550 C311 0611 >>>>>>>> > >> >>>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>>>> > >> >> >>>>>>>> > >> > _______________________________________________ >>>>>>>> > >> > hibernate-dev mailing list >>>>>>>> > >> > hibernate-dev(a)lists.jboss.org >>>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> > >> >>>>>>>> > > >>>>>>>> > > >>>>>>>> > _______________________________________________ >>>>>>>> > hibernate-dev mailing list >>>>>>>> > hibernate-dev(a)lists.jboss.org >>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> > >>>>>>>> _______________________________________________ >>>>>>>> hibernate-dev mailing list >>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, Petar! >>>>>>> Karlovo, Bulgaria. >>>>>>> --- >>>>>>> Public PGP Key at: >>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, Petar! >>>>>> Karlovo, Bulgaria. >>>>>> --- >>>>>> Public PGP Key at: >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> > > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611

Ok Petar, when you get a chance pull and give that a try wrt ForeignKeys On Thu, Apr 2, 2015 at 2:06 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I am working on it as we speak :) > > On Thu, Apr 2, 2015 at 2:05 PM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; > wrote: > >> Cool, >> >> ping me once resolved - I'm eager to test it :) >> >> 2015-04-02 21:57 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> Petar, so I was unfortunately remembering the work done for 6.0 when >>> saying that wrt the FK name. What I found is that binding support for JPA >>> @FK is, lets say "spotty" at best: >>> https://hibernate.atlassian.net/browse/HHH-9709 >>> >>> On Wed, Apr 1, 2015 at 8:02 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >>> wrote: >>> >>>> >>>> OK, maybe I'm doing something wrong. I also tried setting the foreign >>>> key name to "none" like this: >>>> >>>> @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = { >>>> CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, fetch = >>>> FetchType.LAZY) >>>> @JoinTable(inverseJoinColumns = { >>>> @JoinColumn(unique = false, nullable = true, >>>> insertable = true, updatable = true, foreignKey = @ForeignKey(name = >>>> "none", value = ConstraintMode.NO_CONSTRAINT), name = "filter_pk") }, >>>> indexes = { >>>> @Index(unique = false, columnList = "entity_pk") >>>> }, inverseForeignKey = @ForeignKey(name = "none", value = >>>> ConstraintMode.NO_CONSTRAINT), foreignKey = @ForeignKey(name = "none", >>>> value = ConstraintMode.NO_CONSTRAINT), joinColumns = { >>>> @JoinColumn(unique = false, nullable = true, >>>> insertable = true, updatable = true, foreignKey = @ForeignKey(name = >>>> "none", value = ConstraintMode.NO_CONSTRAINT), name = "entity_pk") }, name >>>> = "entity_filters") >>>> >>>> >>>> it didn't help - the foreign keys are still generated. I prepared a >>>> sample project with 2 tests: >>>> 1) will try to create an entity and fail because of the foreign key >>>> 2) will export the schema.sql so you can see the foregin keys are >>>> still generated. >>>> >>>> Sample project is here: https://github.com/paranoiabla/HHH-8805 >>>> >>>> >>>> 2015-04-01 14:36 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> >>>>> >>>>> https://hibernate.atlassian.net/browse/HHH-8805?focusedCommentId=66093&am... >>>>> >>>>> On Wed, Apr 1, 2015 at 6:20 AM, Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> And no, we generally do not reopen issues from Closed state. And >>>>>> here, given the different branches, I'd be more inclined to create a >>>>>> different issue referencing the original. >>>>>> >>>>>> On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve(a)hibernate.org&gt; >>>>>> wrote: >>>>>> >>>>>>> Hmm, it seems I inadvertently set the wrong fix version on >>>>>>> HHH-8805. It is fixed in our metamodel branch which is 6.0. I pulled the >>>>>>> necessary metamodel (org.hibernate.mapping) changes back to master (5.0), >>>>>>> but only the hbm.xml form of naming the FK "none" (magic value) is >>>>>>> supported to truly disable generation. For the time being you can use this >>>>>>> as well from annotations; just name the FK "none". >>>>>>> >>>>>>> If you can write some tests for this, it will make it easier for me >>>>>>> to implement. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev < >>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>> >>>>>>>> Oh, >>>>>>>> >>>>>>>> and one last thing: I don't think this is fixed: >>>>>>>> https://hibernate.atlassian.net/browse/HHH-8805 >>>>>>>> >>>>>>>> Here's my mapping: >>>>>>>> >>>>>>>> @ManyToMany(targetEntity = AbstractFilterModel.class, cascade >>>>>>>> = { >>>>>>>> CascadeType.PERSIST, >>>>>>>> CascadeType.MERGE, >>>>>>>> CascadeType.REFRESH >>>>>>>> }, fetch = FetchType.LAZY) >>>>>>>> @JoinTable(indexes = { >>>>>>>> @Index(unique = false, columnList = "entity_pk") >>>>>>>> }, inverseForeignKey = >>>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), inverseJoinColumns = { >>>>>>>> @JoinColumn(unique = false, nullable = true, insertable = >>>>>>>> true, updatable = true, foreignKey = >>>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "filter_pk") >>>>>>>> }, joinColumns = { >>>>>>>> @JoinColumn(unique = false, nullable = true, insertable = >>>>>>>> true, updatable = true, foreignKey = >>>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "entity_pk") >>>>>>>> }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), >>>>>>>> name = "entity_filters") >>>>>>>> private Collection<AbstractFilterModelDefinition> filters; >>>>>>>> >>>>>>>> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever >>>>>>>> it is possible to add it. However here's what the schema tool generates: >>>>>>>> >>>>>>>> create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters >>>>>>>> (entity_pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FKra38l70n01disvkge7i9ff5ym >>>>>>>> foreign key (filter_pk) >>>>>>>> references abstract_filter (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FKderx50xtd0lkeeblrj3o0ipq9 >>>>>>>> foreign key (entity_pk) >>>>>>>> references stock_level (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FK7ery3yx4pg32ogvv1wpr150oq >>>>>>>> foreign key (entity_pk) >>>>>>>> references content_slot (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FKse5m2mj7rrwj8ndimynfnr2px >>>>>>>> foreign key (entity_pk) >>>>>>>> references blog_entry (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FK9nubqtdhrmefjv2a5oab2fcr2 >>>>>>>> foreign key (entity_pk) >>>>>>>> references price (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FKcsuwqm524wu4u41oatrcalxvh >>>>>>>> foreign key (entity_pk) >>>>>>>> references tax (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FKmd3mm5pw9naa05ype38m6x1eo >>>>>>>> foreign key (entity_pk) >>>>>>>> references abstract_template (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FKsx6vnh2tga70pkne44dnq8kp0 >>>>>>>> foreign key (entity_pk) >>>>>>>> references discount (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FK6yx2wc1w1yb6qa1cx4byv7mju >>>>>>>> foreign key (entity_pk) >>>>>>>> references classification_feature (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FKpoh168do203hfqwb7so7c4c79 >>>>>>>> foreign key (entity_pk) >>>>>>>> references cms_navigation_node (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FKi85fkvbm7otl679ijlr6oyoff >>>>>>>> foreign key (entity_pk) >>>>>>>> references product (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FKi8semxf3lq0n12lm05v7oydeq >>>>>>>> foreign key (entity_pk) >>>>>>>> references abstract_page (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b >>>>>>>> foreign key (entity_pk) >>>>>>>> references promotion (pk); >>>>>>>> >>>>>>>> alter table entity_filters >>>>>>>> add constraint FKfw64whfl6vgbqehj20qmc39i3 >>>>>>>> foreign key (entity_pk) >>>>>>>> references simple_cms_widget (pk); >>>>>>>> >>>>>>>> The foreign keys are all different (in Hibernate 4.3.x they were >>>>>>>> the same), but I just don't want them. Shall I reopen the issue? >>>>>>>> >>>>>>>> >>>>>>>> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com&gt;: >>>>>>>> >>>>>>>>> One other thing I noticed: >>>>>>>>> hibernate-core-5 depends on >>>>>>>>> >>>>>>>>> <groupId>org.jboss.logging</groupId> >>>>>>>>> <artifactId>jboss-logging</artifactId> >>>>>>>>> <version>3.2.1.Final</version> >>>>>>>>> >>>>>>>>> and if you have hibernate-validator 5.1.3.Final (the last >>>>>>>>> stable), it will depend on >>>>>>>>> >>>>>>>>> <groupId>org.jboss.logging</groupId> >>>>>>>>> <artifactId>jboss-logging</artifactId> >>>>>>>>> <version>3.1.4.GA</version> >>>>>>>>> >>>>>>>>> So you will get an exception of method not found on some >>>>>>>>> jboss-logging API. I excluded the jboss-loggin from the hibernate-validator >>>>>>>>> dependency, but now I get a ton of these TRACE statements >>>>>>>>> (literally every millisecond): >>>>>>>>> >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> 2015-04-01 13:28:02,090 >>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener >>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>>>>>>>> >>>>>>>>> >>>>>>>>> But at least it works.. I guess the only real solution is to >>>>>>>>> have hibernate-validator use the same jboss-logging version. >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-04-01 10:39 GMT+03:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: >>>>>>>>> >>>>>>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>>>>>>> >>>>>>>>>> > Just to clarify... I *think* that as long as we run the build >>>>>>>>>> with Java 8 >>>>>>>>>> > and set the bootclasspath to 6 or 7 we should be fine. >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> Yes, setting the boot classpath to 6 (or 7) makes sure you only >>>>>>>>>> use classes >>>>>>>>>> present in that JDK (be it explicitly or implicitly as in the >>>>>>>>>> ConcurrentHashMap case), because it's that class library which >>>>>>>>>> will be used >>>>>>>>>> for compilation then. It is cumbersome to use though as you need >>>>>>>>>> to specify >>>>>>>>>> the location of a 6 or 7 JDK which makes the build less easily >>>>>>>>>> portable >>>>>>>>>> between machines. >>>>>>>>>> >>>>>>>>>> Currently, AnimalSniffer is in place to prevent this very >>>>>>>>>> category of error >>>>>>>>>> and I'm wondering why it didn't detect the "usage" of >>>>>>>>>> KeySetView. It really >>>>>>>>>> should have detected it, assuming it analyses the byte code of >>>>>>>>>> classes. But >>>>>>>>>> this makes me wonder now whether it only analyses the source >>>>>>>>>> code actually. >>>>>>>>>> Then it wouldn't be usable to prevent this sort of issue. >>>>>>>>>> >>>>>>>>>> Coding against the ConcurrentMap interface is the best way to >>>>>>>>>> avoid the >>>>>>>>>> issue. But of course there is no guarantee that it happens >>>>>>>>>> again, unless >>>>>>>>>> e.g. having a build on CI which uses 6 or 7 on its boot >>>>>>>>>> classpath. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>> > wrote: >>>>>>>>>> > >>>>>>>>>> > > Well the idea is to run the Gradle process with Java 8 (the >>>>>>>>>> build itself >>>>>>>>>> > > is a Java process too don't forget). We pass in the older >>>>>>>>>> JDK >>>>>>>>>> > specifically >>>>>>>>>> > > to be able to set the bootclasspath for compilation and the >>>>>>>>>> executable >>>>>>>>>> > for >>>>>>>>>> > > running tests. That's the theory. >>>>>>>>>> > > >>>>>>>>>> > > Interestingly I developed a simplified project to test these >>>>>>>>>> theories: >>>>>>>>>> > > https://github.com/sebersole/gradle-mixed-jdk And of >>>>>>>>>> course this all >>>>>>>>>> > > works there. As you'd expect right? >>>>>>>>>> > > >>>>>>>>>> > > I think the JAXB thing comes into play here as well. Gradle >>>>>>>>>> does not >>>>>>>>>> > have >>>>>>>>>> > > any XJC support built in, so we have to make use of its Ant >>>>>>>>>> support to >>>>>>>>>> > run >>>>>>>>>> > > the XJC Ant tasks for JAXB model generation. The problem >>>>>>>>>> there is that, >>>>>>>>>> > > afaik, there is no way to tell Gradle's AntBuilder to use a >>>>>>>>>> JDK other >>>>>>>>>> > than >>>>>>>>>> > > the one that launched Gradle. I think this is why we see a >>>>>>>>>> JAXB model >>>>>>>>>> > > defined for Java 7, rather than Java 6, because we >>>>>>>>>> essentially run XJC >>>>>>>>>> > with >>>>>>>>>> > > Java 8. >>>>>>>>>> > > >>>>>>>>>> > > Anyway, this certainly makes the build more complex and we >>>>>>>>>> definitely >>>>>>>>>> > have >>>>>>>>>> > > to think through all these scenarios. In fact after Beta1, >>>>>>>>>> one of my >>>>>>>>>> > todos >>>>>>>>>> > > is to build up the build "from scratch" using that >>>>>>>>>> gradle-mixed-jdk >>>>>>>>>> > project >>>>>>>>>> > > as a basis. >>>>>>>>>> > > >>>>>>>>>> > > In general the plan though is to run all the tests (other >>>>>>>>>> than >>>>>>>>>> > > hibernate-java8, obviously) with the "baseline JDK, whether >>>>>>>>>> that be Java >>>>>>>>>> > 6 >>>>>>>>>> > > or 7. >>>>>>>>>> > > >>>>>>>>>> > > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>>>>>>>> sanne(a)hibernate.org&gt; >>>>>>>>>> > > wrote: >>>>>>>>>> > > >>>>>>>>>> > >> There are many similar issues discussed on the Lucene >>>>>>>>>> developer's >>>>>>>>>> > >> mailing list, it's an interesting read: >>>>>>>>>> > >> - >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>>>>>>>> > >> >>>>>>>>>> > >> I see no alternative than to have those test jobs actually >>>>>>>>>> exercising >>>>>>>>>> > >> ORM with JDK6, or maybe even compile it all with JDK6 >>>>>>>>>> except the Java8 >>>>>>>>>> > >> additional module to be compiled with JDK8 ? >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> On 1 April 2015 at 00:36, Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>> > >> > Ahh, seems this may be an option to work around it: >>>>>>>>>> > >> > >>>>>>>>>> > >> > <quote> >>>>>>>>>> > >> > Using the general *Map* interface in place of the concrete >>>>>>>>>> > >> > *ConcurrentHashMap* type here side-steps the coupling to >>>>>>>>>> the Java 8 >>>>>>>>>> > >> return >>>>>>>>>> > >> > type and will allow this code to be compiled with Java 8 >>>>>>>>>> and run on >>>>>>>>>> > >> Java 7. >>>>>>>>>> > >> > </quote> >>>>>>>>>> > >> > >>>>>>>>>> > >> > I had missed that part. >>>>>>>>>> > >> > >>>>>>>>>> > >> > >>>>>>>>>> > >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>> > >> wrote: >>>>>>>>>> > >> > >>>>>>>>>> > >> >> When I say "internal" here, I mean internal to java >>>>>>>>>> classes. >>>>>>>>>> > >> >> >>>>>>>>>> > >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org >>>>>>>>>> > > >>>>>>>>>> > >> >> wrote: >>>>>>>>>> > >> >> >>>>>>>>>> > >> >>> Nope. It just effects any code compiled with Java 8 >>>>>>>>>> even though the >>>>>>>>>> > >> >>> change is internal. The problem is the generated >>>>>>>>>> bytecode >>>>>>>>>> > >> incorporates >>>>>>>>>> > >> >>> this change. Like I said, this should be compiled >>>>>>>>>> with 1.6 >>>>>>>>>> > >> compatibility, >>>>>>>>>> > >> >>> but that is apparently not working atm. I am having a >>>>>>>>>> struggle >>>>>>>>>> > >> getting a >>>>>>>>>> > >> >>> mixed JDK build working "just right". >>>>>>>>>> > >> >>> >>>>>>>>>> > >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>>>>>>>> > >> paranoiabla(a)gmail.com&gt; >>>>>>>>>> > >> >>> wrote: >>>>>>>>>> > >> >>> >>>>>>>>>> > >> >>>> According to this: >>>>>>>>>> > >> >>>> >>>>>>>>>> > >> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>>>>>>>> > >> >>>> >>>>>>>>>> > >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* >>>>>>>>>> returns a Set<K> >>>>>>>>>> > >> while >>>>>>>>>> > >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>>>>>>>> > >> >>>> ConcurrentHashMap.KeySetView<K,V>`. >>>>>>>>>> > >> >>>> >>>>>>>>>> > >> >>>> I think you're using some Java8 API. >>>>>>>>>> > >> >>>> >>>>>>>>>> > >> >>>> >>>>>>>>>> > >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>>>>>>>> paranoiabla(a)gmail.com&gt;: >>>>>>>>>> > >> >>>> >>>>>>>>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>>>>>>>> > >> >>>>> java version "1.7.0_71" >>>>>>>>>> > >> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>>>>>>>> > >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, >>>>>>>>>> mixed mode) >>>>>>>>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>>>>>>>> > >> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic >>>>>>>>>> #44-Ubuntu SMP >>>>>>>>>> > Thu >>>>>>>>>> > >> Mar >>>>>>>>>> > >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>>>>>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>>>>>>>> > >> >>>>> >>>>>>>>>> > >> >>>>> >>>>>>>>>> > >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>> > >> >>>>> >>>>>>>>>> > >> >>>>>> What JRE are you trying to use? This error: >>>>>>>>>> > >> >>>>>> >>>>>>>>>> > >> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>>>>>>>> > >> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>>>>>>>> > >> >>>>>> ConcurrentHashMap$KeySetView; >>>>>>>>>> > >> >>>>>> >>>>>>>>>> > >> >>>>>> is indicative of an issue in cross-jre support due >>>>>>>>>> to a change >>>>>>>>>> > >> >>>>>> internal to java classes. >>>>>>>>>> > >> >>>>>> >>>>>>>>>> > >> >>>>>> >>>>>>>>>> > >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>>>>>>>> > >> paranoiabla(a)gmail.com >>>>>>>>>> > >> >>>>>> > wrote: >>>>>>>>>> > >> >>>>>> >>>>>>>>>> > >> >>>>>>> Thanks Steve, >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>> I managed to migrate my configuration to the new >>>>>>>>>> > >> >>>>>>> MetamodelImplementor. Now when I run the scema >>>>>>>>>> export I get a >>>>>>>>>> > lot >>>>>>>>>> > >> of these >>>>>>>>>> > >> >>>>>>> warning: >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>> INFO : HHH000400: Using dialect: >>>>>>>>>> > >> org.hibernate.dialect.MySQL5Dialect >>>>>>>>>> > >> >>>>>>> WARN : JDBC Driver reports it stores quoted >>>>>>>>>> identifiers in both >>>>>>>>>> > >> mixed >>>>>>>>>> > >> >>>>>>> and upper case >>>>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> > >> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >>>>>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>>>>>>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>> and when I run some test I get the following >>>>>>>>>> exception: >>>>>>>>>> > >> >>>>>>> java.lang.NoSuchMethodError: >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>>>>>> > >> >>>>>>> at >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>>>>>>>> > >> >>>>>>> at >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>>>>>>>> > >> >>>>>>> at >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>>>>>>>> > >> >>>>>>> at >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>>>>>>>> > >> >>>>>>> at >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>>>>>>>> > >> >>>>>>> at >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>>>>>>>> > >> >>>>>>> at >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >>>>>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>>>>>>>> > >> >>>>>>> at >>>>>>>>>> > >> >>>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>>>>>>>> > >> >>>>>>> at >>>>>>>>>> > >> >>>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>>>>>>>> > >> >>>>>>> at >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>>>>>>>> > >> >>>>>>> at >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>>>>>>>> > >> >>>>>>> at >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>> I am told that the bug does not affect the >>>>>>>>>> JBoss->Central sync >>>>>>>>>> > >> >>>>>>>> process. So at some point the artifacts should >>>>>>>>>> all be >>>>>>>>>> > available >>>>>>>>>> > >> in Central >>>>>>>>>> > >> >>>>>>>> >>>>>>>>>> > >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>>>>>>>>> > >> steve(a)hibernate.org >>>>>>>>>> > >> >>>>>>>> > wrote: >>>>>>>>>> > >> >>>>>>>> >>>>>>>>>> > >> >>>>>>>>> hibernate-core seems to be the only artifact that >>>>>>>>>> is available >>>>>>>>>> > >> in >>>>>>>>>> > >> >>>>>>>>> JBoss Nexus. >>>>>>>>>> > >> >>>>>>>>> >>>>>>>>>> > >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>>>>>>>> > >> >>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>> > >> >>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>> So apparently the artifacts / repo issue is a >>>>>>>>>> Nexus bug that >>>>>>>>>> > is >>>>>>>>>> > >> >>>>>>>>>> effecting the JBoss repo (and therefore us)... >>>>>>>>>> > >> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>>>>>>> > >> >>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>> As I pointed out in the announcement, I am >>>>>>>>>> managing the >>>>>>>>>> > >> "migration >>>>>>>>>> > >> >>>>>>>>>> guide" in source repo while I develop the >>>>>>>>>> Betas. See >>>>>>>>>> > >> >>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>>>>>>> > >> >>>>>>>>>> As far are the new bootstrapping apis, see >>>>>>>>>> > >> >>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>>>>>>> > >> >>>>>>>>>> and >>>>>>>>>> > >> >>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>>>>>>> > >> >>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>>>>>>>> > >> >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>>>>> > >> >>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>>> Hi guys, >>>>>>>>>> > >> >>>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>>> I just tried the latest beta and I cannot >>>>>>>>>> compile my >>>>>>>>>> > project. >>>>>>>>>> > >> >>>>>>>>>>> With the >>>>>>>>>> > >> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>>>>>>>> > >> >>>>>>>>>>> ------- >>>>>>>>>> > >> >>>>>>>>>>> final org.hibernate.cfg.Configuration >>>>>>>>>> configuration >>>>>>>>>> > = >>>>>>>>>> > >> >>>>>>>>>>> getHibernateConfiguration(); >>>>>>>>>> > >> >>>>>>>>>>> configuration.buildMappings(); >>>>>>>>>> > >> >>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>>>>>>>> > >> >>>>>>>>>>> SchemaUpdate(configuration); >>>>>>>>>> > >> >>>>>>>>>>> ------- >>>>>>>>>> > >> >>>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>>> however it seems that the SchemaUpdate >>>>>>>>>> constructor has been >>>>>>>>>> > >> >>>>>>>>>>> removed and now >>>>>>>>>> > >> >>>>>>>>>>> a new one is added: >>>>>>>>>> > >> >>>>>>>>>>> -------- >>>>>>>>>> > >> >>>>>>>>>>> public SchemaUpdate(MetadataImplementor >>>>>>>>>> metadata) { >>>>>>>>>> > >> >>>>>>>>>>> this( >>>>>>>>>> > >> >>>>>>>>>>> >>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>>>>>> > >> >>>>>>>>>>> metadata ); >>>>>>>>>> > >> >>>>>>>>>>> } >>>>>>>>>> > >> >>>>>>>>>>> --------- >>>>>>>>>> > >> >>>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>>> Also the configuration.buildMappings() method >>>>>>>>>> has been >>>>>>>>>> > >> >>>>>>>>>>> deprecated. Where do >>>>>>>>>> > >> >>>>>>>>>>> I get the MetadataImplementor from? Also is >>>>>>>>>> there any >>>>>>>>>> > >> changelog I >>>>>>>>>> > >> >>>>>>>>>>> can refer >>>>>>>>>> > >> >>>>>>>>>>> to? >>>>>>>>>> > >> >>>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>>> Thanks. >>>>>>>>>> > >> >>>>>>>>>>> -- >>>>>>>>>> > >> >>>>>>>>>>> Regards, Petar! >>>>>>>>>> > >> >>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>> > >> >>>>>>>>>>> --- >>>>>>>>>> > >> >>>>>>>>>>> Public PGP Key at: >>>>>>>>>> > >> >>>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>> > >> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>>>>>>>>> 1965 8550 >>>>>>>>>> > C311 >>>>>>>>>> > >> >>>>>>>>>>> 0611 >>>>>>>>>> > >> >>>>>>>>>>> _______________________________________________ >>>>>>>>>> > >> >>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>> > >> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>> > >> >>>>>>>>>>> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> > >> >>>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>>> >>>>>>>>>> > >> >>>>>>>>> >>>>>>>>>> > >> >>>>>>>> >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>> -- >>>>>>>>>> > >> >>>>>>> Regards, Petar! >>>>>>>>>> > >> >>>>>>> Karlovo, Bulgaria. >>>>>>>>>> > >> >>>>>>> --- >>>>>>>>>> > >> >>>>>>> Public PGP Key at: >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>> > >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 >>>>>>>>>> 1965 8550 C311 >>>>>>>>>> > >> 0611 >>>>>>>>>> > >> >>>>>>> >>>>>>>>>> > >> >>>>>> >>>>>>>>>> > >> >>>>>> >>>>>>>>>> > >> >>>>> >>>>>>>>>> > >> >>>>> >>>>>>>>>> > >> >>>>> -- >>>>>>>>>> > >> >>>>> Regards, Petar! >>>>>>>>>> > >> >>>>> Karlovo, Bulgaria. >>>>>>>>>> > >> >>>>> --- >>>>>>>>>> > >> >>>>> Public PGP Key at: >>>>>>>>>> > >> >>>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>> > >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>>>>>>>> 8550 C311 >>>>>>>>>> > 0611 >>>>>>>>>> > >> >>>>> >>>>>>>>>> > >> >>>> >>>>>>>>>> > >> >>>> >>>>>>>>>> > >> >>>> >>>>>>>>>> > >> >>>> -- >>>>>>>>>> > >> >>>> Regards, Petar! >>>>>>>>>> > >> >>>> Karlovo, Bulgaria. >>>>>>>>>> > >> >>>> --- >>>>>>>>>> > >> >>>> Public PGP Key at: >>>>>>>>>> > >> >>>> >>>>>>>>>> > >> >>>>>>>>>> > >>>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>> > >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>>>>>>>> 8550 C311 0611 >>>>>>>>>> > >> >>>> >>>>>>>>>> > >> >>> >>>>>>>>>> > >> >>> >>>>>>>>>> > >> >> >>>>>>>>>> > >> > _______________________________________________ >>>>>>>>>> > >> > hibernate-dev mailing list >>>>>>>>>> > >> > hibernate-dev(a)lists.jboss.org >>>>>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> > >> >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > _______________________________________________ >>>>>>>>>> > hibernate-dev mailing list >>>>>>>>>> > hibernate-dev(a)lists.jboss.org >>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> > >>>>>>>>>> _______________________________________________ >>>>>>>>>> hibernate-dev mailing list >>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards, Petar! >>>>>>>>> Karlovo, Bulgaria. >>>>>>>>> --- >>>>>>>>> Public PGP Key at: >>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >>>>>>>>> 0611 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, Petar! >>>>>>>> Karlovo, Bulgaria. >>>>>>>> --- >>>>>>>> Public PGP Key at: >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, Petar! >>>> Karlovo, Bulgaria. >>>> --- >>>> Public PGP Key at: >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>> >>> >>> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> > >

And no, we generally do not reopen issues from Closed state. And here, given the different branches, I'd be more inclined to create a different issue referencing the original. On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Hmm, it seems I inadvertently set the wrong fix version on HHH-8805. It > is fixed in our metamodel branch which is 6.0. I pulled the necessary > metamodel (org.hibernate.mapping) changes back to master (5.0), but only > the hbm.xml form of naming the FK "none" (magic value) is supported to > truly disable generation. For the time being you can use this as well from > annotations; just name the FK "none". > > If you can write some tests for this, it will make it easier for me to > implement. > > > > On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; > wrote: > >> Oh, >> >> and one last thing: I don't think this is fixed: >> https://hibernate.atlassian.net/browse/HHH-8805 >> >> Here's my mapping: >> >> @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = { >> CascadeType.PERSIST, >> CascadeType.MERGE, >> CascadeType.REFRESH >> }, fetch = FetchType.LAZY) >> @JoinTable(indexes = { >> @Index(unique = false, columnList = "entity_pk") >> }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), >> inverseJoinColumns = { >> @JoinColumn(unique = false, nullable = true, insertable = true, >> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), >> name = "filter_pk") >> }, joinColumns = { >> @JoinColumn(unique = false, nullable = true, insertable = true, >> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), >> name = "entity_pk") >> }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = >> "entity_filters") >> private Collection<AbstractFilterModelDefinition> filters; >> >> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it is >> possible to add it. However here's what the schema tool generates: >> >> create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters >> (entity_pk); >> >> alter table entity_filters >> add constraint FKra38l70n01disvkge7i9ff5ym >> foreign key (filter_pk) >> references abstract_filter (pk); >> >> alter table entity_filters >> add constraint FKderx50xtd0lkeeblrj3o0ipq9 >> foreign key (entity_pk) >> references stock_level (pk); >> >> alter table entity_filters >> add constraint FK7ery3yx4pg32ogvv1wpr150oq >> foreign key (entity_pk) >> references content_slot (pk); >> >> alter table entity_filters >> add constraint FKse5m2mj7rrwj8ndimynfnr2px >> foreign key (entity_pk) >> references blog_entry (pk); >> >> alter table entity_filters >> add constraint FK9nubqtdhrmefjv2a5oab2fcr2 >> foreign key (entity_pk) >> references price (pk); >> >> alter table entity_filters >> add constraint FKcsuwqm524wu4u41oatrcalxvh >> foreign key (entity_pk) >> references tax (pk); >> >> alter table entity_filters >> add constraint FKmd3mm5pw9naa05ype38m6x1eo >> foreign key (entity_pk) >> references abstract_template (pk); >> >> alter table entity_filters >> add constraint FKsx6vnh2tga70pkne44dnq8kp0 >> foreign key (entity_pk) >> references discount (pk); >> >> alter table entity_filters >> add constraint FK6yx2wc1w1yb6qa1cx4byv7mju >> foreign key (entity_pk) >> references classification_feature (pk); >> >> alter table entity_filters >> add constraint FKpoh168do203hfqwb7so7c4c79 >> foreign key (entity_pk) >> references cms_navigation_node (pk); >> >> alter table entity_filters >> add constraint FKi85fkvbm7otl679ijlr6oyoff >> foreign key (entity_pk) >> references product (pk); >> >> alter table entity_filters >> add constraint FKi8semxf3lq0n12lm05v7oydeq >> foreign key (entity_pk) >> references abstract_page (pk); >> >> alter table entity_filters >> add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b >> foreign key (entity_pk) >> references promotion (pk); >> >> alter table entity_filters >> add constraint FKfw64whfl6vgbqehj20qmc39i3 >> foreign key (entity_pk) >> references simple_cms_widget (pk); >> >> The foreign keys are all different (in Hibernate 4.3.x they were the >> same), but I just don't want them. Shall I reopen the issue? >> >> >> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla(a)gmail.com&gt;: >> >>> One other thing I noticed: >>> hibernate-core-5 depends on >>> >>> <groupId>org.jboss.logging</groupId> >>> <artifactId>jboss-logging</artifactId> >>> <version>3.2.1.Final</version> >>> >>> and if you have hibernate-validator 5.1.3.Final (the last stable), it >>> will depend on >>> >>> <groupId>org.jboss.logging</groupId> >>> <artifactId>jboss-logging</artifactId> >>> <version>3.1.4.GA</version> >>> >>> So you will get an exception of method not found on some jboss-logging >>> API. I excluded the jboss-loggin from the hibernate-validator >>> dependency, but now I get a ton of these TRACE statements (literally >>> every millisecond): >>> >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> 2015-04-01 13:28:02,090 >>> org.hibernate.event.internal.DefaultPersistEventListener >>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance >>> >>> >>> But at least it works.. I guess the only real solution is to have >>> hibernate-validator use the same jboss-logging version. >>> >>> >>> 2015-04-01 10:39 GMT+03:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: >>> >>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> >>>> > Just to clarify... I *think* that as long as we run the build with >>>> Java 8 >>>> > and set the bootclasspath to 6 or 7 we should be fine. >>>> > >>>> >>>> Yes, setting the boot classpath to 6 (or 7) makes sure you only use >>>> classes >>>> present in that JDK (be it explicitly or implicitly as in the >>>> ConcurrentHashMap case), because it's that class library which will be >>>> used >>>> for compilation then. It is cumbersome to use though as you need to >>>> specify >>>> the location of a 6 or 7 JDK which makes the build less easily portable >>>> between machines. >>>> >>>> Currently, AnimalSniffer is in place to prevent this very category of >>>> error >>>> and I'm wondering why it didn't detect the "usage" of KeySetView. It >>>> really >>>> should have detected it, assuming it analyses the byte code of >>>> classes. But >>>> this makes me wonder now whether it only analyses the source code >>>> actually. >>>> Then it wouldn't be usable to prevent this sort of issue. >>>> >>>> Coding against the ConcurrentMap interface is the best way to avoid the >>>> issue. But of course there is no guarantee that it happens again, >>>> unless >>>> e.g. having a build on CI which uses 6 or 7 on its boot classpath. >>>> >>>> >>>> > On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole <steve(a)hibernate.org >>>> > >>>> > wrote: >>>> > >>>> > > Well the idea is to run the Gradle process with Java 8 (the build >>>> itself >>>> > > is a Java process too don't forget). We pass in the older JDK >>>> > specifically >>>> > > to be able to set the bootclasspath for compilation and the >>>> executable >>>> > for >>>> > > running tests. That's the theory. >>>> > > >>>> > > Interestingly I developed a simplified project to test these >>>> theories: >>>> > > https://github.com/sebersole/gradle-mixed-jdk And of course this >>>> all >>>> > > works there. As you'd expect right? >>>> > > >>>> > > I think the JAXB thing comes into play here as well. Gradle does >>>> not >>>> > have >>>> > > any XJC support built in, so we have to make use of its Ant >>>> support to >>>> > run >>>> > > the XJC Ant tasks for JAXB model generation. The problem there is >>>> that, >>>> > > afaik, there is no way to tell Gradle's AntBuilder to use a JDK >>>> other >>>> > than >>>> > > the one that launched Gradle. I think this is why we see a JAXB >>>> model >>>> > > defined for Java 7, rather than Java 6, because we essentially run >>>> XJC >>>> > with >>>> > > Java 8. >>>> > > >>>> > > Anyway, this certainly makes the build more complex and we >>>> definitely >>>> > have >>>> > > to think through all these scenarios. In fact after Beta1, one of >>>> my >>>> > todos >>>> > > is to build up the build "from scratch" using that gradle-mixed-jdk >>>> > project >>>> > > as a basis. >>>> > > >>>> > > In general the plan though is to run all the tests (other than >>>> > > hibernate-java8, obviously) with the "baseline JDK, whether that >>>> be Java >>>> > 6 >>>> > > or 7. >>>> > > >>>> > > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>> sanne(a)hibernate.org&gt; >>>> > > wrote: >>>> > > >>>> > >> There are many similar issues discussed on the Lucene developer's >>>> > >> mailing list, it's an interesting read: >>>> > >> - >>>> > >> >>>> > >>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>> > >> >>>> > >> I see no alternative than to have those test jobs actually >>>> exercising >>>> > >> ORM with JDK6, or maybe even compile it all with JDK6 except the >>>> Java8 >>>> > >> additional module to be compiled with JDK8 ? >>>> > >> >>>> > >> >>>> > >> >>>> > >> On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> > >> > Ahh, seems this may be an option to work around it: >>>> > >> > >>>> > >> > <quote> >>>> > >> > Using the general *Map* interface in place of the concrete >>>> > >> > *ConcurrentHashMap* type here side-steps the coupling to the >>>> Java 8 >>>> > >> return >>>> > >> > type and will allow this code to be compiled with Java 8 and >>>> run on >>>> > >> Java 7. >>>> > >> > </quote> >>>> > >> > >>>> > >> > I had missed that part. >>>> > >> > >>>> > >> > >>>> > >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>> steve(a)hibernate.org&gt; >>>> > >> wrote: >>>> > >> > >>>> > >> >> When I say "internal" here, I mean internal to java classes. >>>> > >> >> >>>> > >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>> steve(a)hibernate.org >>>> > > >>>> > >> >> wrote: >>>> > >> >> >>>> > >> >>> Nope. It just effects any code compiled with Java 8 even >>>> though the >>>> > >> >>> change is internal. The problem is the generated bytecode >>>> > >> incorporates >>>> > >> >>> this change. Like I said, this should be compiled with 1.6 >>>> > >> compatibility, >>>> > >> >>> but that is apparently not working atm. I am having a >>>> struggle >>>> > >> getting a >>>> > >> >>> mixed JDK build working "just right". >>>> > >> >>> >>>> > >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>> > >> paranoiabla(a)gmail.com&gt; >>>> > >> >>> wrote: >>>> > >> >>> >>>> > >> >>>> According to this: >>>> > >> >>>> >>>> > >> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>> > >> >>>> >>>> > >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a >>>> Set<K> >>>> > >> while >>>> > >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>> > >> >>>> ConcurrentHashMap.KeySetView<K,V>`. >>>> > >> >>>> >>>> > >> >>>> I think you're using some Java8 API. >>>> > >> >>>> >>>> > >> >>>> >>>> > >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>> paranoiabla(a)gmail.com&gt;: >>>> > >> >>>> >>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>> > >> >>>>> java version "1.7.0_71" >>>> > >> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>> > >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed >>>> mode) >>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>> > >> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu >>>> SMP >>>> > Thu >>>> > >> Mar >>>> > >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>> steve(a)hibernate.org&gt;: >>>> > >> >>>>> >>>> > >> >>>>>> What JRE are you trying to use? This error: >>>> > >> >>>>>> >>>> > >> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>> > >> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>> > >> >>>>>> ConcurrentHashMap$KeySetView; >>>> > >> >>>>>> >>>> > >> >>>>>> is indicative of an issue in cross-jre support due to a >>>> change >>>> > >> >>>>>> internal to java classes. >>>> > >> >>>>>> >>>> > >> >>>>>> >>>> > >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>> > >> paranoiabla(a)gmail.com >>>> > >> >>>>>> > wrote: >>>> > >> >>>>>> >>>> > >> >>>>>>> Thanks Steve, >>>> > >> >>>>>>> >>>> > >> >>>>>>> I managed to migrate my configuration to the new >>>> > >> >>>>>>> MetamodelImplementor. Now when I run the scema export I >>>> get a >>>> > lot >>>> > >> of these >>>> > >> >>>>>>> warning: >>>> > >> >>>>>>> >>>> > >> >>>>>>> INFO : HHH000400: Using dialect: >>>> > >> org.hibernate.dialect.MySQL5Dialect >>>> > >> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers >>>> in both >>>> > >> mixed >>>> > >> >>>>>>> and upper case >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> > >> >>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> > com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >>>> > >> >>>>>>> >>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>> > >> >>>>>>> >>>> > >> >>>>>>> and when I run some test I get the following exception: >>>> > >> >>>>>>> java.lang.NoSuchMethodError: >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>> > >> >>>>>>> at >>>> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>> > >> >>>>>>> at >>>> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>> > >> >>>>>>> at >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>> steve(a)hibernate.org&gt;: >>>> > >> >>>>>>> >>>> > >> >>>>>>>> I am told that the bug does not affect the >>>> JBoss->Central sync >>>> > >> >>>>>>>> process. So at some point the artifacts should all be >>>> > available >>>> > >> in Central >>>> > >> >>>>>>>> >>>> > >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>>> > >> steve(a)hibernate.org >>>> > >> >>>>>>>> > wrote: >>>> > >> >>>>>>>> >>>> > >> >>>>>>>>> hibernate-core seems to be the only artifact that is >>>> available >>>> > >> in >>>> > >> >>>>>>>>> JBoss Nexus. >>>> > >> >>>>>>>>> >>>> > >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>> > >> >>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>> > >> >>>>>>>>> >>>> > >> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus >>>> bug that >>>> > is >>>> > >> >>>>>>>>>> effecting the JBoss repo (and therefore us)... >>>> > >> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>>> As I pointed out in the announcement, I am managing the >>>> > >> "migration >>>> > >> >>>>>>>>>> guide" in source repo while I develop the Betas. See >>>> > >> >>>>>>>>>> >>>> > >> >>>> > >>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>> > >> >>>>>>>>>> As far are the new bootstrapping apis, see >>>> > >> >>>>>>>>>> >>>> > >> >>>> > >>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>> > >> >>>>>>>>>> and >>>> > >> >>>>>>>>>> >>>> > >> >>>> > >>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>> > >> >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>>>> Hi guys, >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> I just tried the latest beta and I cannot compile my >>>> > project. >>>> > >> >>>>>>>>>>> With the >>>> > >> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>> > >> >>>>>>>>>>> ------- >>>> > >> >>>>>>>>>>> final org.hibernate.cfg.Configuration >>>> configuration >>>> > = >>>> > >> >>>>>>>>>>> getHibernateConfiguration(); >>>> > >> >>>>>>>>>>> configuration.buildMappings(); >>>> > >> >>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>> > >> >>>>>>>>>>> SchemaUpdate(configuration); >>>> > >> >>>>>>>>>>> ------- >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> however it seems that the SchemaUpdate constructor >>>> has been >>>> > >> >>>>>>>>>>> removed and now >>>> > >> >>>>>>>>>>> a new one is added: >>>> > >> >>>>>>>>>>> -------- >>>> > >> >>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) >>>> { >>>> > >> >>>>>>>>>>> this( >>>> > >> >>>>>>>>>>> >>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>> > >> >>>>>>>>>>> metadata ); >>>> > >> >>>>>>>>>>> } >>>> > >> >>>>>>>>>>> --------- >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> Also the configuration.buildMappings() method has been >>>> > >> >>>>>>>>>>> deprecated. Where do >>>> > >> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any >>>> > >> changelog I >>>> > >> >>>>>>>>>>> can refer >>>> > >> >>>>>>>>>>> to? >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> Thanks. >>>> > >> >>>>>>>>>>> -- >>>> > >> >>>>>>>>>>> Regards, Petar! >>>> > >> >>>>>>>>>>> Karlovo, Bulgaria. >>>> > >> >>>>>>>>>>> --- >>>> > >> >>>>>>>>>>> Public PGP Key at: >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>>> >>>> > >> >>>> > >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> > >> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>> 8550 >>>> > C311 >>>> > >> >>>>>>>>>>> 0611 >>>> > >> >>>>>>>>>>> _______________________________________________ >>>> > >> >>>>>>>>>>> hibernate-dev mailing list >>>> > >> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>> > >> >>>>>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >> >>>>>>>>>>> >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>>> >>>> > >> >>>>>>>>> >>>> > >> >>>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> -- >>>> > >> >>>>>>> Regards, Petar! >>>> > >> >>>>>>> Karlovo, Bulgaria. >>>> > >> >>>>>>> --- >>>> > >> >>>>>>> Public PGP Key at: >>>> > >> >>>>>>> >>>> > >> >>>> > >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> > >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>> C311 >>>> > >> 0611 >>>> > >> >>>>>>> >>>> > >> >>>>>> >>>> > >> >>>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> -- >>>> > >> >>>>> Regards, Petar! >>>> > >> >>>>> Karlovo, Bulgaria. >>>> > >> >>>>> --- >>>> > >> >>>>> Public PGP Key at: >>>> > >> >>>>> >>>> > >> >>>> > >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> > >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>> C311 >>>> > 0611 >>>> > >> >>>>> >>>> > >> >>>> >>>> > >> >>>> >>>> > >> >>>> >>>> > >> >>>> -- >>>> > >> >>>> Regards, Petar! >>>> > >> >>>> Karlovo, Bulgaria. >>>> > >> >>>> --- >>>> > >> >>>> Public PGP Key at: >>>> > >> >>>> >>>> > >> >>>> > >>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>> > >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>> C311 0611 >>>> > >> >>>> >>>> > >> >>> >>>> > >> >>> >>>> > >> >> >>>> > >> > _______________________________________________ >>>> > >> > hibernate-dev mailing list >>>> > >> > hibernate-dev(a)lists.jboss.org >>>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >> >>>> > > >>>> > > >>>> > _______________________________________________ >>>> > hibernate-dev mailing list >>>> > hibernate-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> >>> >>> -- >>> Regards, Petar! >>> Karlovo, Bulgaria. >>> --- >>> Public PGP Key at: >>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>> >> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> > >

Hi Petar, the version issue of jboss-logging is a known limitation; I've described some details on the wildfly-dev mailing list. I was expecting for people to choose the most up to date version of jboss-logging in case of conflicting versions though, or manage the version explicitly rather than leaving the choice to the build tool. The TRACE problem was not expected of course. May I assume you have the TRACE level enabled? Thanks, Sanne On 1 April 2015 at 11:32, Petar Tahchiev <paranoiabla(a)gmail.com&gt; wrote: > One other thing I noticed: > hibernate-core-5 depends on > > <groupId>org.jboss.logging</groupId> > <artifactId>jboss-logging</artifactId> > <version>3.2.1.Final</version> > > and if you have hibernate-validator 5.1.3.Final (the last stable), it will > depend on > > <groupId>org.jboss.logging</groupId> > <artifactId>jboss-logging</artifactId> > <version>3.1.4.GA</version> > > So you will get an exception of method not found on some jboss-logging API. > I excluded the jboss-loggin from the hibernate-validator > dependency, but now I get a ton of these TRACE statements (literally every > millisecond): > > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > 2015-04-01 13:28:02,090 > org.hibernate.event.internal.DefaultPersistEventListener > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance > > > But at least it works.. I guess the only real solution is to have > hibernate-validator use the same jboss-logging version. > > > 2015-04-01 10:39 GMT+03:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: > >> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >> > Just to clarify... I *think* that as long as we run the build with Java >> 8 >> > and set the bootclasspath to 6 or 7 we should be fine. >> > >> >> Yes, setting the boot classpath to 6 (or 7) makes sure you only use classes >> present in that JDK (be it explicitly or implicitly as in the >> ConcurrentHashMap case), because it's that class library which will be used >> for compilation then. It is cumbersome to use though as you need to specify >> the location of a 6 or 7 JDK which makes the build less easily portable >> between machines. >> >> Currently, AnimalSniffer is in place to prevent this very category of error >> and I'm wondering why it didn't detect the "usage" of KeySetView. It really >> should have detected it, assuming it analyses the byte code of classes. But >> this makes me wonder now whether it only analyses the source code actually. >> Then it wouldn't be usable to prevent this sort of issue. >> >> Coding against the ConcurrentMap interface is the best way to avoid the >> issue. But of course there is no guarantee that it happens again, unless >> e.g. having a build on CI which uses 6 or 7 on its boot classpath. >> >> >> > On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole <steve(a)hibernate.org&gt; >> > wrote: >> > >> > > Well the idea is to run the Gradle process with Java 8 (the build >> itself >> > > is a Java process too don't forget). We pass in the older JDK >> > specifically >> > > to be able to set the bootclasspath for compilation and the executable >> > for >> > > running tests. That's the theory. >> > > >> > > Interestingly I developed a simplified project to test these theories: >> > > https://github.com/sebersole/gradle-mixed-jdk And of course this all >> > > works there. As you'd expect right? >> > > >> > > I think the JAXB thing comes into play here as well. Gradle does not >> > have >> > > any XJC support built in, so we have to make use of its Ant support to >> > run >> > > the XJC Ant tasks for JAXB model generation. The problem there is >> that, >> > > afaik, there is no way to tell Gradle's AntBuilder to use a JDK other >> > than >> > > the one that launched Gradle. I think this is why we see a JAXB model >> > > defined for Java 7, rather than Java 6, because we essentially run XJC >> > with >> > > Java 8. >> > > >> > > Anyway, this certainly makes the build more complex and we definitely >> > have >> > > to think through all these scenarios. In fact after Beta1, one of my >> > todos >> > > is to build up the build "from scratch" using that gradle-mixed-jdk >> > project >> > > as a basis. >> > > >> > > In general the plan though is to run all the tests (other than >> > > hibernate-java8, obviously) with the "baseline JDK, whether that be >> Java >> > 6 >> > > or 7. >> > > >> > > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < sanne(a)hibernate.org&gt; >> > > wrote: >> > > >> > >> There are many similar issues discussed on the Lucene developer's >> > >> mailing list, it's an interesting read: >> > >> - >> > >> >> > >> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >> > >> >> > >> I see no alternative than to have those test jobs actually exercising >> > >> ORM with JDK6, or maybe even compile it all with JDK6 except the Java8 >> > >> additional module to be compiled with JDK8 ? >> > >> >> > >> >> > >> >> > >> On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; wrote: >> > >> > Ahh, seems this may be an option to work around it: >> > >> > >> > >> > <quote> >> > >> > Using the general *Map* interface in place of the concrete >> > >> > *ConcurrentHashMap* type here side-steps the coupling to the Java 8 >> > >> return >> > >> > type and will allow this code to be compiled with Java 8 and run on >> > >> Java 7. >> > >> > </quote> >> > >> > >> > >> > I had missed that part. >> > >> > >> > >> > >> > >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >> steve(a)hibernate.org&gt; >> > >> wrote: >> > >> > >> > >> >> When I say "internal" here, I mean internal to java classes. >> > >> >> >> > >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >> steve(a)hibernate.org >> > > >> > >> >> wrote: >> > >> >> >> > >> >>> Nope. It just effects any code compiled with Java 8 even though >> the >> > >> >>> change is internal. The problem is the generated bytecode >> > >> incorporates >> > >> >>> this change. Like I said, this should be compiled with 1.6 >> > >> compatibility, >> > >> >>> but that is apparently not working atm. I am having a struggle >> > >> getting a >> > >> >>> mixed JDK build working "just right". >> > >> >>> >> > >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >> > >> paranoiabla(a)gmail.com&gt; >> > >> >>> wrote: >> > >> >>> >> > >> >>>> According to this: >> > >> >>>> >> > >> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >> > >> >>>> >> > >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a >> Set<K> >> > >> while >> > >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a >> > >> >>>> ConcurrentHashMap.KeySetView<K,V>`. >> > >> >>>> >> > >> >>>> I think you're using some Java8 API. >> > >> >>>> >> > >> >>>> >> > >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < paranoiabla(a)gmail.com >> >: >> > >> >>>> >> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >> > >> >>>>> java version "1.7.0_71" >> > >> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >> > >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) >> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >> > >> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP >> > Thu >> > >> Mar >> > >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < steve(a)hibernate.org&gt;: >> > >> >>>>> >> > >> >>>>>> What JRE are you trying to use? This error: >> > >> >>>>>> >> > >> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >> > >> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >> > >> >>>>>> ConcurrentHashMap$KeySetView; >> > >> >>>>>> >> > >> >>>>>> is indicative of an issue in cross-jre support due to a change >> > >> >>>>>> internal to java classes. >> > >> >>>>>> >> > >> >>>>>> >> > >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >> > >> paranoiabla(a)gmail.com >> > >> >>>>>> > wrote: >> > >> >>>>>> >> > >> >>>>>>> Thanks Steve, >> > >> >>>>>>> >> > >> >>>>>>> I managed to migrate my configuration to the new >> > >> >>>>>>> MetamodelImplementor. Now when I run the scema export I get a >> > lot >> > >> of these >> > >> >>>>>>> warning: >> > >> >>>>>>> >> > >> >>>>>>> INFO : HHH000400: Using dialect: >> > >> org.hibernate.dialect.MySQL5Dialect >> > >> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in >> both >> > >> mixed >> > >> >>>>>>> and upper case >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> >> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> >> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> >> > >> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> >> > com.xxx.platform.module.search.core.model.SearchPageRedirectModel >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for class: >> > >> >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >> > >> >>>>>>> >> > >> >>>>>>> and when I run some test I get the following exception: >> > >> >>>>>>> java.lang.NoSuchMethodError: >> > >> >>>>>>> >> > >> >> > >> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >> > >> >>>>>>> at >> > >> >>>>>>> >> > org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >> > >> >>>>>>> at >> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >> > >> >>>>>>> at >> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >> > >> >>>>>>> at >> > >> >>>>>>> >> > >> >> > >> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >> > >> >>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < steve(a)hibernate.org >> >: >> > >> >>>>>>> >> > >> >>>>>>>> I am told that the bug does not affect the JBoss->Central >> sync >> > >> >>>>>>>> process. So at some point the artifacts should all be >> > available >> > >> in Central >> > >> >>>>>>>> >> > >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >> > >> steve(a)hibernate.org >> > >> >>>>>>>> > wrote: >> > >> >>>>>>>> >> > >> >>>>>>>>> hibernate-core seems to be the only artifact that is >> available >> > >> in >> > >> >>>>>>>>> JBoss Nexus. >> > >> >>>>>>>>> >> > >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >> > >> >>>>>>>>> steve(a)hibernate.org&gt; wrote: >> > >> >>>>>>>>> >> > >> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug >> that >> > is >> > >> >>>>>>>>>> effecting the JBoss repo (and therefore us)... >> > >> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> As I pointed out in the announcement, I am managing the >> > >> "migration >> > >> >>>>>>>>>> guide" in source repo while I develop the Betas. See >> > >> >>>>>>>>>> >> > >> >> > >> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >> > >> >>>>>>>>>> As far are the new bootstrapping apis, see >> > >> >>>>>>>>>> >> > >> >> > >> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >> > >> >>>>>>>>>> and >> > >> >>>>>>>>>> >> > >> >> > >> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >> > >> >>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >> > >> >>>>>>>>>> >> > >> >>>>>>>>>>> Hi guys, >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> I just tried the latest beta and I cannot compile my >> > project. >> > >> >>>>>>>>>>> With the >> > >> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >> > >> >>>>>>>>>>> ------- >> > >> >>>>>>>>>>> final org.hibernate.cfg.Configuration >> configuration >> > = >> > >> >>>>>>>>>>> getHibernateConfiguration(); >> > >> >>>>>>>>>>> configuration.buildMappings(); >> > >> >>>>>>>>>>> final SchemaUpdate schemaUpdate = new >> > >> >>>>>>>>>>> SchemaUpdate(configuration); >> > >> >>>>>>>>>>> ------- >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> however it seems that the SchemaUpdate constructor has >> been >> > >> >>>>>>>>>>> removed and now >> > >> >>>>>>>>>>> a new one is added: >> > >> >>>>>>>>>>> -------- >> > >> >>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) { >> > >> >>>>>>>>>>> this( >> > >> >>>>>>>>>>> >> metadata.getMetadataBuildingOptions().getServiceRegistry(), >> > >> >>>>>>>>>>> metadata ); >> > >> >>>>>>>>>>> } >> > >> >>>>>>>>>>> --------- >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> Also the configuration.buildMappings() method has been >> > >> >>>>>>>>>>> deprecated. Where do >> > >> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any >> > >> changelog I >> > >> >>>>>>>>>>> can refer >> > >> >>>>>>>>>>> to? >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> Thanks. >> > >> >>>>>>>>>>> -- >> > >> >>>>>>>>>>> Regards, Petar! >> > >> >>>>>>>>>>> Karlovo, Bulgaria. >> > >> >>>>>>>>>>> --- >> > >> >>>>>>>>>>> Public PGP Key at: >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>>> >> > >> >> > >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> > >> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >> > C311 >> > >> >>>>>>>>>>> 0611 >> > >> >>>>>>>>>>> _______________________________________________ >> > >> >>>>>>>>>>> hibernate-dev mailing list >> > >> >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >> > >> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> >>>>>>>>>>> >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> >> > >> >>>>>>>>> >> > >> >>>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> -- >> > >> >>>>>>> Regards, Petar! >> > >> >>>>>>> Karlovo, Bulgaria. >> > >> >>>>>>> --- >> > >> >>>>>>> Public PGP Key at: >> > >> >>>>>>> >> > >> >> > >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> > >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >> > >> 0611 >> > >> >>>>>>> >> > >> >>>>>> >> > >> >>>>>> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> -- >> > >> >>>>> Regards, Petar! >> > >> >>>>> Karlovo, Bulgaria. >> > >> >>>>> --- >> > >> >>>>> Public PGP Key at: >> > >> >>>>> >> > >> >> > >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> > >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >> > 0611 >> > >> >>>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> -- >> > >> >>>> Regards, Petar! >> > >> >>>> Karlovo, Bulgaria. >> > >> >>>> --- >> > >> >>>> Public PGP Key at: >> > >> >>>> >> > >> >> > >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> > >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >> 0611 >> > >> >>>> >> > >> >>> >> > >> >>> >> > >> >> >> > >> > _______________________________________________ >> > >> > hibernate-dev mailing list >> > >> > hibernate-dev(a)lists.jboss.org >> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> >> > > >> > > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

petar@petar-ThinkPad-X1-Carbon:~$ java -version java version "1.7.0_71" Java(TM) SE Runtime Environment (build 1.7.0_71-b14) Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) petar@petar-ThinkPad-X1-Carbon:~$ uname -a Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP Thu Mar 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux petar@petar-ThinkPad-X1-Carbon:~$ 2015-04-01 2:21 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > What JRE are you trying to use? This error: > > java.lang.NoSuchMethodError: java.util.concurrent. > ConcurrentHashMap.keySet()Ljava/util/concurrent/ > ConcurrentHashMap$KeySetView; > > is indicative of an issue in cross-jre support due to a change internal > to java classes. > > > On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; > wrote: > >> Thanks Steve, >> >> I managed to migrate my configuration to the new MetamodelImplementor. >> Now when I run the scema export I get a lot of these warning: >> >> INFO : HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect >> WARN : JDBC Driver reports it stores quoted identifiers in both mixed >> and upper case >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.core.model.cms.AbstractPageModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.module.invoice.core.model.InvoicePageModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >> WARN : HHH000072: Duplicate joins for class: >> com.xxx.platform.module.promotion.core.model.PromotionModel >> >> and when I run some test I get the following exception: >> java.lang.NoSuchMethodError: >> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >> at >> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >> at >> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >> at >> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >> at >> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >> at >> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >> at >> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >> at org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >> at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >> at org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >> at >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >> at >> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >> at >> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >> >> >> >> >> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> I am told that the bug does not affect the JBoss->Central sync >>> process. So at some point the artifacts should all be available in Central >>> >>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> hibernate-core seems to be the only artifact that is available in >>>> JBoss Nexus. >>>> >>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> So apparently the artifacts / repo issue is a Nexus bug that is >>>>> effecting the JBoss repo (and therefore us)... >>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>> >>>>> As I pointed out in the announcement, I am managing the "migration >>>>> guide" in source repo while I develop the Betas. See >>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>> As far are the new bootstrapping apis, see >>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>> and >>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>> >>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>> >>>>>> Hi guys, >>>>>> >>>>>> I just tried the latest beta and I cannot compile my project. With >>>>>> the >>>>>> latest hibernate 4.3.X I was able to do this: >>>>>> ------- >>>>>> final org.hibernate.cfg.Configuration configuration = >>>>>> getHibernateConfiguration(); >>>>>> configuration.buildMappings(); >>>>>> final SchemaUpdate schemaUpdate = new >>>>>> SchemaUpdate(configuration); >>>>>> ------- >>>>>> >>>>>> however it seems that the SchemaUpdate constructor has been removed >>>>>> and now >>>>>> a new one is added: >>>>>> -------- >>>>>> public SchemaUpdate(MetadataImplementor metadata) { >>>>>> this( >>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>> metadata ); >>>>>> } >>>>>> --------- >>>>>> >>>>>> Also the configuration.buildMappings() method has been deprecated. >>>>>> Where do >>>>>> I get the MetadataImplementor from? Also is there any changelog I >>>>>> can refer >>>>>> to? >>>>>> >>>>>> Thanks. >>>>>> -- >>>>>> Regards, Petar! >>>>>> Karlovo, Bulgaria. >>>>>> --- >>>>>> Public PGP Key at: >>>>>> >>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> > > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611