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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
