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
