[hibernate-dev] Trying Hibernate 5.0.0.Beta1
Petar Tahchiev
paranoiabla at gmail.com
Mon Apr 6 02:34:47 EDT 2015
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 at 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 <paranoiabla at 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 <emmanuel at 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 at 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 <gunnar at 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 <steve at 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 at 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 <steve at 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 at 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 <gunnar at hibernate.org>:
>>> >>>>>>
>>> >>>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve at 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 at 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 at 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 <steve at 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 <
>>> >>>>>>>> steve at 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 <
>>> >>>>>>>> steve at 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 at 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 <
>>> >>>>>>>> paranoiabla at gmail.com>:
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> petar at 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 at 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 at petar-ThinkPad-X1-Carbon:~$
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <
>>> >>>>>>>> steve at 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 at 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 at 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 at 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 at 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 <
>>> >>>>>>>>>>>>>>>>>>>> paranoiabla at 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 at 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 at lists.jboss.org
>>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>> _______________________________________________
>>> >>>>>>>> hibernate-dev mailing list
>>> >>>>>>>> hibernate-dev at lists.jboss.org
>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at 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
More information about the hibernate-dev
mailing list