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
