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
