Wow, that's interesting. When I set the hbm2ddl-auto property to *create*, then I get a lot of these:
2015-04-06 10:35:14,243 org.hibernate.tool.hbm2ddl.SchemaExport [main] ERROR: HHH000389: Unsuccessful: alter table abstract_order drop constraint FKqmp2kh2yeov0xhpk0heyrxg6q 2015-04-06 10:35:14,243 org.hibernate.tool.hbm2ddl.SchemaExport [main] ERROR: user lacks privilege or object not found: PUBLIC.ABSTRACT_ORDER 2015-04-06 10:35:14,243 org.hibernate.tool.hbm2ddl.SchemaExport [main] ERROR: HHH000389: Unsuccessful: alter table abstract_order drop constraint FKni48bu7u20jisn95bc32ssqbm but then it all seems to work fine. However, if I set it up to *update* it throws the "BIG PROBLEM" in the SchemaMigratorImpl as I explained above. This is a different behaviour than Hibernate 4.3.x and i'm not sure if it is bug or maybe the update value has been deprecated... 2015-04-06 9:34 GMT+03:00 Petar Tahchiev <paranoia...@gmail.com>: > 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 <st...@hibernate.org>: > >> 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 <paranoia...@gmail.com> >> 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 <emman...@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 <st...@hibernate.org> 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 <gun...@hibernate.org> >>>> 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 <st...@hibernate.org>: >>>> >> >>>> >>> Gunnar, it is applied. Add something that is java 8 specific and >>>> see... >>>> >>> On Apr 1, 2015 7:59 AM, "Gunnar Morling" <gun...@hibernate.org> >>>> 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 <st...@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 < >>>> gun...@hibernate.org> >>>> >>>>> 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/5f6d1d24f7945eb8a5acdb69d9595004ec4e462f >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> 2015-04-01 9:39 GMT+02:00 Gunnar Morling <gun...@hibernate.org>: >>>> >>>>>> >>>> >>>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <st...@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 < >>>> st...@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 < >>>> >>>>>>>> sa...@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/%3C07c401d06aba%240b477c80%2421d67580%24%40thetaphi.de%3E >>>> >>>>>>>>>> >>>> >>>>>>>>>> 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 < >>>> st...@hibernate.org> >>>> >>>>>>>> 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 < >>>> >>>>>>>> st...@hibernate.org> >>>> >>>>>>>>>> wrote: >>>> >>>>>>>>>>> >>>> >>>>>>>>>>>> When I say "internal" here, I mean internal to java >>>> classes. >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>> >>>>>>>> st...@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 < >>>> >>>>>>>>>> paranoia...@gmail.com> >>>> >>>>>>>>>>>>> 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 < >>>> >>>>>>>> paranoia...@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 < >>>> >>>>>>>> st...@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 < >>>> >>>>>>>>>> paranoia...@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 < >>>> >>>>>>>> st...@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 < >>>> >>>>>>>>>> st...@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 < >>>> >>>>>>>>>>>>>>>>>>> st...@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-migration-guide.md >>>> >>>>>>>>>>>>>>>>>>>> As far are the new bootstrapping apis, see >>>> >>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html >>>> >>>>>>>>>>>>>>>>>>>> and >>>> >>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html >>>> >>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>> >>>>>>>>>>>>>>>>>>>> paranoia...@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@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@lists.jboss.org >>>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>> _______________________________________________ >>>> >>>>>>>> hibernate-dev mailing list >>>> >>>>>>>> hibernate-dev@lists.jboss.org >>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>> >>>> >>>> >>>> >> >>>> > _______________________________________________ >>>> > hibernate-dev mailing list >>>> > hibernate-dev@lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
