From steve at hibernate.org  Tue Jul  1 12:39:18 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 1 Jul 2014 11:39:18 -0500
Subject: [hibernate-dev] IRC Developer Meeting
Message-ID: <CAFdSV9sypW-ZPKOjNx7-8rAHkFeb-a9dpYyt3yCTMxqsyjNA+w@mail.gmail.com>

Discussed EntityEntry/EntityKey memory enhancements and continued
JdbcSession design discussion...

[11:37] <jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-01-14.41.html
[11:37] <jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-01-14.41.txt
[11:37] <jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-01-14.41.log.html

From sanne at hibernate.org  Tue Jul  1 13:54:50 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 1 Jul 2014 19:54:50 +0200
Subject: [hibernate-dev] Thread-Safety of NoopOptimizer
Message-ID: <CAFm4XO1rtmmV5fpurFUAbOB8-iX6AcFy5WNJmEEAa7vL6OqB2A@mail.gmail.com>

I'm trying to understand if the NoopOptimizer could drop the
"synchronized" at line 53.

I added the synchronization myself some months ago, when we discovered
that we could remove a level of synchronization which was more coarse
grained, but then when inspecting the safety of the various smaller
parts, when hitting the NoopOptimizer I wasn't too sure - as the
AccessCallback is pluggable - and opted to be safe rather than sorry
as I thought this Optimizer would not be used in a high-performance
use case.

It seems I was wrong an some people actually use this Optimizer in a
scenario needing high scalability, and this one also happens to be the
default Optimizer.

By looking at all AccessCallback implementors in the ORM codebase, it
looks like safe to remove the synchronization, but are there reliable
tests I could use to verify this?

There are some more optimisations that come to mind when looking into
the various Optimizer and Generator implementors, but I don't feel
comfortable into changing these without running some stress tests.

TiA,
Sanne

From smarlow at redhat.com  Wed Jul  2 14:36:54 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 02 Jul 2014 14:36:54 -0400
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To: <A9C93719-2B63-4E30-B3DC-65F1F5071BBF@hibernate.org>
References: <A9C93719-2B63-4E30-B3DC-65F1F5071BBF@hibernate.org>
Message-ID: <53B45146.3030507@redhat.com>

On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X and IntelliJ IDEA so here are a few tidbits:
>
> I give Gradle 1GB
>
>      export GRADLE_OPTS="-Xmx1024M"

Are you on master or an earlier ORM branch?  I have 
GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora 
takes all available CPU (feels like my ThinkPad is on its knees until 
the build completes).


>
> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core subsystem. Basically at least one of the worker hangs for ever.
> To work around that I forced Gradle to use one thread
>
>      ./gradlew -no-daemon --parallel-threads 1 clean test

Thanks for the tip, I will try this.

>
> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that is to use `./gradlew idea` and open the project in the IDE. You then have to manually add the generated source directory in a few modules.
> Things are explained here: https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From smarlow at redhat.com  Wed Jul  2 15:43:22 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 02 Jul 2014 15:43:22 -0400
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To: <53B45146.3030507@redhat.com>
References: <A9C93719-2B63-4E30-B3DC-65F1F5071BBF@hibernate.org>
	<53B45146.3030507@redhat.com>
Message-ID: <53B460DA.9010005@redhat.com>

On 07/02/2014 02:36 PM, Scott Marlow wrote:
> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
>> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X and IntelliJ IDEA so here are a few tidbits:
>>
>> I give Gradle 1GB
>>
>>       export GRADLE_OPTS="-Xmx1024M"
>
> Are you on master or an earlier ORM branch?  I have
> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
> takes all available CPU (feels like my ThinkPad is on its knees until
> the build completes).

For me, when I run the testsuite on the master branch, my cpu gets 
pegged at 100% utilization.

>
>
>>
>> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core subsystem. Basically at least one of the worker hangs for ever.
>> To work around that I forced Gradle to use one thread
>>
>>       ./gradlew -no-daemon --parallel-threads 1 clean test
>
> Thanks for the tip, I will try this.

This (-no-daemon --parallel-threads 1) didn't help me.  Eventually, the 
testsuite will complete but it seems to take a long time (45 minutes or 
so).  I also tried setting GRADLE_OPTS="-Xmx1024M" but that didn't help.

>
>>
>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that is to use `./gradlew idea` and open the project in the IDE. You then have to manually add the generated source directory in a few modules.
>> Things are explained here: https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
>>
>> Emmanuel
>> _______________________________________________
>> 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
>


From smarlow at redhat.com  Wed Jul  2 17:24:01 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 02 Jul 2014 17:24:01 -0400
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To: <53B460DA.9010005@redhat.com>
References: <A9C93719-2B63-4E30-B3DC-65F1F5071BBF@hibernate.org>	<53B45146.3030507@redhat.com>
	<53B460DA.9010005@redhat.com>
Message-ID: <53B47871.5000102@redhat.com>

I removed GRADLE_OPTS and ran again with "-no-daemon --parallel-threads 
1" and my laptop still pegged the cpu at 100% but seemed a little more 
responsive.  From running TOP, I could see that six or seven separate 
Java processes are running (if each one is taking up to 1gig of memory 
on my 8 gig laptop, that could explain why I'm seeing thrashing).

On 07/02/2014 03:43 PM, Scott Marlow wrote:
> On 07/02/2014 02:36 PM, Scott Marlow wrote:
>> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
>>> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X and IntelliJ IDEA so here are a few tidbits:
>>>
>>> I give Gradle 1GB
>>>
>>>        export GRADLE_OPTS="-Xmx1024M"
>>
>> Are you on master or an earlier ORM branch?  I have
>> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
>> takes all available CPU (feels like my ThinkPad is on its knees until
>> the build completes).
>
> For me, when I run the testsuite on the master branch, my cpu gets
> pegged at 100% utilization.
>
>>
>>
>>>
>>> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core subsystem. Basically at least one of the worker hangs for ever.
>>> To work around that I forced Gradle to use one thread
>>>
>>>        ./gradlew -no-daemon --parallel-threads 1 clean test
>>
>> Thanks for the tip, I will try this.
>
> This (-no-daemon --parallel-threads 1) didn't help me.  Eventually, the
> testsuite will complete but it seems to take a long time (45 minutes or
> so).  I also tried setting GRADLE_OPTS="-Xmx1024M" but that didn't help.
>
>>
>>>
>>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that is to use `./gradlew idea` and open the project in the IDE. You then have to manually add the generated source directory in a few modules.
>>> Things are explained here: https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
>>>
>>> Emmanuel
>>> _______________________________________________
>>> 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
>


From emmanuel at hibernate.org  Thu Jul  3 12:03:26 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 3 Jul 2014 18:03:26 +0200
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To: <53B460DA.9010005@redhat.com>
References: <A9C93719-2B63-4E30-B3DC-65F1F5071BBF@hibernate.org>
	<53B45146.3030507@redhat.com> <53B460DA.9010005@redhat.com>
Message-ID: <C0F29479-7E36-40C4-B014-629174912F29@hibernate.org>

For me the test suite would not even complete, it would hang after ~2500 tests with 0 CPU usage for ever without the --parallel-threads 1 option so it?s a matter of life and death for my setup ;)
With that option, it runs in about 7 to 10 mins I think (I have a SSD and 16 GB of ram).


On 02 Jul 2014, at 21:43, Scott Marlow <smarlow at redhat.com> wrote:

> On 07/02/2014 02:36 PM, Scott Marlow wrote:
>> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
>>> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X and IntelliJ IDEA so here are a few tidbits:
>>> 
>>> I give Gradle 1GB
>>> 
>>>      export GRADLE_OPTS="-Xmx1024M"
>> 
>> Are you on master or an earlier ORM branch?  I have
>> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
>> takes all available CPU (feels like my ThinkPad is on its knees until
>> the build completes).
> 
> For me, when I run the testsuite on the master branch, my cpu gets pegged at 100% utilization.
> 
>> 
>> 
>>> 
>>> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core subsystem. Basically at least one of the worker hangs for ever.
>>> To work around that I forced Gradle to use one thread
>>> 
>>>      ./gradlew -no-daemon --parallel-threads 1 clean test
>> 
>> Thanks for the tip, I will try this.
> 
> This (-no-daemon --parallel-threads 1) didn't help me.  Eventually, the testsuite will complete but it seems to take a long time (45 minutes or so).  I also tried setting GRADLE_OPTS="-Xmx1024M" but that didn't help.
> 
>> 
>>> 
>>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that is to use `./gradlew idea` and open the project in the IDE. You then have to manually add the generated source directory in a few modules.
>>> Things are explained here: https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
>>> 
>>> Emmanuel
>>> _______________________________________________
>>> 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
>> 
> 



From steve at hibernate.org  Thu Jul  3 13:37:34 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 3 Jul 2014 12:37:34 -0500
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To: <C0F29479-7E36-40C4-B014-629174912F29@hibernate.org>
References: <A9C93719-2B63-4E30-B3DC-65F1F5071BBF@hibernate.org>
	<53B45146.3030507@redhat.com> <53B460DA.9010005@redhat.com>
	<C0F29479-7E36-40C4-B014-629174912F29@hibernate.org>
Message-ID: <CAFdSV9tsfimCCuPmKetX0Yzz=ScL=uKpGcK91VuU-eqbLA5Kjg@mail.gmail.com>

I've mentioned the sheer number of "expected failures" on master now
multiple times on IRC during meetings.  I think that is a large reason for
the time/perf issues running the testsuite on master.  I have also
mentioned the flag that controls this behavior each time.  Have any of
y'all tried that top see if that helps you?


On Thu, Jul 3, 2014 at 11:03 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> For me the test suite would not even complete, it would hang after ~2500
> tests with 0 CPU usage for ever without the --parallel-threads 1 option so
> it?s a matter of life and death for my setup ;)
> With that option, it runs in about 7 to 10 mins I think (I have a SSD and
> 16 GB of ram).
>
>
> On 02 Jul 2014, at 21:43, Scott Marlow <smarlow at redhat.com> wrote:
>
> > On 07/02/2014 02:36 PM, Scott Marlow wrote:
> >> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
> >>> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X
> and IntelliJ IDEA so here are a few tidbits:
> >>>
> >>> I give Gradle 1GB
> >>>
> >>>      export GRADLE_OPTS="-Xmx1024M"
> >>
> >> Are you on master or an earlier ORM branch?  I have
> >> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
> >> takes all available CPU (feels like my ThinkPad is on its knees until
> >> the build completes).
> >
> > For me, when I run the testsuite on the master branch, my cpu gets
> pegged at 100% utilization.
> >
> >>
> >>
> >>>
> >>> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core
> subsystem. Basically at least one of the worker hangs for ever.
> >>> To work around that I forced Gradle to use one thread
> >>>
> >>>      ./gradlew -no-daemon --parallel-threads 1 clean test
> >>
> >> Thanks for the tip, I will try this.
> >
> > This (-no-daemon --parallel-threads 1) didn't help me.  Eventually, the
> testsuite will complete but it seems to take a long time (45 minutes or
> so).  I also tried setting GRADLE_OPTS="-Xmx1024M" but that didn't help.
> >
> >>
> >>>
> >>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both
> to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that
> is to use `./gradlew idea` and open the project in the IDE. You then have
> to manually add the generated source directory in a few modules.
> >>> Things are explained here:
> https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
> >>>
> >>> Emmanuel
> >>> _______________________________________________
> >>> 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
>

From emmanuel at hibernate.org  Mon Jul  7 09:35:20 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 7 Jul 2014 15:35:20 +0200
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To: <CAFdSV9tsfimCCuPmKetX0Yzz=ScL=uKpGcK91VuU-eqbLA5Kjg@mail.gmail.com>
References: <A9C93719-2B63-4E30-B3DC-65F1F5071BBF@hibernate.org>
	<53B45146.3030507@redhat.com> <53B460DA.9010005@redhat.com>
	<C0F29479-7E36-40C4-B014-629174912F29@hibernate.org>
	<CAFdSV9tsfimCCuPmKetX0Yzz=ScL=uKpGcK91VuU-eqbLA5Kjg@mail.gmail.com>
Message-ID: <AD7100B8-2282-414F-B69B-741262A908CA@hibernate.org>

Ah interesting. I do not remember such a discussion but I am not at all meetings. Is there a pointer to one of them?

On 03 Jul 2014, at 19:37, Steve Ebersole <steve at hibernate.org> wrote:

> I've mentioned the sheer number of "expected failures" on master now multiple times on IRC during meetings.  I think that is a large reason for the time/perf issues running the testsuite on master.  I have also mentioned the flag that controls this behavior each time.  Have any of y'all tried that top see if that helps you?
> 
> 
> On Thu, Jul 3, 2014 at 11:03 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> For me the test suite would not even complete, it would hang after ~2500 tests with 0 CPU usage for ever without the --parallel-threads 1 option so it?s a matter of life and death for my setup ;)
> With that option, it runs in about 7 to 10 mins I think (I have a SSD and 16 GB of ram).
> 
> 
> On 02 Jul 2014, at 21:43, Scott Marlow <smarlow at redhat.com> wrote:
> 
> > On 07/02/2014 02:36 PM, Scott Marlow wrote:
> >> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
> >>> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X and IntelliJ IDEA so here are a few tidbits:
> >>>
> >>> I give Gradle 1GB
> >>>
> >>>      export GRADLE_OPTS="-Xmx1024M"
> >>
> >> Are you on master or an earlier ORM branch?  I have
> >> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
> >> takes all available CPU (feels like my ThinkPad is on its knees until
> >> the build completes).
> >
> > For me, when I run the testsuite on the master branch, my cpu gets pegged at 100% utilization.
> >
> >>
> >>
> >>>
> >>> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core subsystem. Basically at least one of the worker hangs for ever.
> >>> To work around that I forced Gradle to use one thread
> >>>
> >>>      ./gradlew -no-daemon --parallel-threads 1 clean test
> >>
> >> Thanks for the tip, I will try this.
> >
> > This (-no-daemon --parallel-threads 1) didn't help me.  Eventually, the testsuite will complete but it seems to take a long time (45 minutes or so).  I also tried setting GRADLE_OPTS="-Xmx1024M" but that didn't help.
> >
> >>
> >>>
> >>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that is to use `./gradlew idea` and open the project in the IDE. You then have to manually add the generated source directory in a few modules.
> >>> Things are explained here: https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
> >>>
> >>> Emmanuel
> >>> _______________________________________________
> >>> 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
> 


From etienne.miret at ens-lyon.org  Mon Jul  7 14:29:03 2014
From: etienne.miret at ens-lyon.org (Etienne Miret)
Date: Mon, 7 Jul 2014 20:29:03 +0200
Subject: [hibernate-dev] Gradle not running some unit tests
Message-ID: <ED0E8831-7E8E-4A69-9C93-611E0A03777F@ens-lyon.org>

Hello all,

Willing to investigate some Hibernate bugs, I downloaded the sources (from github), compiled them and ran unit tests. I used the provided Gradle wrapper to compile and run the tests. However, hibernate-core/target/reports/tests/index.html reports a number of test classes as not containing any tests. I mainly looked at org.hibernate.test.cut.CompositeUserTypeTest, and I can tell that:
 * it contains two method annotated with @org.junit.Test
 * it extends org.hibernate.testing.junit4.BaseUnitTestCase
   (through BaseCoreFunctionalTestCase), which has a
   @org.junit.runner.RunWith annotation.
>From what I know of Gradle, this is enough to have the tests detected and ran. And actually, those tests *are* detected and ran on branch 4.2. But on branch master, this test class appears in the report with 0 tests within.

Does anyone know why those tests are missing from the report?

In case this is of any help, here is the output of ./gradle --version:

------------------------------------------------------------
Gradle 1.9
------------------------------------------------------------

Build time:   2013-11-19 08:20:02 UTC
Build number: none
Revision:     7970ec3503b4f5767ee1c1c69f8b4186c4763e3d

Groovy:       1.8.6
Ant:          Apache Ant(TM) version 1.9.2 compiled on July 8 2013
Ivy:          2.2.0
JVM:          1.7.0_60 (Oracle Corporation 24.60-b09)
OS:           Mac OS X 10.9.4 x86_64

Regards,

-- 
Etienne Miret



From brmeyer at redhat.com  Mon Jul  7 17:36:18 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Mon, 7 Jul 2014 17:36:18 -0400 (EDT)
Subject: [hibernate-dev] Hibernate ORM/Validator included in Apache Karaf by
	default
In-Reply-To: <1025273615.5253692.1404768513039.JavaMail.zimbra@redhat.com>
Message-ID: <907685510.5261202.1404768978850.JavaMail.zimbra@redhat.com>

FYI, I just learned that the Apache Karaf team has included Hibernate ORM and Hibernate Validator as default system features, starting with Karaf 2.4.x, 2.3.4+, and 3.0.x.  I'd call that a big vote of confidence for Hibernate OSGi.  So, thanks to everyone who helped make that a reality!

https://issues.apache.org/jira/browse/KARAF-2666
https://issues.apache.org/jira/browse/KARAF-2746
https://issues.apache.org/jira/browse/KARAF-2751

From sanne at hibernate.org  Mon Jul  7 18:21:36 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 7 Jul 2014 23:21:36 +0100
Subject: [hibernate-dev] Hibernate ORM/Validator included in Apache
 Karaf by default
In-Reply-To: <907685510.5261202.1404768978850.JavaMail.zimbra@redhat.com>
References: <1025273615.5253692.1404768513039.JavaMail.zimbra@redhat.com>
	<907685510.5261202.1404768978850.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO050wuY+LGQ6xqXkiLBozxaug36uN91eRrVYY-6qfJdCA@mail.gmail.com>

Congratulations!
Now let's fix the missing projects :-)


On 7 July 2014 22:36, Brett Meyer <brmeyer at redhat.com> wrote:
> FYI, I just learned that the Apache Karaf team has included Hibernate ORM and Hibernate Validator as default system features, starting with Karaf 2.4.x, 2.3.4+, and 3.0.x.  I'd call that a big vote of confidence for Hibernate OSGi.  So, thanks to everyone who helped make that a reality!
>
> https://issues.apache.org/jira/browse/KARAF-2666
> https://issues.apache.org/jira/browse/KARAF-2746
> https://issues.apache.org/jira/browse/KARAF-2751
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Mon Jul  7 19:21:00 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 8 Jul 2014 00:21:00 +0100
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
Message-ID: <CAFm4XO0knssmVFEhfkO3_DkrN0OPuBJ2O7pnkxVVhAkkok7Qcw@mail.gmail.com>

Hi all,
I'm looking forward to a release of Hibernate ORM 4.3, especially
after my fix for Service loading under OSGi gets integrated (HHH-9258
is slowing down progress on Search).

I see it has been a long while since 4.3.5.Final.
Assuming that gets integrated quickly, could we also plan for a release please?

Cheers,
Sanne

From sanne at hibernate.org  Tue Jul  8 06:49:53 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 8 Jul 2014 11:49:53 +0100
Subject: [hibernate-dev] SearchFactory API exposes Class type for entity
Message-ID: <CAFm4XO2EiN6OhTyveHY-Q7vES-UfN2CcLbqX5jYWJeLZmc1tfQ@mail.gmail.com>

When I started refactoring the Search code towards free-form I simply
started to remove all references to Class and replace them with
TypeIdentifier, essentially working only on hibernate-search-engine
and closing the ORM integration modules which don't need to be
affected.

The SearchFactory interface however is meant as public API and exposes
Class in its signatures to identify specific entity types (I'll use
"entity" in its conceptual meaning): for example we have

    void optimize(Class entityType);

Since not only Hibernate Search / ORM will be using Class &
annotations, I could split out the SearchFactory and its default
"class to index mapping" strategies into a separate module, or I could
just keep it there: public API but ignored in case of different
integrations?

I think I'll leave it there for now, but early comments are welcome.

Sanne

From steve at hibernate.org  Tue Jul  8 10:50:01 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 8 Jul 2014 09:50:01 -0500
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To: <CAFm4XO0knssmVFEhfkO3_DkrN0OPuBJ2O7pnkxVVhAkkok7Qcw@mail.gmail.com>
References: <CAFm4XO0knssmVFEhfkO3_DkrN0OPuBJ2O7pnkxVVhAkkok7Qcw@mail.gmail.com>
Message-ID: <CAFdSV9ud3hShQSt0uSdp9raA9aS3XfMsLeKe-oA+M2PkAqXUVA@mail.gmail.com>

Gail was going to work on this.  IIRC she was waiting to finish the merge
work she was doing.  Gail?


On Mon, Jul 7, 2014 at 6:21 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi all,
> I'm looking forward to a release of Hibernate ORM 4.3, especially
> after my fix for Service loading under OSGi gets integrated (HHH-9258
> is slowing down progress on Search).
>
> I see it has been a long while since 4.3.5.Final.
> Assuming that gets integrated quickly, could we also plan for a release
> please?
>
> Cheers,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jul  8 11:52:51 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 8 Jul 2014 10:52:51 -0500
Subject: [hibernate-dev] IRC Developer Meeting - 7/8
Message-ID: <CAFdSV9vKU3bJpo4jjr7bUVBQX3nfPxUqGv=q5NUB7ODWrVu2HQ@mail.gmail.com>

Mostly more design discussion of JdbcSession

[10:49] <jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-08-14.42.html
[10:49] <jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-08-14.42.txt
[10:49] <jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-08-14.42.log.html

From gbadner at redhat.com  Tue Jul  8 15:53:11 2014
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 8 Jul 2014 15:53:11 -0400 (EDT)
Subject: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading
	problem
Message-ID: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>

HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads having a different ContextClassLoader (CCL) than their caller. As a result, SerializableBlobProxy.generateProxy() throws IllegalArgumentException because WrappedBlob is not found. The same happens for SerializableClobProxy.generateProxy() because WrappedClob is not found.

IIUC, this will be fixed by accessing the ClassLoaderService in Hibernate 5.

I'm looking for either a fix or workaround for this in Hibernate 4.2.x and 4.3.x.

A) A possible fix for HHH-8310 suggests using the ClassLoader returned by WrappedBlob.class.getClassLoader(). Could this somehow get an unintended ClassLoader? 

B) A workaround is for the caller to initialize ClassLoaderHelper.overridenClassLoader before calling Spring.

Which would be more appropriate?

Thanks,
Gail

[1] https://hibernate.atlassian.net/browse/HHH-8310
[2] https://jira.spring.io/browse/SPR-11125

From sanne at hibernate.org  Tue Jul  8 16:20:30 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 8 Jul 2014 21:20:30 +0100
Subject: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading
	problem
In-Reply-To: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
References: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO27uxC2N4y1LYuiYyn6pDQVoG_1JU-YQaD--XUwT4UVfg@mail.gmail.com>

On 8 July 2014 20:53, Gail Badner <gbadner at redhat.com> wrote:
> HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads having a different ContextClassLoader (CCL) than their caller. As a result, SerializableBlobProxy.generateProxy() throws IllegalArgumentException because WrappedBlob is not found. The same happens for SerializableClobProxy.generateProxy() because WrappedClob is not found.
>
> IIUC, this will be fixed by accessing the ClassLoaderService in Hibernate 5.
>
> I'm looking for either a fix or workaround for this in Hibernate 4.2.x and 4.3.x.
>
> A) A possible fix for HHH-8310 suggests using the ClassLoader returned by WrappedBlob.class.getClassLoader(). Could this somehow get an unintended ClassLoader?

I'd use this approach, you could only get an unintended ClassLoader if
there are duplicates exposed on the same classpath, but in such a case
nothing would work correctly anyway.

Sanne

>
> B) A workaround is for the caller to initialize ClassLoaderHelper.overridenClassLoader before calling Spring.
>
> Which would be more appropriate?
>
> Thanks,
> Gail
>
> [1] https://hibernate.atlassian.net/browse/HHH-8310
> [2] https://jira.spring.io/browse/SPR-11125
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From smarlow at redhat.com  Tue Jul  8 17:04:34 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 08 Jul 2014 17:04:34 -0400
Subject: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading
 problem
In-Reply-To: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
References: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
Message-ID: <53BC5CE2.6040904@redhat.com>

This sounds similar to https://community.jboss.org/message/879546

On 07/08/2014 03:53 PM, Gail Badner wrote:
> HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads having a different ContextClassLoader (CCL) than their caller. As a result, SerializableBlobProxy.generateProxy() throws IllegalArgumentException because WrappedBlob is not found. The same happens for SerializableClobProxy.generateProxy() because WrappedClob is not found.
>
> IIUC, this will be fixed by accessing the ClassLoaderService in Hibernate 5.
>
> I'm looking for either a fix or workaround for this in Hibernate 4.2.x and 4.3.x.
>
> A) A possible fix for HHH-8310 suggests using the ClassLoader returned by WrappedBlob.class.getClassLoader(). Could this somehow get an unintended ClassLoader?
>
> B) A workaround is for the caller to initialize ClassLoaderHelper.overridenClassLoader before calling Spring.
>
> Which would be more appropriate?
>
> Thanks,
> Gail
>
> [1] https://hibernate.atlassian.net/browse/HHH-8310
> [2] https://jira.spring.io/browse/SPR-11125
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From smarlow at redhat.com  Tue Jul  8 17:19:50 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 08 Jul 2014 17:19:50 -0400
Subject: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading
 problem
In-Reply-To: <53BC5CE2.6040904@redhat.com>
References: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
	<53BC5CE2.6040904@redhat.com>
Message-ID: <53BC6076.2010305@redhat.com>

On 07/08/2014 05:04 PM, Scott Marlow wrote:
> This sounds similar to https://community.jboss.org/message/879546

I was hoping to hear more feedback from the above link but didn't.  I 
suspect that its a classloader issue with ear sub-deployments having 
Hibernate on their classpath but not the ear top level classloader.


>
> On 07/08/2014 03:53 PM, Gail Badner wrote:
>> HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads having a different ContextClassLoader (CCL) than their caller. As a result, SerializableBlobProxy.generateProxy() throws IllegalArgumentException because WrappedBlob is not found. The same happens for SerializableClobProxy.generateProxy() because WrappedClob is not found.
>>
>> IIUC, this will be fixed by accessing the ClassLoaderService in Hibernate 5.
>>
>> I'm looking for either a fix or workaround for this in Hibernate 4.2.x and 4.3.x.
>>
>> A) A possible fix for HHH-8310 suggests using the ClassLoader returned by WrappedBlob.class.getClassLoader(). Could this somehow get an unintended ClassLoader?

Good question but this change might impact HHH-8010.  Might be good to 
check with Brett on why OSGi needs to use an alternative classloader 
(which is set in ClassLoaderHelper).

>>
>> B) A workaround is for the caller to initialize ClassLoaderHelper.overridenClassLoader before calling Spring.

I don't think this will work in a multiple deployment environment (e.g. 
WildFly) unless ClassLoaderHelper defaulted to the ORM classloader 
instead of an application level classloader.

>>
>> Which would be more appropriate?
>>
>> Thanks,
>> Gail
>>
>> [1] https://hibernate.atlassian.net/browse/HHH-8310
>> [2] https://jira.spring.io/browse/SPR-11125
>> _______________________________________________
>> 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
>


From gbadner at redhat.com  Tue Jul  8 17:40:00 2014
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 8 Jul 2014 17:40:00 -0400 (EDT)
Subject: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading
 problem
In-Reply-To: <53BC6076.2010305@redhat.com>
References: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
	<53BC5CE2.6040904@redhat.com> <53BC6076.2010305@redhat.com>
Message-ID: <892665831.8371949.1404855600334.JavaMail.zimbra@redhat.com>

Hi Scott,

I believe the classloading problem you mention is the same. Both BlobProxy.getProxyClassLoader() and SerializableBlobProxy.getProxyClassLoader() return ClassLoaderHelper.getContextClassLoader() if non-null.

Gail

----- Original Message -----
> From: "Scott Marlow" <smarlow at redhat.com>
> To: "Gail Badner" <gbadner at redhat.com>, "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Tuesday, July 8, 2014 2:19:50 PM
> Subject: Re: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading problem
> 
> On 07/08/2014 05:04 PM, Scott Marlow wrote:
> > This sounds similar to https://community.jboss.org/message/879546
> 
> I was hoping to hear more feedback from the above link but didn't.  I
> suspect that its a classloader issue with ear sub-deployments having
> Hibernate on their classpath but not the ear top level classloader.
> 
> 
> >
> > On 07/08/2014 03:53 PM, Gail Badner wrote:
> >> HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads
> >> having a different ContextClassLoader (CCL) than their caller. As a
> >> result, SerializableBlobProxy.generateProxy() throws
> >> IllegalArgumentException because WrappedBlob is not found. The same
> >> happens for SerializableClobProxy.generateProxy() because WrappedClob is
> >> not found.
> >>
> >> IIUC, this will be fixed by accessing the ClassLoaderService in Hibernate
> >> 5.
> >>
> >> I'm looking for either a fix or workaround for this in Hibernate 4.2.x and
> >> 4.3.x.
> >>
> >> A) A possible fix for HHH-8310 suggests using the ClassLoader returned by
> >> WrappedBlob.class.getClassLoader(). Could this somehow get an unintended
> >> ClassLoader?
> 
> Good question but this change might impact HHH-8010.  Might be good to
> check with Brett on why OSGi needs to use an alternative classloader
> (which is set in ClassLoaderHelper).
> 
> >>
> >> B) A workaround is for the caller to initialize
> >> ClassLoaderHelper.overridenClassLoader before calling Spring.
> 
> I don't think this will work in a multiple deployment environment (e.g.
> WildFly) unless ClassLoaderHelper defaulted to the ORM classloader
> instead of an application level classloader.
> 
> >>
> >> Which would be more appropriate?
> >>
> >> Thanks,
> >> Gail
> >>
> >> [1] https://hibernate.atlassian.net/browse/HHH-8310
> >> [2] https://jira.spring.io/browse/SPR-11125
> >> _______________________________________________
> >> 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
> >
> 
> 

From gbadner at redhat.com  Tue Jul  8 22:39:21 2014
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 8 Jul 2014 22:39:21 -0400 (EDT)
Subject: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading
 problem
In-Reply-To: <892665831.8371949.1404855600334.JavaMail.zimbra@redhat.com>
References: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
	<53BC5CE2.6040904@redhat.com> <53BC6076.2010305@redhat.com>
	<892665831.8371949.1404855600334.JavaMail.zimbra@redhat.com>
Message-ID: <982605977.8616050.1404873561795.JavaMail.zimbra@redhat.com>

I heard back from Steve and he agrees that getting the ClassLoader from WrappedBlob.class.getClassLoader() should be fine.

To answer Scott: IIUC, HHH-8010 has to do with using a specified OsgiClassLoader to build a SessionFactory or EntityManagerFactory. Most usages of ClassLoaderHelper.getContextClassLoader() are in fact involved in building the SessionFactory or EntityManagerFactory. 

AFAICT, SerializableBlobProxy and SerializableClobProxy are not involved in the process of building a SessionFactory or EntityManagerFactory, so making the suggested change to generate proxies shouldn't impact HHH-8010.

After Scott mentioned the message discussing this same problem with BlobProxy, I found that ClobProxy, NClobProxy, and ResultSetWrapperProxy also prefer ClassLoaderHelper.getContextClassLoader(). I'll make a similar change to their getProxyClassLoader() methods (using the appropriate interface). I've replied to the thread.

I also noticed that ReflectHelper and SerializationHelper use ClassLoaderHelper.getContextClassLoader() and I am guessing there are some uses of these classes that would be susceptible to the same Spring bug. I'm not going to deal with these now though.

Thanks all for the feedback! :)
Gail

----- Original Message -----
> From: "Gail Badner" <gbadner at redhat.com>
> To: "Scott Marlow" <smarlow at redhat.com>
> Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Tuesday, July 8, 2014 2:40:00 PM
> Subject: Re: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading problem
> 
> Hi Scott,
> 
> I believe the classloading problem you mention is the same. Both
> BlobProxy.getProxyClassLoader() and
> SerializableBlobProxy.getProxyClassLoader() return
> ClassLoaderHelper.getContextClassLoader() if non-null.
> 
> Gail
> 
> ----- Original Message -----
> > From: "Scott Marlow" <smarlow at redhat.com>
> > To: "Gail Badner" <gbadner at redhat.com>, "hibernate-dev"
> > <hibernate-dev at lists.jboss.org>
> > Sent: Tuesday, July 8, 2014 2:19:50 PM
> > Subject: Re: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob
> > classloading problem
> > 
> > On 07/08/2014 05:04 PM, Scott Marlow wrote:
> > > This sounds similar to https://community.jboss.org/message/879546
> > 
> > I was hoping to hear more feedback from the above link but didn't.  I
> > suspect that its a classloader issue with ear sub-deployments having
> > Hibernate on their classpath but not the ear top level classloader.
> > 
> > 
> > >
> > > On 07/08/2014 03:53 PM, Gail Badner wrote:
> > >> HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads
> > >> having a different ContextClassLoader (CCL) than their caller. As a
> > >> result, SerializableBlobProxy.generateProxy() throws
> > >> IllegalArgumentException because WrappedBlob is not found. The same
> > >> happens for SerializableClobProxy.generateProxy() because WrappedClob is
> > >> not found.
> > >>
> > >> IIUC, this will be fixed by accessing the ClassLoaderService in
> > >> Hibernate
> > >> 5.
> > >>
> > >> I'm looking for either a fix or workaround for this in Hibernate 4.2.x
> > >> and
> > >> 4.3.x.
> > >>
> > >> A) A possible fix for HHH-8310 suggests using the ClassLoader returned
> > >> by
> > >> WrappedBlob.class.getClassLoader(). Could this somehow get an unintended
> > >> ClassLoader?
> > 
> > Good question but this change might impact HHH-8010.  Might be good to
> > check with Brett on why OSGi needs to use an alternative classloader
> > (which is set in ClassLoaderHelper).
> > 
> > >>
> > >> B) A workaround is for the caller to initialize
> > >> ClassLoaderHelper.overridenClassLoader before calling Spring.
> > 
> > I don't think this will work in a multiple deployment environment (e.g.
> > WildFly) unless ClassLoaderHelper defaulted to the ORM classloader
> > instead of an application level classloader.
> > 
> > >>
> > >> Which would be more appropriate?
> > >>
> > >> Thanks,
> > >> Gail
> > >>
> > >> [1] https://hibernate.atlassian.net/browse/HHH-8310
> > >> [2] https://jira.spring.io/browse/SPR-11125
> > >> _______________________________________________
> > >> 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
> > >
> > 
> > 
> 

From gunnar at hibernate.org  Wed Jul  9 06:17:40 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 9 Jul 2014 12:17:40 +0200
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To: <CAFdSV9ud3hShQSt0uSdp9raA9aS3XfMsLeKe-oA+M2PkAqXUVA@mail.gmail.com>
References: <CAFm4XO0knssmVFEhfkO3_DkrN0OPuBJ2O7pnkxVVhAkkok7Qcw@mail.gmail.com>
	<CAFdSV9ud3hShQSt0uSdp9raA9aS3XfMsLeKe-oA+M2PkAqXUVA@mail.gmail.com>
Message-ID: <CADGJaX-k7n5wscu_PNCsM+jVnQ8bhrFi5Pt1L3ebxtARTOpQ_A@mail.gmail.com>

Will this contain the recent improvements for the extra state in
EntityEntry? We need this in OGM to move forward with more intelligent
querying of embedded data for document stores but also for Neo4j.

Thanks,

--Gunnar




2014-07-08 16:50 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Gail was going to work on this.  IIRC she was waiting to finish the merge
> work she was doing.  Gail?
>
>
> On Mon, Jul 7, 2014 at 6:21 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > Hi all,
> > I'm looking forward to a release of Hibernate ORM 4.3, especially
> > after my fix for Service loading under OSGi gets integrated (HHH-9258
> > is slowing down progress on Search).
> >
> > I see it has been a long while since 4.3.5.Final.
> > Assuming that gets integrated quickly, could we also plan for a release
> > please?
> >
> > Cheers,
> > Sanne
> > _______________________________________________
> > 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
>

From sanne at hibernate.org  Wed Jul  9 07:14:51 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 9 Jul 2014 12:14:51 +0100
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To: <CADGJaX-k7n5wscu_PNCsM+jVnQ8bhrFi5Pt1L3ebxtARTOpQ_A@mail.gmail.com>
References: <CAFm4XO0knssmVFEhfkO3_DkrN0OPuBJ2O7pnkxVVhAkkok7Qcw@mail.gmail.com>
	<CAFdSV9ud3hShQSt0uSdp9raA9aS3XfMsLeKe-oA+M2PkAqXUVA@mail.gmail.com>
	<CADGJaX-k7n5wscu_PNCsM+jVnQ8bhrFi5Pt1L3ebxtARTOpQ_A@mail.gmail.com>
Message-ID: <CAFm4XO3D59oEJrcA5fUppiwB3UQoZrfsXGQg4VhTzbR99_iNbA@mail.gmail.com>

Hi Gunnar,
it's still unclear what effect it's having on the performance of
Hibernate ORM version 4.2-latest, so I had a chat with John and we
agreed that we can treat it optimistically as it's very likely to just
have caused a different effect on some other code area.

So, assuming it's not too late for version 4.3.6, could you push it to
4.3 *only* ?

We can then later decide to backport to 4.2 or not based on more
information, but as you say we need it for OGM anyway so let's push it
to 4.3 and move on.

--Sanne

On 9 July 2014 11:17, Gunnar Morling <gunnar at hibernate.org> wrote:
> Will this contain the recent improvements for the extra state in
> EntityEntry? We need this in OGM to move forward with more intelligent
> querying of embedded data for document stores but also for Neo4j.
>
> Thanks,
>
> --Gunnar
>
>
>
>
> 2014-07-08 16:50 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> Gail was going to work on this.  IIRC she was waiting to finish the merge
>> work she was doing.  Gail?
>>
>>
>> On Mon, Jul 7, 2014 at 6:21 PM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > Hi all,
>> > I'm looking forward to a release of Hibernate ORM 4.3, especially
>> > after my fix for Service loading under OSGi gets integrated (HHH-9258
>> > is slowing down progress on Search).
>> >
>> > I see it has been a long while since 4.3.5.Final.
>> > Assuming that gets integrated quickly, could we also plan for a release
>> > please?
>> >
>> > Cheers,
>> > Sanne
>> > _______________________________________________
>> > 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
>
>

From emmanuel at hibernate.org  Wed Jul  9 07:24:24 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 9 Jul 2014 13:24:24 +0200
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To: <CAFm4XO3D59oEJrcA5fUppiwB3UQoZrfsXGQg4VhTzbR99_iNbA@mail.gmail.com>
References: <CAFm4XO0knssmVFEhfkO3_DkrN0OPuBJ2O7pnkxVVhAkkok7Qcw@mail.gmail.com>
	<CAFdSV9ud3hShQSt0uSdp9raA9aS3XfMsLeKe-oA+M2PkAqXUVA@mail.gmail.com>
	<CADGJaX-k7n5wscu_PNCsM+jVnQ8bhrFi5Pt1L3ebxtARTOpQ_A@mail.gmail.com>
	<CAFm4XO3D59oEJrcA5fUppiwB3UQoZrfsXGQg4VhTzbR99_iNbA@mail.gmail.com>
Message-ID: <AF693BDE-7985-4D02-91EE-5E1D9C371FFD@hibernate.org>

We need to address some of Gunnar?s comments on the master PR. He proposed some renaming for example. Gunnar, do you want to take the lead?

On 09 Jul 2014, at 13:14, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Gunnar,
> it's still unclear what effect it's having on the performance of
> Hibernate ORM version 4.2-latest, so I had a chat with John and we
> agreed that we can treat it optimistically as it's very likely to just
> have caused a different effect on some other code area.
> 
> So, assuming it's not too late for version 4.3.6, could you push it to
> 4.3 *only* ?
> 
> We can then later decide to backport to 4.2 or not based on more
> information, but as you say we need it for OGM anyway so let's push it
> to 4.3 and move on.
> 
> --Sanne
> 
> On 9 July 2014 11:17, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Will this contain the recent improvements for the extra state in
>> EntityEntry? We need this in OGM to move forward with more intelligent
>> querying of embedded data for document stores but also for Neo4j.
>> 
>> Thanks,
>> 
>> --Gunnar
>> 
>> 
>> 
>> 
>> 2014-07-08 16:50 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> 
>>> Gail was going to work on this.  IIRC she was waiting to finish the merge
>>> work she was doing.  Gail?
>>> 
>>> 
>>> On Mon, Jul 7, 2014 at 6:21 PM, Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>> 
>>>> Hi all,
>>>> I'm looking forward to a release of Hibernate ORM 4.3, especially
>>>> after my fix for Service loading under OSGi gets integrated (HHH-9258
>>>> is slowing down progress on Search).
>>>> 
>>>> I see it has been a long while since 4.3.5.Final.
>>>> Assuming that gets integrated quickly, could we also plan for a release
>>>> please?
>>>> 
>>>> Cheers,
>>>> Sanne
>>>> _______________________________________________
>>>> 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



From gunnar at hibernate.org  Wed Jul  9 08:38:36 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 9 Jul 2014 14:38:36 +0200
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To: <AF693BDE-7985-4D02-91EE-5E1D9C371FFD@hibernate.org>
References: <CAFm4XO0knssmVFEhfkO3_DkrN0OPuBJ2O7pnkxVVhAkkok7Qcw@mail.gmail.com>
	<CAFdSV9ud3hShQSt0uSdp9raA9aS3XfMsLeKe-oA+M2PkAqXUVA@mail.gmail.com>
	<CADGJaX-k7n5wscu_PNCsM+jVnQ8bhrFi5Pt1L3ebxtARTOpQ_A@mail.gmail.com>
	<CAFm4XO3D59oEJrcA5fUppiwB3UQoZrfsXGQg4VhTzbR99_iNbA@mail.gmail.com>
	<AF693BDE-7985-4D02-91EE-5E1D9C371FFD@hibernate.org>
Message-ID: <CADGJaX-Dau389ZPA-gBVm7hKqKj8A5uSHem+e=_0YFt4wvjKpw@mail.gmail.com>

2014-07-09 13:24 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> We need to address some of Gunnar?s comments on the master PR. He proposed
> some renaming for example. Gunnar, do you want to take the lead?
>

Yes, I can do the merge to 4.3.

I don't have strong feelings on the renaming, but I'm a bit concerned about
the de-serialization issue. Do we for now just assume that all potential EE
implementations use the same persistent representation? Then always
de-serializing into DefaultEntityEntry as it's currently happening should
be ok.

On 09 Jul 2014, at 13:14, Sanne Grinovero <sanne at hibernate.org> wrote:
>
> > Hi Gunnar,
> > it's still unclear what effect it's having on the performance of
> > Hibernate ORM version 4.2-latest, so I had a chat with John and we
> > agreed that we can treat it optimistically as it's very likely to just
> > have caused a different effect on some other code area.
> >
> > So, assuming it's not too late for version 4.3.6, could you push it to
> > 4.3 *only* ?
> >
> > We can then later decide to backport to 4.2 or not based on more
> > information, but as you say we need it for OGM anyway so let's push it
> > to 4.3 and move on.
> >
> > --Sanne
> >
> > On 9 July 2014 11:17, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> Will this contain the recent improvements for the extra state in
> >> EntityEntry? We need this in OGM to move forward with more intelligent
> >> querying of embedded data for document stores but also for Neo4j.
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >>
> >>
> >>
> >>
> >> 2014-07-08 16:50 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >>
> >>> Gail was going to work on this.  IIRC she was waiting to finish the
> merge
> >>> work she was doing.  Gail?
> >>>
> >>>
> >>> On Mon, Jul 7, 2014 at 6:21 PM, Sanne Grinovero <sanne at hibernate.org>
> >>> wrote:
> >>>
> >>>> Hi all,
> >>>> I'm looking forward to a release of Hibernate ORM 4.3, especially
> >>>> after my fix for Service loading under OSGi gets integrated (HHH-9258
> >>>> is slowing down progress on Search).
> >>>>
> >>>> I see it has been a long while since 4.3.5.Final.
> >>>> Assuming that gets integrated quickly, could we also plan for a
> release
> >>>> please?
> >>>>
> >>>> Cheers,
> >>>> Sanne
> >>>> _______________________________________________
> >>>> 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
>
>

From gunnar at hibernate.org  Wed Jul  9 09:32:53 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 9 Jul 2014 15:32:53 +0200
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To: <53B47871.5000102@redhat.com>
References: <A9C93719-2B63-4E30-B3DC-65F1F5071BBF@hibernate.org>
	<53B45146.3030507@redhat.com> <53B460DA.9010005@redhat.com>
	<53B47871.5000102@redhat.com>
Message-ID: <CADGJaX-h0fxAkv_-iYC0iFgVZ+jtuYfDP47E3rCXeo4S=U6qNA@mail.gmail.com>

2014-07-02 23:24 GMT+02:00 Scott Marlow <smarlow at redhat.com>:

> I removed GRADLE_OPTS and ran again with "-no-daemon --parallel-threads
> 1" and my laptop still pegged the cpu at 100% but seemed a little more
> responsive.  From running TOP, I could see that six or seven separate
> Java processes are running (if each one is taking up to 1gig of memory
> on my 8 gig laptop, that could explain why I'm seeing thrashing).
>

Did you ever find a way for running the build? My machine basically becomes
nearly unusable due to extremely high CPU usage once I start the build on
master :(

Steve, any pointer on the options/flags recommended to build ORM on master
would be much appreciated. Thanks!

--Gunnar


>
> On 07/02/2014 03:43 PM, Scott Marlow wrote:
> > On 07/02/2014 02:36 PM, Scott Marlow wrote:
> >> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
> >>> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X
> and IntelliJ IDEA so here are a few tidbits:
> >>>
> >>> I give Gradle 1GB
> >>>
> >>>        export GRADLE_OPTS="-Xmx1024M"
> >>
> >> Are you on master or an earlier ORM branch?  I have
> >> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
> >> takes all available CPU (feels like my ThinkPad is on its knees until
> >> the build completes).
> >
> > For me, when I run the testsuite on the master branch, my cpu gets
> > pegged at 100% utilization.
> >
> >>
> >>
> >>>
> >>> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core
> subsystem. Basically at least one of the worker hangs for ever.
> >>> To work around that I forced Gradle to use one thread
> >>>
> >>>        ./gradlew -no-daemon --parallel-threads 1 clean test
> >>
> >> Thanks for the tip, I will try this.
> >
> > This (-no-daemon --parallel-threads 1) didn't help me.  Eventually, the
> > testsuite will complete but it seems to take a long time (45 minutes or
> > so).  I also tried setting GRADLE_OPTS="-Xmx1024M" but that didn't help.
> >
> >>
> >>>
> >>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both
> to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that
> is to use `./gradlew idea` and open the project in the IDE. You then have
> to manually add the generated source directory in a few modules.
> >>> Things are explained here:
> https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
> >>>
> >>> Emmanuel
> >>> _______________________________________________
> >>> 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
>

From emmanuel at hibernate.org  Wed Jul  9 12:07:16 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 9 Jul 2014 18:07:16 +0200
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To: <CADGJaX-Dau389ZPA-gBVm7hKqKj8A5uSHem+e=_0YFt4wvjKpw@mail.gmail.com>
References: <CAFm4XO0knssmVFEhfkO3_DkrN0OPuBJ2O7pnkxVVhAkkok7Qcw@mail.gmail.com>
	<CAFdSV9ud3hShQSt0uSdp9raA9aS3XfMsLeKe-oA+M2PkAqXUVA@mail.gmail.com>
	<CADGJaX-k7n5wscu_PNCsM+jVnQ8bhrFi5Pt1L3ebxtARTOpQ_A@mail.gmail.com>
	<CAFm4XO3D59oEJrcA5fUppiwB3UQoZrfsXGQg4VhTzbR99_iNbA@mail.gmail.com>
	<AF693BDE-7985-4D02-91EE-5E1D9C371FFD@hibernate.org>
	<CADGJaX-Dau389ZPA-gBVm7hKqKj8A5uSHem+e=_0YFt4wvjKpw@mail.gmail.com>
Message-ID: <CAA82DC4-6FBB-49A9-8534-EB608D3F9B0B@hibernate.org>


On 09 Jul 2014, at 14:38, Gunnar Morling <gunnar at hibernate.org> wrote:

> 2014-07-09 13:24 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> We need to address some of Gunnar?s comments on the master PR. He proposed some renaming for example. Gunnar, do you want to take the lead?
> 
> Yes, I can do the merge to 4.3.
> 
> I don't have strong feelings on the renaming, but I'm a bit concerned about the de-serialization issue. Do we for now just assume that all potential EE implementations use the same persistent representation? Then always de-serializing into DefaultEntityEntry as it's currently happening should be ok.

That has my preference. But we should find a way to make it more explicit.


From smarlow at redhat.com  Wed Jul  9 14:09:27 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 09 Jul 2014 14:09:27 -0400
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To: <CADGJaX-h0fxAkv_-iYC0iFgVZ+jtuYfDP47E3rCXeo4S=U6qNA@mail.gmail.com>
References: <A9C93719-2B63-4E30-B3DC-65F1F5071BBF@hibernate.org>	<53B45146.3030507@redhat.com>	<53B460DA.9010005@redhat.com>	<53B47871.5000102@redhat.com>
	<CADGJaX-h0fxAkv_-iYC0iFgVZ+jtuYfDP47E3rCXeo4S=U6qNA@mail.gmail.com>
Message-ID: <53BD8557.7000608@redhat.com>

On 07/09/2014 09:32 AM, Gunnar Morling wrote:
> 2014-07-02 23:24 GMT+02:00 Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>>:
>
>     I removed GRADLE_OPTS and ran again with "-no-daemon --parallel-threads
>     1" and my laptop still pegged the cpu at 100% but seemed a little more
>     responsive.  From running TOP, I could see that six or seven separate
>     Java processes are running (if each one is taking up to 1gig of memory
>     on my 8 gig laptop, that could explain why I'm seeing thrashing).
>
>
> Did you ever find a way for running the build? My machine basically
> becomes nearly unusable due to extremely high CPU usage once I start the
> build on master :(

I found some relief from setting "export GRADLE_OPTS=".  My CPU still 
reaches near 100% but my KDE UI seems more responsive.

>
> Steve, any pointer on the options/flags recommended to build ORM on
> master would be much appreciated. Thanks!
>
> --Gunnar
>
>
>     On 07/02/2014 03:43 PM, Scott Marlow wrote:
>      > On 07/02/2014 02:36 PM, Scott Marlow wrote:
>      >> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
>      >>> I had a lot of hurdles to make Hibernate ORM run and build on
>     Mac OS X and IntelliJ IDEA so here are a few tidbits:
>      >>>
>      >>> I give Gradle 1GB
>      >>>
>      >>>        export GRADLE_OPTS="-Xmx1024M"
>      >>
>      >> Are you on master or an earlier ORM branch?  I have
>      >> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
>      >> takes all available CPU (feels like my ThinkPad is on its knees
>     until
>      >> the build completes).
>      >
>      > For me, when I run the testsuite on the master branch, my cpu gets
>      > pegged at 100% utilization.
>      >
>      >>
>      >>
>      >>>
>      >>> Gradle hangs on me after ~ 2300 to 2400 tests for
>     hibernate-core subsystem. Basically at least one of the worker hangs
>     for ever.
>      >>> To work around that I forced Gradle to use one thread
>      >>>
>      >>>        ./gradlew -no-daemon --parallel-threads 1 clean test
>      >>
>      >> Thanks for the tip, I will try this.
>      >
>      > This (-no-daemon --parallel-threads 1) didn't help me.
>       Eventually, the
>      > testsuite will complete but it seems to take a long time (45
>     minutes or
>      > so).  I also tried setting GRADLE_OPTS="-Xmx1024M" but that
>     didn't help.
>      >
>      >>
>      >>>
>      >>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried
>     both to run IDEA with Java 6 (default) and Java 7 (hacked). The way
>     around that is to use `./gradlew idea` and open the project in the
>     IDE. You then have to manually add the generated source directory in
>     a few modules.
>      >>> Things are explained here:
>     https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
>      >>>
>      >>> Emmanuel
>      >>> _______________________________________________
>      >>> hibernate-dev mailing list
>      >>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>
>      >>
>      >> _______________________________________________
>      >> hibernate-dev mailing list
>      >> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>      >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>
>      >
>      > _______________________________________________
>      > hibernate-dev mailing list
>      > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>


From gbadner at redhat.com  Wed Jul  9 18:07:46 2014
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 9 Jul 2014 18:07:46 -0400 (EDT)
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To: <CAA82DC4-6FBB-49A9-8534-EB608D3F9B0B@hibernate.org>
References: <CAFm4XO0knssmVFEhfkO3_DkrN0OPuBJ2O7pnkxVVhAkkok7Qcw@mail.gmail.com>
	<CAFdSV9ud3hShQSt0uSdp9raA9aS3XfMsLeKe-oA+M2PkAqXUVA@mail.gmail.com>
	<CADGJaX-k7n5wscu_PNCsM+jVnQ8bhrFi5Pt1L3ebxtARTOpQ_A@mail.gmail.com>
	<CAFm4XO3D59oEJrcA5fUppiwB3UQoZrfsXGQg4VhTzbR99_iNbA@mail.gmail.com>
	<AF693BDE-7985-4D02-91EE-5E1D9C371FFD@hibernate.org>
	<CADGJaX-Dau389ZPA-gBVm7hKqKj8A5uSHem+e=_0YFt4wvjKpw@mail.gmail.com>
	<CAA82DC4-6FBB-49A9-8534-EB608D3F9B0B@hibernate.org>
Message-ID: <449512583.10369329.1404943666419.JavaMail.zimbra@redhat.com>

I don't see HHH-8683 is pushed and resolved.

I will do the release later this evening.

Thanks,
Gail

----- Original Message -----
> From: "Emmanuel Bernard" <emmanuel at hibernate.org>
> To: "Gunnar Morling" <gunnar at hibernate.org>
> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Wednesday, July 9, 2014 9:07:16 AM
> Subject: Re: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
> 
> 
> On 09 Jul 2014, at 14:38, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> > 2014-07-09 13:24 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> > We need to address some of Gunnar?s comments on the master PR. He proposed
> > some renaming for example. Gunnar, do you want to take the lead?
> > 
> > Yes, I can do the merge to 4.3.
> > 
> > I don't have strong feelings on the renaming, but I'm a bit concerned about
> > the de-serialization issue. Do we for now just assume that all potential
> > EE implementations use the same persistent representation? Then always
> > de-serializing into DefaultEntityEntry as it's currently happening should
> > be ok.
> 
> That has my preference. But we should find a way to make it more explicit.
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 


From gbadner at redhat.com  Wed Jul  9 19:15:10 2014
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 9 Jul 2014 19:15:10 -0400 (EDT)
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To: <449512583.10369329.1404943666419.JavaMail.zimbra@redhat.com>
References: <CAFm4XO0knssmVFEhfkO3_DkrN0OPuBJ2O7pnkxVVhAkkok7Qcw@mail.gmail.com>
	<CAFdSV9ud3hShQSt0uSdp9raA9aS3XfMsLeKe-oA+M2PkAqXUVA@mail.gmail.com>
	<CADGJaX-k7n5wscu_PNCsM+jVnQ8bhrFi5Pt1L3ebxtARTOpQ_A@mail.gmail.com>
	<CAFm4XO3D59oEJrcA5fUppiwB3UQoZrfsXGQg4VhTzbR99_iNbA@mail.gmail.com>
	<AF693BDE-7985-4D02-91EE-5E1D9C371FFD@hibernate.org>
	<CADGJaX-Dau389ZPA-gBVm7hKqKj8A5uSHem+e=_0YFt4wvjKpw@mail.gmail.com>
	<CAA82DC4-6FBB-49A9-8534-EB608D3F9B0B@hibernate.org>
	<449512583.10369329.1404943666419.JavaMail.zimbra@redhat.com>
Message-ID: <1372043681.10413884.1404947710421.JavaMail.zimbra@redhat.com>

Oops, it is there...

----- Original Message -----
> From: "Gail Badner" <gbadner at redhat.com>
> To: "Emmanuel Bernard" <emmanuel at hibernate.org>
> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Wednesday, July 9, 2014 3:07:46 PM
> Subject: Re: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
> 
> I don't see HHH-8683 is pushed and resolved.
> 
> I will do the release later this evening.
> 
> Thanks,
> Gail
> 
> ----- Original Message -----
> > From: "Emmanuel Bernard" <emmanuel at hibernate.org>
> > To: "Gunnar Morling" <gunnar at hibernate.org>
> > Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> > Sent: Wednesday, July 9, 2014 9:07:16 AM
> > Subject: Re: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
> > 
> > 
> > On 09 Jul 2014, at 14:38, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 
> > > 2014-07-09 13:24 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> > > We need to address some of Gunnar?s comments on the master PR. He
> > > proposed
> > > some renaming for example. Gunnar, do you want to take the lead?
> > > 
> > > Yes, I can do the merge to 4.3.
> > > 
> > > I don't have strong feelings on the renaming, but I'm a bit concerned
> > > about
> > > the de-serialization issue. Do we for now just assume that all potential
> > > EE implementations use the same persistent representation? Then always
> > > de-serializing into DefaultEntityEntry as it's currently happening should
> > > be ok.
> > 
> > That has my preference. But we should find a way to make it more explicit.
> > 
> > _______________________________________________
> > 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


From gbadner at redhat.com  Thu Jul 10 02:40:49 2014
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 10 Jul 2014 02:40:49 -0400 (EDT)
Subject: [hibernate-dev] Delaying 4.3.6 until tomorrow
In-Reply-To: <822063939.10746061.1404974394132.JavaMail.zimbra@redhat.com>
Message-ID: <825983463.10746168.1404974449906.JavaMail.zimbra@redhat.com>

I've started making preparations for the 4.3.6 release, but now I can't access the wiki with release instructions. 

Since it's getting late anyhow, I'm going to put off releasing until tomorrow.

Gail

From steve at hibernate.org  Thu Jul 10 10:40:32 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 10 Jul 2014 09:40:32 -0500
Subject: [hibernate-dev] Delaying 4.3.6 until tomorrow
In-Reply-To: <825983463.10746168.1404974449906.JavaMail.zimbra@redhat.com>
References: <822063939.10746061.1404974394132.JavaMail.zimbra@redhat.com>
	<825983463.10746168.1404974449906.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9v0hAuZRyRQ9+tbw57QU_G6HagxFoWdpduj-W6U7y-KOQ@mail.gmail.com>

Ping me in the morning if you still can't get to it.  Could you just not
see it?  Or was something down with JBoss.org?


On Thu, Jul 10, 2014 at 1:40 AM, Gail Badner <gbadner at redhat.com> wrote:

> I've started making preparations for the 4.3.6 release, but now I can't
> access the wiki with release instructions.
>
> Since it's getting late anyhow, I'm going to put off releasing until
> tomorrow.
>
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Thu Jul 10 13:19:52 2014
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 10 Jul 2014 13:19:52 -0400 (EDT)
Subject: [hibernate-dev] Delaying 4.3.6 until tomorrow
In-Reply-To: <CAFdSV9v0hAuZRyRQ9+tbw57QU_G6HagxFoWdpduj-W6U7y-KOQ@mail.gmail.com>
References: <822063939.10746061.1404974394132.JavaMail.zimbra@redhat.com>
	<825983463.10746168.1404974449906.JavaMail.zimbra@redhat.com>
	<CAFdSV9v0hAuZRyRQ9+tbw57QU_G6HagxFoWdpduj-W6U7y-KOQ@mail.gmail.com>
Message-ID: <395446612.11699892.1405012792549.JavaMail.zimbra@redhat.com>

I can see it now. It must have gone down last night.

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Thursday, July 10, 2014 7:40:32 AM
> Subject: Re: [hibernate-dev] Delaying 4.3.6 until tomorrow
> 
> Ping me in the morning if you still can't get to it.  Could you just not
> see it?  Or was something down with JBoss.org?
> 
> 
> On Thu, Jul 10, 2014 at 1:40 AM, Gail Badner <gbadner at redhat.com> wrote:
> 
> > I've started making preparations for the 4.3.6 release, but now I can't
> > access the wiki with release instructions.
> >
> > Since it's getting late anyhow, I'm going to put off releasing until
> > tomorrow.
> >
> > Gail
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 

From gbadner at redhat.com  Thu Jul 10 14:43:45 2014
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 10 Jul 2014 14:43:45 -0400 (EDT)
Subject: [hibernate-dev] Scheduling 4.3.6 and 4.2.15 releases for Wednesday,
	7/16/14
In-Reply-To: <1017990003.11792037.1405017652575.JavaMail.zimbra@redhat.com>
Message-ID: <406153936.11799871.1405017825086.JavaMail.zimbra@redhat.com>

I am rescheduling the 4.3.6 release for Wednesday next week.

That will give us enough time to do necessary backports to 4.2 and also release 4.2.15.

Regards,
Gail

From davide at hibernate.org  Thu Jul 10 17:44:18 2014
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 10 Jul 2014 22:44:18 +0100
Subject: [hibernate-dev] Hibernate OGM 4.1 Beta 5 is out: JP-QL queries for
	Neo4j and more
Message-ID: <CANoTJYNFDJ6esqLj6CTvqqTdgi-uDPQ8Ls4BGFDY3jkxHX4mBQ@mail.gmail.com>

It's my pleasure to announce a new release of Hibernate OGM.

Hibernate OGM can now convert JP-QL queries into cypher queries when
working with Neo4j. We improved the JSON representation used for
associations in CouchDB and MongoDB making it more concise. We also worked
on several bug fixes and improvements under the hood.

Check out the anonuncement for more details[1].
Davide
[1]
http://in.relation.to/Bloggers/HibernateOGM410Beta5IsOutJPQLQueriesForNeo4jAndMore
<http://in.relation.to/Bloggers/HibernateOGM410Beta4IsOutWithSupportForMongoDBCLISyntaxAndBidirectionalRelationshipsForNeo4j>

From sanne at hibernate.org  Fri Jul 11 04:55:20 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 11 Jul 2014 09:55:20 +0100
Subject: [hibernate-dev] Scheduling 4.3.6 and 4.2.15 releases for
 Wednesday, 7/16/14
In-Reply-To: <406153936.11799871.1405017825086.JavaMail.zimbra@redhat.com>
References: <1017990003.11792037.1405017652575.JavaMail.zimbra@redhat.com>
	<406153936.11799871.1405017825086.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO3cbOZqFurJmE1G3d8etsqq5d3isD4Et7f8BBdiyafr0Q@mail.gmail.com>

Gail,  there are (at least) two other Hibernate projects waiting for that
release. Sad news!
On 10 Jul 2014 19:44, "Gail Badner" <gbadner at redhat.com> wrote:

> I am rescheduling the 4.3.6 release for Wednesday next week.
>
> That will give us enough time to do necessary backports to 4.2 and also
> release 4.2.15.
>
> Regards,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From paranoiabla at gmail.com  Fri Jul 11 07:53:18 2014
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Fri, 11 Jul 2014 14:53:18 +0300
Subject: [hibernate-dev] Hibernate + Log4J2 Performance Problem
Message-ID: <CAKnbemUZ5KCgTDpfj4bY7iJNbvUiGtRonxJvDYS1BGTTKFQBdg@mail.gmail.com>

Hello,

I'm really sorry to post this here but I couldn't find any jboss-logging
mailing list. So here's my question. I'm reading this issue:

https://issues.jboss.org/browse/JBLOGGING-95

and I'm trying to make my hibernate use log4j2. So far I had

<dependency>
    <groupId>org.jboss.logging</groupId>
    <artifactId>jboss-logging-log4j</artifactId>
     <version>${jboss.logging.version}</version>
</dependency>

and I have log4j -> log4j2 routed. Unfortunately now my hibernate creates a
log4j.log file and log4j prints the messages to the command line (still no
log4j2) :(

So I got rid of this dependency and I added the jboss-logging. So now
here's my set of jars:

hibernate-core
hibernate-entitymanager
hibernate-c3p0
hibernate-validator
log4j2
org.jboss.logging:jboss-logging:jar:3.2.0.Beta1

then I run my task and I get performance of:
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 3:12.951s
[INFO] Finished at: Fri Jul 11 12:50:41 EEST 2014
[INFO] Final Memory: 128M/508M
[INFO]
------------------------------------------------------------------------

3 minutes and 12 seconds. Performance is quite good. However I use the
maven enforcer plugin and maven did warn me I have duplicate classes:

Duplicate classes found:

  Found in:
    org.jboss.logging:jboss-logging:jar:3.1.3.GA:compile
    org.jboss.logging:jboss-logging:jar:3.2.0.Beta1:compile
  Duplicate classes:
    org/jboss/logging/Field.class
    org/jboss/logging/LoggerProvider.class
    org/jboss/logging/Log4jLoggerProvider.class
    org/jboss/logging/NDC.class
    org/jboss/logging/MessageBundle.class
    org/jboss/logging/AbstractMdcLoggerProvider.class
    org/jboss/logging/Log4jLogger$1.class
    org/jboss/logging/Messages$1.class
    org/jboss/logging/JDKLevel.class
    org/jboss/logging/DelegatingBasicLogger.class
    org/jboss/logging/JDKLoggerProvider.class
    org/jboss/logging/Slf4jLoggerProvider.class
    org/jboss/logging/LoggingClass.class
    org/jboss/logging/Messages.class
    org/jboss/logging/AbstractLoggerProvider.class
    org/jboss/logging/Property.class
    org/jboss/logging/JBossLogRecord.class
    org/jboss/logging/SerializedLogger.class
    org/jboss/logging/Message.class
    org/jboss/logging/MDC.class
    org/jboss/logging/Message$Format.class
    org/jboss/logging/JBossLogManagerProvider$1.class
    org/jboss/logging/Cause.class
    org/jboss/logging/Param.class
    org/jboss/logging/JDKLogger$1.class
    org/jboss/logging/JBossLogManagerLogger.class
    org/jboss/logging/Slf4jLogger.class
    org/jboss/logging/JBossLogManagerProvider.class
    org/jboss/logging/FormatWith.class
    org/jboss/logging/Slf4jLocationAwareLogger$1.class
    org/jboss/logging/Logger$Level.class
    org/jboss/logging/BasicLogger.class
    org/jboss/logging/Logger$1.class
    org/jboss/logging/JDKLogger.class
    org/jboss/logging/JBossLogManagerLogger$1.class
    org/jboss/logging/MessageLogger.class
    org/jboss/logging/ParameterConverter.class
    org/jboss/logging/Logger.class
    org/jboss/logging/Slf4jLocationAwareLogger.class
    org/jboss/logging/Log4jLogger.class
    org/jboss/logging/LoggerProviders$1.class
    org/jboss/logging/Slf4jLogger$1.class
    org/jboss/logging/AbstractLoggerProvider$Entry.class
    org/jboss/logging/LogMessage.class
    org/jboss/logging/LoggerProviders.class

I excluded the jboss-logging from all hibernate dependencies like this:
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-validator</artifactId>
            <version>${hibernate.validator.version}</version>
            <exclusions>
                <exclusion>
                    <groupId>org.jboss.logging</groupId>
                    <artifactId>jboss-logging</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

No more duplicate classes :) . I run the same task again and here's the
performance:

[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1:30:04.829s
[INFO] Finished at: Fri Jul 11 12:28:08 EEST 2014
[INFO] Final Memory: 118M/512M
[INFO]
------------------------------------------------------------------------

1 hour and 30 minutes and 4 seconds!!!!!! OMG :X How could this be??? And
on top of this no Log4j messages are coming through :(

This is probably a bug or I'm clearly missing how to setup Hibernate and
LOG4J2. Can you please help me, or at least point me to a forum or mailing
list where I can post this.


-- 
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

From sanne at hibernate.org  Fri Jul 11 08:17:36 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 11 Jul 2014 13:17:36 +0100
Subject: [hibernate-dev] Hibernate + Log4J2 Performance Problem
In-Reply-To: <CAKnbemUZ5KCgTDpfj4bY7iJNbvUiGtRonxJvDYS1BGTTKFQBdg@mail.gmail.com>
References: <CAKnbemUZ5KCgTDpfj4bY7iJNbvUiGtRonxJvDYS1BGTTKFQBdg@mail.gmail.com>
Message-ID: <CAFm4XO3_3WCKebyD3-gyzYjMDoH7ZkCqG9RO9Ks78LrG9eh3bQ@mail.gmail.com>

Hi,
I never tried Log4j2 myself, but while excluding all jboss-logging
artifacts, are you making sure you keep at least one (compatible)
version of it?
You need JBoss Logging to log anything, even if you re-route the
actual output to a different logger, as that's what Hibernate will use
as primary fa?ade.

HTH
Sanne

On 11 July 2014 12:53, Petar Tahchiev <paranoiabla at gmail.com> wrote:
> Hello,
>
> I'm really sorry to post this here but I couldn't find any jboss-logging
> mailing list. So here's my question. I'm reading this issue:
>
> https://issues.jboss.org/browse/JBLOGGING-95
>
> and I'm trying to make my hibernate use log4j2. So far I had
>
> <dependency>
>     <groupId>org.jboss.logging</groupId>
>     <artifactId>jboss-logging-log4j</artifactId>
>      <version>${jboss.logging.version}</version>
> </dependency>
>
> and I have log4j -> log4j2 routed. Unfortunately now my hibernate creates a
> log4j.log file and log4j prints the messages to the command line (still no
> log4j2) :(
>
> So I got rid of this dependency and I added the jboss-logging. So now
> here's my set of jars:
>
> hibernate-core
> hibernate-entitymanager
> hibernate-c3p0
> hibernate-validator
> log4j2
> org.jboss.logging:jboss-logging:jar:3.2.0.Beta1
>
> then I run my task and I get performance of:
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 3:12.951s
> [INFO] Finished at: Fri Jul 11 12:50:41 EEST 2014
> [INFO] Final Memory: 128M/508M
> [INFO]
> ------------------------------------------------------------------------
>
> 3 minutes and 12 seconds. Performance is quite good. However I use the
> maven enforcer plugin and maven did warn me I have duplicate classes:
>
> Duplicate classes found:
>
>   Found in:
>     org.jboss.logging:jboss-logging:jar:3.1.3.GA:compile
>     org.jboss.logging:jboss-logging:jar:3.2.0.Beta1:compile
>   Duplicate classes:
>     org/jboss/logging/Field.class
>     org/jboss/logging/LoggerProvider.class
>     org/jboss/logging/Log4jLoggerProvider.class
>     org/jboss/logging/NDC.class
>     org/jboss/logging/MessageBundle.class
>     org/jboss/logging/AbstractMdcLoggerProvider.class
>     org/jboss/logging/Log4jLogger$1.class
>     org/jboss/logging/Messages$1.class
>     org/jboss/logging/JDKLevel.class
>     org/jboss/logging/DelegatingBasicLogger.class
>     org/jboss/logging/JDKLoggerProvider.class
>     org/jboss/logging/Slf4jLoggerProvider.class
>     org/jboss/logging/LoggingClass.class
>     org/jboss/logging/Messages.class
>     org/jboss/logging/AbstractLoggerProvider.class
>     org/jboss/logging/Property.class
>     org/jboss/logging/JBossLogRecord.class
>     org/jboss/logging/SerializedLogger.class
>     org/jboss/logging/Message.class
>     org/jboss/logging/MDC.class
>     org/jboss/logging/Message$Format.class
>     org/jboss/logging/JBossLogManagerProvider$1.class
>     org/jboss/logging/Cause.class
>     org/jboss/logging/Param.class
>     org/jboss/logging/JDKLogger$1.class
>     org/jboss/logging/JBossLogManagerLogger.class
>     org/jboss/logging/Slf4jLogger.class
>     org/jboss/logging/JBossLogManagerProvider.class
>     org/jboss/logging/FormatWith.class
>     org/jboss/logging/Slf4jLocationAwareLogger$1.class
>     org/jboss/logging/Logger$Level.class
>     org/jboss/logging/BasicLogger.class
>     org/jboss/logging/Logger$1.class
>     org/jboss/logging/JDKLogger.class
>     org/jboss/logging/JBossLogManagerLogger$1.class
>     org/jboss/logging/MessageLogger.class
>     org/jboss/logging/ParameterConverter.class
>     org/jboss/logging/Logger.class
>     org/jboss/logging/Slf4jLocationAwareLogger.class
>     org/jboss/logging/Log4jLogger.class
>     org/jboss/logging/LoggerProviders$1.class
>     org/jboss/logging/Slf4jLogger$1.class
>     org/jboss/logging/AbstractLoggerProvider$Entry.class
>     org/jboss/logging/LogMessage.class
>     org/jboss/logging/LoggerProviders.class
>
> I excluded the jboss-logging from all hibernate dependencies like this:
>         <dependency>
>             <groupId>org.hibernate</groupId>
>             <artifactId>hibernate-validator</artifactId>
>             <version>${hibernate.validator.version}</version>
>             <exclusions>
>                 <exclusion>
>                     <groupId>org.jboss.logging</groupId>
>                     <artifactId>jboss-logging</artifactId>
>                 </exclusion>
>             </exclusions>
>         </dependency>
>
> No more duplicate classes :) . I run the same task again and here's the
> performance:
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 1:30:04.829s
> [INFO] Finished at: Fri Jul 11 12:28:08 EEST 2014
> [INFO] Final Memory: 118M/512M
> [INFO]
> ------------------------------------------------------------------------
>
> 1 hour and 30 minutes and 4 seconds!!!!!! OMG :X How could this be??? And
> on top of this no Log4j messages are coming through :(
>
> This is probably a bug or I'm clearly missing how to setup Hibernate and
> LOG4J2. Can you please help me, or at least point me to a forum or mailing
> list where I can post this.
>
>
> --
> 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


From paranoiabla at gmail.com  Fri Jul 11 08:44:04 2014
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Fri, 11 Jul 2014 15:44:04 +0300
Subject: [hibernate-dev] Hibernate + Log4J2 Performance Problem
In-Reply-To: <CAFm4XO3_3WCKebyD3-gyzYjMDoH7ZkCqG9RO9Ks78LrG9eh3bQ@mail.gmail.com>
References: <CAKnbemUZ5KCgTDpfj4bY7iJNbvUiGtRonxJvDYS1BGTTKFQBdg@mail.gmail.com>
	<CAFm4XO3_3WCKebyD3-gyzYjMDoH7ZkCqG9RO9Ks78LrG9eh3bQ@mail.gmail.com>
Message-ID: <CAKnbemXcTWTArKDpd-4WSpAaMaLU_chNobdVS-zOL+FA=FL0Uw@mail.gmail.com>

Hi Sanne,

yes, as you can see:
-------------------------------------------------
So I got rid of this dependency and I added the jboss-logging. So now
here's my set of jars:

hibernate-core
hibernate-entitymanager
hibernate-c3p0
hibernate-validator
log4j2
org.jboss.logging:jboss-logging:jar:3.2.0.Beta1
-----------------------------------------
I have log4j2 and jboss-logging:jar:3.2.0.Beta1

I upgraded to version 3.2.0.Beta1 because this bug

https://issues.jboss.org/browse/JBLOGGING-95

mentions that it was fixed in this version.



2014-07-11 15:17 GMT+03:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi,
> I never tried Log4j2 myself, but while excluding all jboss-logging
> artifacts, are you making sure you keep at least one (compatible)
> version of it?
> You need JBoss Logging to log anything, even if you re-route the
> actual output to a different logger, as that's what Hibernate will use
> as primary fa?ade.
>
> HTH
> Sanne
>
> On 11 July 2014 12:53, Petar Tahchiev <paranoiabla at gmail.com> wrote:
> > Hello,
> >
> > I'm really sorry to post this here but I couldn't find any jboss-logging
> > mailing list. So here's my question. I'm reading this issue:
> >
> > https://issues.jboss.org/browse/JBLOGGING-95
> >
> > and I'm trying to make my hibernate use log4j2. So far I had
> >
> > <dependency>
> >     <groupId>org.jboss.logging</groupId>
> >     <artifactId>jboss-logging-log4j</artifactId>
> >      <version>${jboss.logging.version}</version>
> > </dependency>
> >
> > and I have log4j -> log4j2 routed. Unfortunately now my hibernate
> creates a
> > log4j.log file and log4j prints the messages to the command line (still
> no
> > log4j2) :(
> >
> > So I got rid of this dependency and I added the jboss-logging. So now
> > here's my set of jars:
> >
> > hibernate-core
> > hibernate-entitymanager
> > hibernate-c3p0
> > hibernate-validator
> > log4j2
> > org.jboss.logging:jboss-logging:jar:3.2.0.Beta1
> >
> > then I run my task and I get performance of:
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] BUILD SUCCESS
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Total time: 3:12.951s
> > [INFO] Finished at: Fri Jul 11 12:50:41 EEST 2014
> > [INFO] Final Memory: 128M/508M
> > [INFO]
> > ------------------------------------------------------------------------
> >
> > 3 minutes and 12 seconds. Performance is quite good. However I use the
> > maven enforcer plugin and maven did warn me I have duplicate classes:
> >
> > Duplicate classes found:
> >
> >   Found in:
> >     org.jboss.logging:jboss-logging:jar:3.1.3.GA:compile
> >     org.jboss.logging:jboss-logging:jar:3.2.0.Beta1:compile
> >   Duplicate classes:
> >     org/jboss/logging/Field.class
> >     org/jboss/logging/LoggerProvider.class
> >     org/jboss/logging/Log4jLoggerProvider.class
> >     org/jboss/logging/NDC.class
> >     org/jboss/logging/MessageBundle.class
> >     org/jboss/logging/AbstractMdcLoggerProvider.class
> >     org/jboss/logging/Log4jLogger$1.class
> >     org/jboss/logging/Messages$1.class
> >     org/jboss/logging/JDKLevel.class
> >     org/jboss/logging/DelegatingBasicLogger.class
> >     org/jboss/logging/JDKLoggerProvider.class
> >     org/jboss/logging/Slf4jLoggerProvider.class
> >     org/jboss/logging/LoggingClass.class
> >     org/jboss/logging/Messages.class
> >     org/jboss/logging/AbstractLoggerProvider.class
> >     org/jboss/logging/Property.class
> >     org/jboss/logging/JBossLogRecord.class
> >     org/jboss/logging/SerializedLogger.class
> >     org/jboss/logging/Message.class
> >     org/jboss/logging/MDC.class
> >     org/jboss/logging/Message$Format.class
> >     org/jboss/logging/JBossLogManagerProvider$1.class
> >     org/jboss/logging/Cause.class
> >     org/jboss/logging/Param.class
> >     org/jboss/logging/JDKLogger$1.class
> >     org/jboss/logging/JBossLogManagerLogger.class
> >     org/jboss/logging/Slf4jLogger.class
> >     org/jboss/logging/JBossLogManagerProvider.class
> >     org/jboss/logging/FormatWith.class
> >     org/jboss/logging/Slf4jLocationAwareLogger$1.class
> >     org/jboss/logging/Logger$Level.class
> >     org/jboss/logging/BasicLogger.class
> >     org/jboss/logging/Logger$1.class
> >     org/jboss/logging/JDKLogger.class
> >     org/jboss/logging/JBossLogManagerLogger$1.class
> >     org/jboss/logging/MessageLogger.class
> >     org/jboss/logging/ParameterConverter.class
> >     org/jboss/logging/Logger.class
> >     org/jboss/logging/Slf4jLocationAwareLogger.class
> >     org/jboss/logging/Log4jLogger.class
> >     org/jboss/logging/LoggerProviders$1.class
> >     org/jboss/logging/Slf4jLogger$1.class
> >     org/jboss/logging/AbstractLoggerProvider$Entry.class
> >     org/jboss/logging/LogMessage.class
> >     org/jboss/logging/LoggerProviders.class
> >
> > I excluded the jboss-logging from all hibernate dependencies like this:
> >         <dependency>
> >             <groupId>org.hibernate</groupId>
> >             <artifactId>hibernate-validator</artifactId>
> >             <version>${hibernate.validator.version}</version>
> >             <exclusions>
> >                 <exclusion>
> >                     <groupId>org.jboss.logging</groupId>
> >                     <artifactId>jboss-logging</artifactId>
> >                 </exclusion>
> >             </exclusions>
> >         </dependency>
> >
> > No more duplicate classes :) . I run the same task again and here's the
> > performance:
> >
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] BUILD SUCCESS
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Total time: 1:30:04.829s
> > [INFO] Finished at: Fri Jul 11 12:28:08 EEST 2014
> > [INFO] Final Memory: 118M/512M
> > [INFO]
> > ------------------------------------------------------------------------
> >
> > 1 hour and 30 minutes and 4 seconds!!!!!! OMG :X How could this be??? And
> > on top of this no Log4j messages are coming through :(
> >
> > This is probably a bug or I'm clearly missing how to setup Hibernate and
> > LOG4J2. Can you please help me, or at least point me to a forum or
> mailing
> > list where I can post this.
> >
> >
> > --
> > 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

From smarlow at redhat.com  Fri Jul 11 09:06:13 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 11 Jul 2014 09:06:13 -0400
Subject: [hibernate-dev] Hibernate + Log4J2 Performance Problem
In-Reply-To: <CAKnbemUZ5KCgTDpfj4bY7iJNbvUiGtRonxJvDYS1BGTTKFQBdg@mail.gmail.com>
References: <CAKnbemUZ5KCgTDpfj4bY7iJNbvUiGtRonxJvDYS1BGTTKFQBdg@mail.gmail.com>
Message-ID: <53BFE145.2090408@redhat.com>


On 07/11/2014 07:53 AM, Petar Tahchiev wrote:
> Hello,
>
> I'm really sorry to post this here but I couldn't find any jboss-logging
> mailing list.

https://lists.jboss.org/mailman/listinfo/wildfly-dev might also be a 
good place to post on.  The developers that work on jboss-logging, will 
see your wildfly-dev post but probably not your hibernate-dev post.

Scott


From smarlow at redhat.com  Fri Jul 11 09:36:32 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 11 Jul 2014 09:36:32 -0400
Subject: [hibernate-dev] failures running with a Java security manager + ORM
	4.3.5.Final
Message-ID: <53BFE860.3030802@redhat.com>

I have been running the EE 7 compatibility tests with the Java security 
manager enabled to find issues like http://pastie.org/9378079

Should we try to fix these on the ORM 4.3 branch (WildFly 9.0 currently 
is using 4.3.5.Final) or on master (which should show up in WildFly at 
some point)?

Scott

From paranoiabla at gmail.com  Fri Jul 11 10:23:37 2014
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Fri, 11 Jul 2014 17:23:37 +0300
Subject: [hibernate-dev]  Delaying 4.3.6 until tomorrow
Message-ID: <CAKnbemXez6r0Xb2E+Bmrif4ftA6kokPZ5DWr9UOe=ruFtO1Hcw@mail.gmail.com>

Hi guys,

any chance to have this included in 4.3.6:

https://hibernate.atlassian.net/browse/HHH-9217

I have supplied a pull request - it's really simple but keeps blocking me.

-- 
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

From sanne at hibernate.org  Fri Jul 11 18:35:41 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 11 Jul 2014 23:35:41 +0100
Subject: [hibernate-dev] Released Hibernate Commons Annotations 4.0.5.Final
Message-ID: <CAFm4XO3qQp4VZxeRZxjEaD_=E6fTKkZ+Q_bVQFCNyofUGowwXg@mail.gmail.com>

Hello all,
I've just release Hibernate Commons Annotations 4.0.5.Final, to fix a
single but annoying issue:
https://hibernate.atlassian.net/browse/HCANN-60

-- Sanne

From sanne at hibernate.org  Sun Jul 13 08:47:51 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 13 Jul 2014 13:47:51 +0100
Subject: [hibernate-dev] Explaining versioning and dependency compatibility
Message-ID: <CAFm4XO08YPe34Z=sZQc9yZTkPZSQauKUdhfAoND9kf2t1tnrnQ@mail.gmail.com>

I've been explaining $subject to a forum user [1]. I'm confident it's
only a problem for newcomers, but are we expecting more expert
developers to pass this lore by word of mouth?

I think we should add an explanation on these on the website but I'm
not sure where this would be more appropriate to present.

Should we highlight compatible versions of other integration points on
each sub section?
For example I could edit the Search area to mention which versions of
ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
different ones!), Commons Annotations, etc.. are supposed to work for
each release.

[1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292

-- Sanne

From sanne at hibernate.org  Sun Jul 13 18:30:37 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 13 Jul 2014 23:30:37 +0100
Subject: [hibernate-dev] Removal of method in ServiceRegistryBuilder broke
	JBoss Tools
Message-ID: <CAFm4XO3BdubybSr9yh+S4+d+K9D=ue4Tnv=43gma+b7PiYQL7g@mail.gmail.com>

Just noticed this post, a user unable to use Hibernate 4.3.5.Final
with the Hibernate/JBoss Tools:
https://forum.hibernate.org/viewtopic.php?f=6&t=1035330

The method "buildServiceRegistry()" seems to have been renamed to
"build()", but also the class was deprecated.
Seems useful to just add the old method back, as a delegate to
build().. may I do that?

-- Sanne

From gunnar at hibernate.org  Mon Jul 14 06:21:40 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 14 Jul 2014 12:21:40 +0200
Subject: [hibernate-dev] Explaining versioning and dependency
	compatibility
In-Reply-To: <CAFm4XO08YPe34Z=sZQc9yZTkPZSQauKUdhfAoND9kf2t1tnrnQ@mail.gmail.com>
References: <CAFm4XO08YPe34Z=sZQc9yZTkPZSQauKUdhfAoND9kf2t1tnrnQ@mail.gmail.com>
Message-ID: <CADGJaX9J4P5M-BJx0Vk-FWw2jfVDnKrN8wrhQFc8Nbs262Q=jQ@mail.gmail.com>

2014-07-13 14:47 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> I've been explaining $subject to a forum user [1]. I'm confident it's
> only a problem for newcomers, but are we expecting more expert
> developers to pass this lore by word of mouth?
>

Not so sure whether it's not a problem for expert users as well every now
and then.

Looking at OGM for instance, we're currently in the situation that we
depend on a specific micro version of ORM (4.3.6 once it's out), which may
be a surprising fact. Personally, I think it'd be rational for a user to
expect compatibility based on minor version families of our projects, e.g.
that each OGM 4.1.x release is compatible with each ORM 4.3.x release.

As we can't guarantee this due to the rapid evolvement atm. (e.g. we add
new SPIs in ORM micro releases for the sake of OGM), some clear
documentation is highly desirable.

I think we should add an explanation on these on the website but I'm
> not sure where this would be more appropriate to present.
>
> Should we highlight compatible versions of other integration points on
> each sub section?
> For example I could edit the Search area to mention which versions of
> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
> different ones!), Commons Annotations, etc.. are supposed to work for
> each release.
>

Documenting the matching/required versions of upstream projects in each
project area may be one way. E.g. Search could document its requirements,
OGM its own etc. I don't think Search should document any expectations
towards OGM versions as the dependency is the other way around?

Speaking in Maven terms, I still think that providing this information in
form of bill-of-materials POMs would be the approach most helpful to users.
Such project BOM would contain the versions of all its components and
dependencies. Users would reference this BOM using the "import" scope in
their dependency management configuration and thus get matching versions
when declaring a dependency to any of the artifacts listed in the BOM.

I vaguely remember though that in the past there had been reservations
towards providing such BOMs?

@Davide, I've created https://hibernate.atlassian.net/browse/OGM-574 to do
this for OGM; Shall we give it a try?

--Gunnar



> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
>
> -- Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Jul 14 06:54:03 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 14 Jul 2014 11:54:03 +0100
Subject: [hibernate-dev] Explaining versioning and dependency
	compatibility
In-Reply-To: <CADGJaX9J4P5M-BJx0Vk-FWw2jfVDnKrN8wrhQFc8Nbs262Q=jQ@mail.gmail.com>
References: <CAFm4XO08YPe34Z=sZQc9yZTkPZSQauKUdhfAoND9kf2t1tnrnQ@mail.gmail.com>
	<CADGJaX9J4P5M-BJx0Vk-FWw2jfVDnKrN8wrhQFc8Nbs262Q=jQ@mail.gmail.com>
Message-ID: <CAFm4XO2EYa+1_xJ-HXOT56N0d-XjnWV_DX8ED2PyQRN+io87OQ@mail.gmail.com>

Good point on OGM' s need for a specific micro. We could propose a 4.4
series of ORM after you finish defining the integration point? So OGM
x.Final will be able to depend on a more reasonable version range.

About BOM files, I'm just skeptical as I don't see how we should
maintain and test them:
- would we update some separate BOM project at every release?
- would you re-run the testsuite of each and all projects at every BOM
update overriding the testsuite versions to make sure it's a valid
combination? (how to automate?)
- I'd also expect some integration tests to actually verify the
correctness of the BOM file (e.g. syntax)

Also the documented dependency ranges on the website could need some
testing in a perfect world, but:
a) I'd expect it to be simpler as it' s a smaller matrix if each
project documents its own dependencies only
b) each project somehow "is aware" if when it breaks compatibility
with older dependencies, like you notice now with OGM: it's an
explicit step you just have to remember to document (and rare enough
so that I wouldn't bother too much to automate).
c) *Personal opinion* I feel like a statement about *expected
compatibility* does create a lower expectation in terms of accuracy
than a BOM file, so that I wouldn't expect need for actual QA on this
subject as much as I would expect it on BOM files which we would
officially distribute.

I'm not strictly against BOM but it sounds like taking a lot of our
bandwidth for a minor practical improvement.


Ultimately we should be very aware that our modules are in constant
change, and people mixing our latest are aware of a little bit of risk
in using latest as there is a mismatch between our expectations vs our
capacity to test and deliver a single unified platform, I think that's
more something for assemblies such as WildFly, JBoss EAP, Spring, and
whoever else redistributes our jars as a combination. We should be
ready to provide recommendations (as what we expect to work) to the
people making these distributions and our users but.. would you
consider untested BOM files to be good for that?

Sanne


On 14 July 2014 11:21, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2014-07-13 14:47 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> I've been explaining $subject to a forum user [1]. I'm confident it's
>> only a problem for newcomers, but are we expecting more expert
>> developers to pass this lore by word of mouth?
>
>
> Not so sure whether it's not a problem for expert users as well every now
> and then.
>
> Looking at OGM for instance, we're currently in the situation that we depend
> on a specific micro version of ORM (4.3.6 once it's out), which may be a
> surprising fact. Personally, I think it'd be rational for a user to expect
> compatibility based on minor version families of our projects, e.g. that
> each OGM 4.1.x release is compatible with each ORM 4.3.x release.
>
> As we can't guarantee this due to the rapid evolvement atm. (e.g. we add new
> SPIs in ORM micro releases for the sake of OGM), some clear documentation is
> highly desirable.
>
>> I think we should add an explanation on these on the website but I'm
>> not sure where this would be more appropriate to present.
>>
>> Should we highlight compatible versions of other integration points on
>> each sub section?
>> For example I could edit the Search area to mention which versions of
>> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
>> different ones!), Commons Annotations, etc.. are supposed to work for
>> each release.
>
>
> Documenting the matching/required versions of upstream projects in each
> project area may be one way. E.g. Search could document its requirements,
> OGM its own etc. I don't think Search should document any expectations
> towards OGM versions as the dependency is the other way around?
>
> Speaking in Maven terms, I still think that providing this information in
> form of bill-of-materials POMs would be the approach most helpful to users.
> Such project BOM would contain the versions of all its components and
> dependencies. Users would reference this BOM using the "import" scope in
> their dependency management configuration and thus get matching versions
> when declaring a dependency to any of the artifacts listed in the BOM.
>
> I vaguely remember though that in the past there had been reservations
> towards providing such BOMs?
>
> @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574 to do
> this for OGM; Shall we give it a try?
>
> --Gunnar
>
>
>>
>> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
>>
>> -- Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From gunnar at hibernate.org  Mon Jul 14 10:23:18 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 14 Jul 2014 16:23:18 +0200
Subject: [hibernate-dev] Explaining versioning and dependency
	compatibility
In-Reply-To: <CAFm4XO2EYa+1_xJ-HXOT56N0d-XjnWV_DX8ED2PyQRN+io87OQ@mail.gmail.com>
References: <CAFm4XO08YPe34Z=sZQc9yZTkPZSQauKUdhfAoND9kf2t1tnrnQ@mail.gmail.com>
	<CADGJaX9J4P5M-BJx0Vk-FWw2jfVDnKrN8wrhQFc8Nbs262Q=jQ@mail.gmail.com>
	<CAFm4XO2EYa+1_xJ-HXOT56N0d-XjnWV_DX8ED2PyQRN+io87OQ@mail.gmail.com>
Message-ID: <CADGJaX8AHDjSiO3SidciuZtB1ZByZbR3pFT=kaANZvWxHR+vmg@mail.gmail.com>

2014-07-14 12:54 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Good point on OGM' s need for a specific micro. We could propose a 4.4
> series of ORM after you finish defining the integration point? So OGM
> x.Final will be able to depend on a more reasonable version range.
>

Yes, that'd be vey nice.


> About BOM files, I'm just skeptical as I don't see how we should
> maintain and test them:
>

We'd maintain it in the same way as we maintain the dependencyManagement
block in our current POMs. Only that it's not part of the parent POM itself
but is extracted into a separate POM file. We'd import that BOM in our own
build and thus verify and test it.

The significant difference would be that a user can do the same (import
that BOM) and thus get matching versions of our artifacts.


> - would we update some separate BOM project at every release?
>

It would be just a module of each project, e.g. hibernate-ogm-bom, which
gets released as all the other modules.


> - would you re-run the testsuite of each and all projects at every BOM
> update overriding the testsuite versions to make sure it's a valid
> combination? (how to automate?)

- I'd also expect some integration tests to actually verify the
> correctness of the BOM file (e.g. syntax)
>

See above, as the BOM would be used in a project's build itself, it gets
verified.


> Also the documented dependency ranges on the website could need some
> testing in a perfect world, but:
> a) I'd expect it to be simpler as it' s a smaller matrix if each
> project documents its own dependencies only
> b) each project somehow "is aware" if when it breaks compatibility
> with older dependencies, like you notice now with OGM: it's an
> explicit step you just have to remember to document (and rare enough
> so that I wouldn't bother too much to automate).
> c) *Personal opinion* I feel like a statement about *expected
> compatibility* does create a lower expectation in terms of accuracy
> than a BOM file, so that I wouldn't expect need for actual QA on this
> subject as much as I would expect it on BOM files which we would
> officially distribute.
>

Atm. we also specify which version of our dependencies we expect (in our
parent POMs). So this information is there, it's only very hard for users
to extract it if they want to add any of our dependencies themselves
(they'd have to look up the version we depend on to make sure they don't
override it with a non-compatible one). By giving users the BOMs for
importing, this information is much more conveniently accessible (and there
is no risk for it of getting out-dated as with a wiki/web site based
approach).

>
> I'm not strictly against BOM but it sounds like taking a lot of our
> bandwidth for a minor practical improvement.
>

Maybe we have different things in mind?

It's not a huge effort, actually I've just pushed a branch for this for
OGM:
https://github.com/gunnarmorling/hibernate-ogm/compare/hibernate:master...gunnarmorling:OGM-574?expand=1


Ultimately we should be very aware that our modules are in constant
> change, and people mixing our latest are aware of a little bit of risk
> in using latest as there is a mismatch between our expectations vs our
> capacity to test and deliver a single unified platform, I think that's
> more something for assemblies such as WildFly, JBoss EAP, Spring, and
> whoever else redistributes our jars as a combination. We should be
> ready to provide recommendations (as what we expect to work) to the
> people making these distributions and our users but.. would you
> consider untested BOM files to be good for that?
>

They are not untested (at least in my model), as they are used for our own
build.

Sanne
>

--Gunnar


> On 14 July 2014 11:21, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >
> >> I've been explaining $subject to a forum user [1]. I'm confident it's
> >> only a problem for newcomers, but are we expecting more expert
> >> developers to pass this lore by word of mouth?
> >
> >
> > Not so sure whether it's not a problem for expert users as well every now
> > and then.
> >
> > Looking at OGM for instance, we're currently in the situation that we
> depend
> > on a specific micro version of ORM (4.3.6 once it's out), which may be a
> > surprising fact. Personally, I think it'd be rational for a user to
> expect
> > compatibility based on minor version families of our projects, e.g. that
> > each OGM 4.1.x release is compatible with each ORM 4.3.x release.
> >
> > As we can't guarantee this due to the rapid evolvement atm. (e.g. we add
> new
> > SPIs in ORM micro releases for the sake of OGM), some clear
> documentation is
> > highly desirable.
> >
> >> I think we should add an explanation on these on the website but I'm
> >> not sure where this would be more appropriate to present.
> >>
> >> Should we highlight compatible versions of other integration points on
> >> each sub section?
> >> For example I could edit the Search area to mention which versions of
> >> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
> >> different ones!), Commons Annotations, etc.. are supposed to work for
> >> each release.
> >
> >
> > Documenting the matching/required versions of upstream projects in each
> > project area may be one way. E.g. Search could document its requirements,
> > OGM its own etc. I don't think Search should document any expectations
> > towards OGM versions as the dependency is the other way around?
> >
> > Speaking in Maven terms, I still think that providing this information in
> > form of bill-of-materials POMs would be the approach most helpful to
> users.
> > Such project BOM would contain the versions of all its components and
> > dependencies. Users would reference this BOM using the "import" scope in
> > their dependency management configuration and thus get matching versions
> > when declaring a dependency to any of the artifacts listed in the BOM.
> >
> > I vaguely remember though that in the past there had been reservations
> > towards providing such BOMs?
> >
> > @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574 to
> do
> > this for OGM; Shall we give it a try?
> >
> > --Gunnar
> >
> >
> >>
> >> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
> >>
> >> -- Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From sanne at hibernate.org  Mon Jul 14 10:38:52 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 14 Jul 2014 15:38:52 +0100
Subject: [hibernate-dev] Explaining versioning and dependency
	compatibility
In-Reply-To: <CADGJaX8AHDjSiO3SidciuZtB1ZByZbR3pFT=kaANZvWxHR+vmg@mail.gmail.com>
References: <CAFm4XO08YPe34Z=sZQc9yZTkPZSQauKUdhfAoND9kf2t1tnrnQ@mail.gmail.com>
	<CADGJaX9J4P5M-BJx0Vk-FWw2jfVDnKrN8wrhQFc8Nbs262Q=jQ@mail.gmail.com>
	<CAFm4XO2EYa+1_xJ-HXOT56N0d-XjnWV_DX8ED2PyQRN+io87OQ@mail.gmail.com>
	<CADGJaX8AHDjSiO3SidciuZtB1ZByZbR3pFT=kaANZvWxHR+vmg@mail.gmail.com>
Message-ID: <CAFm4XO0D0ud=bDaJb-dJEeb3ccymx8KbR6RgscDyQdwotK8E3Q@mail.gmail.com>

On 14 July 2014 15:23, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2014-07-14 12:54 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> Good point on OGM' s need for a specific micro. We could propose a 4.4
>> series of ORM after you finish defining the integration point? So OGM
>> x.Final will be able to depend on a more reasonable version range.
>
>
> Yes, that'd be vey nice.
>
>>
>> About BOM files, I'm just skeptical as I don't see how we should
>> maintain and test them:
>
>
> We'd maintain it in the same way as we maintain the dependencyManagement
> block in our current POMs. Only that it's not part of the parent POM itself
> but is extracted into a separate POM file. We'd import that BOM in our own
> build and thus verify and test it.
>
> The significant difference would be that a user can do the same (import that
> BOM) and thus get matching versions of our artifacts.
>
>>
>> - would we update some separate BOM project at every release?
>
>
> It would be just a module of each project, e.g. hibernate-ogm-bom, which
> gets released as all the other modules.
>
>>
>> - would you re-run the testsuite of each and all projects at every BOM
>> update overriding the testsuite versions to make sure it's a valid
>> combination? (how to automate?)
>>
>> - I'd also expect some integration tests to actually verify the
>> correctness of the BOM file (e.g. syntax)
>
>
> See above, as the BOM would be used in a project's build itself, it gets
> verified.

I don't understand how this would work. Let's take Search for example,
so I'd maintain a BOM file in Hibernate Search, and release a new one
at each of Search releases?

That implies my BOM file is "the one for Hibernate Search version X",
not for all projects together.
This doesn't answer the question of users "which version of Hibernate
Validator, Hibernate ORM, Hibernate Search work fine together? "

Let's say we release multiple BOM files. How do I use those in my
project, which one do I use to define my version of ORM?
As far as I know there is no such thing as "import the union of
multiple BOMs, validating the intersection is consistent" in Maven.

Sanne



>
>>
>> Also the documented dependency ranges on the website could need some
>> testing in a perfect world, but:
>> a) I'd expect it to be simpler as it' s a smaller matrix if each
>> project documents its own dependencies only
>> b) each project somehow "is aware" if when it breaks compatibility
>> with older dependencies, like you notice now with OGM: it's an
>> explicit step you just have to remember to document (and rare enough
>> so that I wouldn't bother too much to automate).
>> c) *Personal opinion* I feel like a statement about *expected
>> compatibility* does create a lower expectation in terms of accuracy
>> than a BOM file, so that I wouldn't expect need for actual QA on this
>> subject as much as I would expect it on BOM files which we would
>> officially distribute.
>
>
> Atm. we also specify which version of our dependencies we expect (in our
> parent POMs). So this information is there, it's only very hard for users to
> extract it if they want to add any of our dependencies themselves (they'd
> have to look up the version we depend on to make sure they don't override it
> with a non-compatible one). By giving users the BOMs for importing, this
> information is much more conveniently accessible (and there is no risk for
> it of getting out-dated as with a wiki/web site based approach).
>>
>>
>> I'm not strictly against BOM but it sounds like taking a lot of our
>> bandwidth for a minor practical improvement.
>
>
> Maybe we have different things in mind?
>
> It's not a huge effort, actually I've just pushed a branch for this for OGM:
> https://github.com/gunnarmorling/hibernate-ogm/compare/hibernate:master...gunnarmorling:OGM-574?expand=1
>
>> Ultimately we should be very aware that our modules are in constant
>> change, and people mixing our latest are aware of a little bit of risk
>> in using latest as there is a mismatch between our expectations vs our
>> capacity to test and deliver a single unified platform, I think that's
>> more something for assemblies such as WildFly, JBoss EAP, Spring, and
>> whoever else redistributes our jars as a combination. We should be
>> ready to provide recommendations (as what we expect to work) to the
>> people making these distributions and our users but.. would you
>> consider untested BOM files to be good for that?
>
>
> They are not untested (at least in my model), as they are used for our own
> build.
>
>> Sanne
>
>
> --Gunnar
>
>>
>> On 14 July 2014 11:21, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >
>> >> I've been explaining $subject to a forum user [1]. I'm confident it's
>> >> only a problem for newcomers, but are we expecting more expert
>> >> developers to pass this lore by word of mouth?
>> >
>> >
>> > Not so sure whether it's not a problem for expert users as well every
>> > now
>> > and then.
>> >
>> > Looking at OGM for instance, we're currently in the situation that we
>> > depend
>> > on a specific micro version of ORM (4.3.6 once it's out), which may be a
>> > surprising fact. Personally, I think it'd be rational for a user to
>> > expect
>> > compatibility based on minor version families of our projects, e.g. that
>> > each OGM 4.1.x release is compatible with each ORM 4.3.x release.
>> >
>> > As we can't guarantee this due to the rapid evolvement atm. (e.g. we add
>> > new
>> > SPIs in ORM micro releases for the sake of OGM), some clear
>> > documentation is
>> > highly desirable.
>> >
>> >> I think we should add an explanation on these on the website but I'm
>> >> not sure where this would be more appropriate to present.
>> >>
>> >> Should we highlight compatible versions of other integration points on
>> >> each sub section?
>> >> For example I could edit the Search area to mention which versions of
>> >> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
>> >> different ones!), Commons Annotations, etc.. are supposed to work for
>> >> each release.
>> >
>> >
>> > Documenting the matching/required versions of upstream projects in each
>> > project area may be one way. E.g. Search could document its
>> > requirements,
>> > OGM its own etc. I don't think Search should document any expectations
>> > towards OGM versions as the dependency is the other way around?
>> >
>> > Speaking in Maven terms, I still think that providing this information
>> > in
>> > form of bill-of-materials POMs would be the approach most helpful to
>> > users.
>> > Such project BOM would contain the versions of all its components and
>> > dependencies. Users would reference this BOM using the "import" scope in
>> > their dependency management configuration and thus get matching versions
>> > when declaring a dependency to any of the artifacts listed in the BOM.
>> >
>> > I vaguely remember though that in the past there had been reservations
>> > towards providing such BOMs?
>> >
>> > @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574 to
>> > do
>> > this for OGM; Shall we give it a try?
>> >
>> > --Gunnar
>> >
>> >
>> >>
>> >> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
>> >>
>> >> -- Sanne
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>
>

From steve at hibernate.org  Mon Jul 14 10:44:14 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 14 Jul 2014 09:44:14 -0500
Subject: [hibernate-dev] Explaining versioning and dependency
	compatibility
In-Reply-To: <CAFm4XO2EYa+1_xJ-HXOT56N0d-XjnWV_DX8ED2PyQRN+io87OQ@mail.gmail.com>
References: <CAFm4XO08YPe34Z=sZQc9yZTkPZSQauKUdhfAoND9kf2t1tnrnQ@mail.gmail.com>
	<CADGJaX9J4P5M-BJx0Vk-FWw2jfVDnKrN8wrhQFc8Nbs262Q=jQ@mail.gmail.com>
	<CAFm4XO2EYa+1_xJ-HXOT56N0d-XjnWV_DX8ED2PyQRN+io87OQ@mail.gmail.com>
Message-ID: <CAFdSV9tnS2ZpUAaRCajTKhoncXd_M__8oKp_n7_k+aFxCwp15g@mail.gmail.com>

I actually think ORM 4.4 stabilizing the APIs and SPIs used in the other
projects would be a good idea as well.




On Mon, Jul 14, 2014 at 5:54 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Good point on OGM' s need for a specific micro. We could propose a 4.4
> series of ORM after you finish defining the integration point? So OGM
> x.Final will be able to depend on a more reasonable version range.
>
> About BOM files, I'm just skeptical as I don't see how we should
> maintain and test them:
> - would we update some separate BOM project at every release?
> - would you re-run the testsuite of each and all projects at every BOM
> update overriding the testsuite versions to make sure it's a valid
> combination? (how to automate?)
> - I'd also expect some integration tests to actually verify the
> correctness of the BOM file (e.g. syntax)
>
> Also the documented dependency ranges on the website could need some
> testing in a perfect world, but:
> a) I'd expect it to be simpler as it' s a smaller matrix if each
> project documents its own dependencies only
> b) each project somehow "is aware" if when it breaks compatibility
> with older dependencies, like you notice now with OGM: it's an
> explicit step you just have to remember to document (and rare enough
> so that I wouldn't bother too much to automate).
> c) *Personal opinion* I feel like a statement about *expected
> compatibility* does create a lower expectation in terms of accuracy
> than a BOM file, so that I wouldn't expect need for actual QA on this
> subject as much as I would expect it on BOM files which we would
> officially distribute.
>
> I'm not strictly against BOM but it sounds like taking a lot of our
> bandwidth for a minor practical improvement.
>
>
> Ultimately we should be very aware that our modules are in constant
> change, and people mixing our latest are aware of a little bit of risk
> in using latest as there is a mismatch between our expectations vs our
> capacity to test and deliver a single unified platform, I think that's
> more something for assemblies such as WildFly, JBoss EAP, Spring, and
> whoever else redistributes our jars as a combination. We should be
> ready to provide recommendations (as what we expect to work) to the
> people making these distributions and our users but.. would you
> consider untested BOM files to be good for that?
>
> Sanne
>
>
> On 14 July 2014 11:21, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >
> >> I've been explaining $subject to a forum user [1]. I'm confident it's
> >> only a problem for newcomers, but are we expecting more expert
> >> developers to pass this lore by word of mouth?
> >
> >
> > Not so sure whether it's not a problem for expert users as well every now
> > and then.
> >
> > Looking at OGM for instance, we're currently in the situation that we
> depend
> > on a specific micro version of ORM (4.3.6 once it's out), which may be a
> > surprising fact. Personally, I think it'd be rational for a user to
> expect
> > compatibility based on minor version families of our projects, e.g. that
> > each OGM 4.1.x release is compatible with each ORM 4.3.x release.
> >
> > As we can't guarantee this due to the rapid evolvement atm. (e.g. we add
> new
> > SPIs in ORM micro releases for the sake of OGM), some clear
> documentation is
> > highly desirable.
> >
> >> I think we should add an explanation on these on the website but I'm
> >> not sure where this would be more appropriate to present.
> >>
> >> Should we highlight compatible versions of other integration points on
> >> each sub section?
> >> For example I could edit the Search area to mention which versions of
> >> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
> >> different ones!), Commons Annotations, etc.. are supposed to work for
> >> each release.
> >
> >
> > Documenting the matching/required versions of upstream projects in each
> > project area may be one way. E.g. Search could document its requirements,
> > OGM its own etc. I don't think Search should document any expectations
> > towards OGM versions as the dependency is the other way around?
> >
> > Speaking in Maven terms, I still think that providing this information in
> > form of bill-of-materials POMs would be the approach most helpful to
> users.
> > Such project BOM would contain the versions of all its components and
> > dependencies. Users would reference this BOM using the "import" scope in
> > their dependency management configuration and thus get matching versions
> > when declaring a dependency to any of the artifacts listed in the BOM.
> >
> > I vaguely remember though that in the past there had been reservations
> > towards providing such BOMs?
> >
> > @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574 to
> do
> > this for OGM; Shall we give it a try?
> >
> > --Gunnar
> >
> >
> >>
> >> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
> >>
> >> -- Sanne
> >> _______________________________________________
> >> 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
>

From steve at hibernate.org  Mon Jul 14 10:45:20 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 14 Jul 2014 09:45:20 -0500
Subject: [hibernate-dev] Removal of method in ServiceRegistryBuilder
 broke JBoss Tools
In-Reply-To: <CAFm4XO3BdubybSr9yh+S4+d+K9D=ue4Tnv=43gma+b7PiYQL7g@mail.gmail.com>
References: <CAFm4XO3BdubybSr9yh+S4+d+K9D=ue4Tnv=43gma+b7PiYQL7g@mail.gmail.com>
Message-ID: <CAFdSV9voQjyj4-7=jvr26niVAdOWvdvBLvg0Jd5c_trZ4sRq0Q@mail.gmail.com>

Sure, that's fine.


On Sun, Jul 13, 2014 at 5:30 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Just noticed this post, a user unable to use Hibernate 4.3.5.Final
> with the Hibernate/JBoss Tools:
> https://forum.hibernate.org/viewtopic.php?f=6&t=1035330
>
> The method "buildServiceRegistry()" seems to have been renamed to
> "build()", but also the class was deprecated.
> Seems useful to just add the old method back, as a delegate to
> build().. may I do that?
>
> -- Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Jul 14 11:09:34 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 14 Jul 2014 16:09:34 +0100
Subject: [hibernate-dev] Removal of method in ServiceRegistryBuilder
 broke JBoss Tools
In-Reply-To: <CAFdSV9voQjyj4-7=jvr26niVAdOWvdvBLvg0Jd5c_trZ4sRq0Q@mail.gmail.com>
References: <CAFm4XO3BdubybSr9yh+S4+d+K9D=ue4Tnv=43gma+b7PiYQL7g@mail.gmail.com>
	<CAFdSV9voQjyj4-7=jvr26niVAdOWvdvBLvg0Jd5c_trZ4sRq0Q@mail.gmail.com>
Message-ID: <CAFm4XO2St5CMSL+-Xzm6Kf6Db8VzSjZfJDrmBhkbXssNO_Hedw@mail.gmail.com>

Done as HHH-9288, should be included in 4.3.6.Final

On 14 July 2014 15:45, Steve Ebersole <steve at hibernate.org> wrote:
> Sure, that's fine.
>
>
> On Sun, Jul 13, 2014 at 5:30 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Just noticed this post, a user unable to use Hibernate 4.3.5.Final
>> with the Hibernate/JBoss Tools:
>> https://forum.hibernate.org/viewtopic.php?f=6&t=1035330
>>
>> The method "buildServiceRegistry()" seems to have been renamed to
>> "build()", but also the class was deprecated.
>> Seems useful to just add the old method back, as a delegate to
>> build().. may I do that?
>>
>> -- Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From gunnar at hibernate.org  Tue Jul 15 04:10:33 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 15 Jul 2014 10:10:33 +0200
Subject: [hibernate-dev] Explaining versioning and dependency
	compatibility
In-Reply-To: <CAFm4XO0D0ud=bDaJb-dJEeb3ccymx8KbR6RgscDyQdwotK8E3Q@mail.gmail.com>
References: <CAFm4XO08YPe34Z=sZQc9yZTkPZSQauKUdhfAoND9kf2t1tnrnQ@mail.gmail.com>
	<CADGJaX9J4P5M-BJx0Vk-FWw2jfVDnKrN8wrhQFc8Nbs262Q=jQ@mail.gmail.com>
	<CAFm4XO2EYa+1_xJ-HXOT56N0d-XjnWV_DX8ED2PyQRN+io87OQ@mail.gmail.com>
	<CADGJaX8AHDjSiO3SidciuZtB1ZByZbR3pFT=kaANZvWxHR+vmg@mail.gmail.com>
	<CAFm4XO0D0ud=bDaJb-dJEeb3ccymx8KbR6RgscDyQdwotK8E3Q@mail.gmail.com>
Message-ID: <CADGJaX-ViDOw+_Gmg94dKHvBoLuX71dVUxoikhdZEy2ML3vK6w@mail.gmail.com>

2014-07-14 16:38 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 14 July 2014 15:23, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2014-07-14 12:54 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >
> >> Good point on OGM' s need for a specific micro. We could propose a 4.4
> >> series of ORM after you finish defining the integration point? So OGM
> >> x.Final will be able to depend on a more reasonable version range.
> >
> >
> > Yes, that'd be vey nice.
> >
> >>
> >> About BOM files, I'm just skeptical as I don't see how we should
> >> maintain and test them:
> >
> >
> > We'd maintain it in the same way as we maintain the dependencyManagement
> > block in our current POMs. Only that it's not part of the parent POM
> itself
> > but is extracted into a separate POM file. We'd import that BOM in our
> own
> > build and thus verify and test it.
> >
> > The significant difference would be that a user can do the same (import
> that
> > BOM) and thus get matching versions of our artifacts.
> >
> >>
> >> - would we update some separate BOM project at every release?
> >
> >
> > It would be just a module of each project, e.g. hibernate-ogm-bom, which
> > gets released as all the other modules.
> >
> >>
> >> - would you re-run the testsuite of each and all projects at every BOM
> >> update overriding the testsuite versions to make sure it's a valid
> >> combination? (how to automate?)
> >>
> >> - I'd also expect some integration tests to actually verify the
> >> correctness of the BOM file (e.g. syntax)
> >
> >
> > See above, as the BOM would be used in a project's build itself, it gets
> > verified.
>
> I don't understand how this would work. Let's take Search for example,
> so I'd maintain a BOM file in Hibernate Search, and release a new one
> at each of Search releases?
>

Yes.

You implicitly do the same also today by releasing your parent POM which
contains the versions of the required ORM etc. modules. Only that a user
cannot easily make use of those versions when declaring a dependency to ORM
or any of the Search dependencies themselves.


> That implies my BOM file is "the one for Hibernate Search version X",
> not for all projects together.
> This doesn't answer the question of users "which version of Hibernate
> Validator, Hibernate ORM, Hibernate Search work fine together? "
>

It depends on the perspective. It answers the question "Which is the right
version of ORM, if I want to work with release XYZ of Search?" What it does
not answer is "If I'm working with ORM version XYZ, which version of Search
do I need to add?".

Maybe the situation is also a bit different for Search and OGM. I guess
Search more often is added to projects which are using ORM already and thus
need to find out the matching Search version (unless they are willing to
switch to another ORM version and just take the latest Search). For OGM I'd
rather expect that users start with the latest version of OGM and are fine
with whatever ORM version this requires (at least until we truly support
polyglot scenarios, where again OGM may be added to an existing ORM
application).

So at least for OGM a BOM as I described it would be very helpful. E.g. the
user in the forum would have benefitted from it as he wouldn't have to
manually specify ORM versions but would get those declared in the OGM BOM.

As Hardy is saying, Validator has no version requirements in this context.

Let's say we release multiple BOM files. How do I use those in my
> project, which one do I use to define my version of ORM?
>

You'd have to use the one of the "most downstream" Hibernate project you're
using. E.g. when working with ORM and Search, the one from Search. When
working with ORM, Search and OGM, the one from OGM. BOMs can also include
other BOMs, so e.g. in the OGM BOM we could import the one from Search, so
we wouldn't have to re-declare versions for all Search components in OGM.


> As far as I know there is no such thing as "import the union of
> multiple BOMs, validating the intersection is consistent" in Maven.
>

Unfortunately that's true. I hoped the DependencyConvergence rule for the
enforcer plug-in would help, but this one only deals with resolved
dependencies and not things declared in <dependencyManagement>. So if a
user would import the Search *and* the OGM BOM (which they shouldn't),
there'd be a risk of inconsistencies (in this case the import declared
first takes precedence).

Nevertheless I feel that (at least for OGM) providing such BOM would be
beneficial to users.

Sanne
>

--Gunnar


>
>
>
> >
> >>
> >> Also the documented dependency ranges on the website could need some
> >> testing in a perfect world, but:
> >> a) I'd expect it to be simpler as it' s a smaller matrix if each
> >> project documents its own dependencies only
> >> b) each project somehow "is aware" if when it breaks compatibility
> >> with older dependencies, like you notice now with OGM: it's an
> >> explicit step you just have to remember to document (and rare enough
> >> so that I wouldn't bother too much to automate).
> >> c) *Personal opinion* I feel like a statement about *expected
> >> compatibility* does create a lower expectation in terms of accuracy
> >> than a BOM file, so that I wouldn't expect need for actual QA on this
> >> subject as much as I would expect it on BOM files which we would
> >> officially distribute.
> >
> >
> > Atm. we also specify which version of our dependencies we expect (in our
> > parent POMs). So this information is there, it's only very hard for
> users to
> > extract it if they want to add any of our dependencies themselves (they'd
> > have to look up the version we depend on to make sure they don't
> override it
> > with a non-compatible one). By giving users the BOMs for importing, this
> > information is much more conveniently accessible (and there is no risk
> for
> > it of getting out-dated as with a wiki/web site based approach).
> >>
> >>
> >> I'm not strictly against BOM but it sounds like taking a lot of our
> >> bandwidth for a minor practical improvement.
> >
> >
> > Maybe we have different things in mind?
> >
> > It's not a huge effort, actually I've just pushed a branch for this for
> OGM:
> >
> https://github.com/gunnarmorling/hibernate-ogm/compare/hibernate:master...gunnarmorling:OGM-574?expand=1
> >
> >> Ultimately we should be very aware that our modules are in constant
> >> change, and people mixing our latest are aware of a little bit of risk
> >> in using latest as there is a mismatch between our expectations vs our
> >> capacity to test and deliver a single unified platform, I think that's
> >> more something for assemblies such as WildFly, JBoss EAP, Spring, and
> >> whoever else redistributes our jars as a combination. We should be
> >> ready to provide recommendations (as what we expect to work) to the
> >> people making these distributions and our users but.. would you
> >> consider untested BOM files to be good for that?
> >
> >
> > They are not untested (at least in my model), as they are used for our
> own
> > build.
> >
> >> Sanne
> >
> >
> > --Gunnar
> >
> >>
> >> On 14 July 2014 11:21, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >
> >> >> I've been explaining $subject to a forum user [1]. I'm confident it's
> >> >> only a problem for newcomers, but are we expecting more expert
> >> >> developers to pass this lore by word of mouth?
> >> >
> >> >
> >> > Not so sure whether it's not a problem for expert users as well every
> >> > now
> >> > and then.
> >> >
> >> > Looking at OGM for instance, we're currently in the situation that we
> >> > depend
> >> > on a specific micro version of ORM (4.3.6 once it's out), which may
> be a
> >> > surprising fact. Personally, I think it'd be rational for a user to
> >> > expect
> >> > compatibility based on minor version families of our projects, e.g.
> that
> >> > each OGM 4.1.x release is compatible with each ORM 4.3.x release.
> >> >
> >> > As we can't guarantee this due to the rapid evolvement atm. (e.g. we
> add
> >> > new
> >> > SPIs in ORM micro releases for the sake of OGM), some clear
> >> > documentation is
> >> > highly desirable.
> >> >
> >> >> I think we should add an explanation on these on the website but I'm
> >> >> not sure where this would be more appropriate to present.
> >> >>
> >> >> Should we highlight compatible versions of other integration points
> on
> >> >> each sub section?
> >> >> For example I could edit the Search area to mention which versions of
> >> >> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
> >> >> different ones!), Commons Annotations, etc.. are supposed to work for
> >> >> each release.
> >> >
> >> >
> >> > Documenting the matching/required versions of upstream projects in
> each
> >> > project area may be one way. E.g. Search could document its
> >> > requirements,
> >> > OGM its own etc. I don't think Search should document any expectations
> >> > towards OGM versions as the dependency is the other way around?
> >> >
> >> > Speaking in Maven terms, I still think that providing this information
> >> > in
> >> > form of bill-of-materials POMs would be the approach most helpful to
> >> > users.
> >> > Such project BOM would contain the versions of all its components and
> >> > dependencies. Users would reference this BOM using the "import" scope
> in
> >> > their dependency management configuration and thus get matching
> versions
> >> > when declaring a dependency to any of the artifacts listed in the BOM.
> >> >
> >> > I vaguely remember though that in the past there had been reservations
> >> > towards providing such BOMs?
> >> >
> >> > @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574
> to
> >> > do
> >> > this for OGM; Shall we give it a try?
> >> >
> >> > --Gunnar
> >> >
> >> >
> >> >>
> >> >> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
> >> >>
> >> >> -- Sanne
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >
> >
>

From sanne at hibernate.org  Tue Jul 15 06:27:37 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 15 Jul 2014 11:27:37 +0100
Subject: [hibernate-dev] Explaining versioning and dependency
	compatibility
In-Reply-To: <CADGJaX-ViDOw+_Gmg94dKHvBoLuX71dVUxoikhdZEy2ML3vK6w@mail.gmail.com>
References: <CAFm4XO08YPe34Z=sZQc9yZTkPZSQauKUdhfAoND9kf2t1tnrnQ@mail.gmail.com>
	<CADGJaX9J4P5M-BJx0Vk-FWw2jfVDnKrN8wrhQFc8Nbs262Q=jQ@mail.gmail.com>
	<CAFm4XO2EYa+1_xJ-HXOT56N0d-XjnWV_DX8ED2PyQRN+io87OQ@mail.gmail.com>
	<CADGJaX8AHDjSiO3SidciuZtB1ZByZbR3pFT=kaANZvWxHR+vmg@mail.gmail.com>
	<CAFm4XO0D0ud=bDaJb-dJEeb3ccymx8KbR6RgscDyQdwotK8E3Q@mail.gmail.com>
	<CADGJaX-ViDOw+_Gmg94dKHvBoLuX71dVUxoikhdZEy2ML3vK6w@mail.gmail.com>
Message-ID: <CAFm4XO23k3K9C-Gw6BiQBD2uu-L23fYiN0-sntaqiRe=haM_mg@mail.gmail.com>

Interesting points. Indeed the need of users is different for the
Validator, Search, OGM examples, we might not be needing a "fits all"
solution.

So for OGM a BOM file might be useful. You should probably add all
other optional projects in there as well, that would resolve the
"intersections" problem.

For Validator, I don't understand why you all say there is no
dependency: it might be a wide range, but there is integration code in
ORM which has not always be there, and not always the same. I don't
expect Validator 3.x to work with latest ORM, and you should state
that somewhere.
On top of this, Validator has some shared dependencies with the other
modules; most of these are usually not a problem but there are
situations in which some combo might not work because of say a
breaking change int JBoss Logger or Commons Annotations.

Indeed for Search one might want to simply add some very basic
full-text search capability on an existing complex ORM application and
not wish to change ORM, or in a different case one wants to play with
the latest power features in the latest Search version. Depending on
the case one searches for compatibility for a specific version of ORM
or for a particular version of Search. I think it would be nice if
both project had some kind of informational box close to the version
details to list which "recommended" compatible version we suggest.

Even for OGM if we do BOM files, I would still like to see such an
information box on the website as not everyone is versed with Maven.


On 15 July 2014 09:10, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2014-07-14 16:38 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> On 14 July 2014 15:23, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > 2014-07-14 12:54 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >
>> >> Good point on OGM' s need for a specific micro. We could propose a 4.4
>> >> series of ORM after you finish defining the integration point? So OGM
>> >> x.Final will be able to depend on a more reasonable version range.
>> >
>> >
>> > Yes, that'd be vey nice.
>> >
>> >>
>> >> About BOM files, I'm just skeptical as I don't see how we should
>> >> maintain and test them:
>> >
>> >
>> > We'd maintain it in the same way as we maintain the dependencyManagement
>> > block in our current POMs. Only that it's not part of the parent POM
>> > itself
>> > but is extracted into a separate POM file. We'd import that BOM in our
>> > own
>> > build and thus verify and test it.
>> >
>> > The significant difference would be that a user can do the same (import
>> > that
>> > BOM) and thus get matching versions of our artifacts.
>> >
>> >>
>> >> - would we update some separate BOM project at every release?
>> >
>> >
>> > It would be just a module of each project, e.g. hibernate-ogm-bom, which
>> > gets released as all the other modules.
>> >
>> >>
>> >> - would you re-run the testsuite of each and all projects at every BOM
>> >> update overriding the testsuite versions to make sure it's a valid
>> >> combination? (how to automate?)
>> >>
>> >> - I'd also expect some integration tests to actually verify the
>> >> correctness of the BOM file (e.g. syntax)
>> >
>> >
>> > See above, as the BOM would be used in a project's build itself, it gets
>> > verified.
>>
>> I don't understand how this would work. Let's take Search for example,
>> so I'd maintain a BOM file in Hibernate Search, and release a new one
>> at each of Search releases?
>
>
> Yes.
>
> You implicitly do the same also today by releasing your parent POM which
> contains the versions of the required ORM etc. modules. Only that a user
> cannot easily make use of those versions when declaring a dependency to ORM
> or any of the Search dependencies themselves.
>
>>
>> That implies my BOM file is "the one for Hibernate Search version X",
>> not for all projects together.
>> This doesn't answer the question of users "which version of Hibernate
>> Validator, Hibernate ORM, Hibernate Search work fine together? "
>
>
> It depends on the perspective. It answers the question "Which is the right
> version of ORM, if I want to work with release XYZ of Search?" What it does
> not answer is "If I'm working with ORM version XYZ, which version of Search
> do I need to add?".
>
> Maybe the situation is also a bit different for Search and OGM. I guess
> Search more often is added to projects which are using ORM already and thus
> need to find out the matching Search version (unless they are willing to
> switch to another ORM version and just take the latest Search). For OGM I'd
> rather expect that users start with the latest version of OGM and are fine
> with whatever ORM version this requires (at least until we truly support
> polyglot scenarios, where again OGM may be added to an existing ORM
> application).
>
> So at least for OGM a BOM as I described it would be very helpful. E.g. the
> user in the forum would have benefitted from it as he wouldn't have to
> manually specify ORM versions but would get those declared in the OGM BOM.
>
> As Hardy is saying, Validator has no version requirements in this context.
>
>> Let's say we release multiple BOM files. How do I use those in my
>> project, which one do I use to define my version of ORM?
>
>
> You'd have to use the one of the "most downstream" Hibernate project you're
> using. E.g. when working with ORM and Search, the one from Search. When
> working with ORM, Search and OGM, the one from OGM. BOMs can also include
> other BOMs, so e.g. in the OGM BOM we could import the one from Search, so
> we wouldn't have to re-declare versions for all Search components in OGM.
>
>>
>> As far as I know there is no such thing as "import the union of
>> multiple BOMs, validating the intersection is consistent" in Maven.
>
>
> Unfortunately that's true. I hoped the DependencyConvergence rule for the
> enforcer plug-in would help, but this one only deals with resolved
> dependencies and not things declared in <dependencyManagement>. So if a user
> would import the Search *and* the OGM BOM (which they shouldn't), there'd be
> a risk of inconsistencies (in this case the import declared first takes
> precedence).
>
> Nevertheless I feel that (at least for OGM) providing such BOM would be
> beneficial to users.
>
>> Sanne
>
>
> --Gunnar
>
>>
>>
>>
>>
>> >
>> >>
>> >> Also the documented dependency ranges on the website could need some
>> >> testing in a perfect world, but:
>> >> a) I'd expect it to be simpler as it' s a smaller matrix if each
>> >> project documents its own dependencies only
>> >> b) each project somehow "is aware" if when it breaks compatibility
>> >> with older dependencies, like you notice now with OGM: it's an
>> >> explicit step you just have to remember to document (and rare enough
>> >> so that I wouldn't bother too much to automate).
>> >> c) *Personal opinion* I feel like a statement about *expected
>> >> compatibility* does create a lower expectation in terms of accuracy
>> >> than a BOM file, so that I wouldn't expect need for actual QA on this
>> >> subject as much as I would expect it on BOM files which we would
>> >> officially distribute.
>> >
>> >
>> > Atm. we also specify which version of our dependencies we expect (in our
>> > parent POMs). So this information is there, it's only very hard for
>> > users to
>> > extract it if they want to add any of our dependencies themselves
>> > (they'd
>> > have to look up the version we depend on to make sure they don't
>> > override it
>> > with a non-compatible one). By giving users the BOMs for importing, this
>> > information is much more conveniently accessible (and there is no risk
>> > for
>> > it of getting out-dated as with a wiki/web site based approach).
>> >>
>> >>
>> >> I'm not strictly against BOM but it sounds like taking a lot of our
>> >> bandwidth for a minor practical improvement.
>> >
>> >
>> > Maybe we have different things in mind?
>> >
>> > It's not a huge effort, actually I've just pushed a branch for this for
>> > OGM:
>> >
>> > https://github.com/gunnarmorling/hibernate-ogm/compare/hibernate:master...gunnarmorling:OGM-574?expand=1
>> >
>> >> Ultimately we should be very aware that our modules are in constant
>> >> change, and people mixing our latest are aware of a little bit of risk
>> >> in using latest as there is a mismatch between our expectations vs our
>> >> capacity to test and deliver a single unified platform, I think that's
>> >> more something for assemblies such as WildFly, JBoss EAP, Spring, and
>> >> whoever else redistributes our jars as a combination. We should be
>> >> ready to provide recommendations (as what we expect to work) to the
>> >> people making these distributions and our users but.. would you
>> >> consider untested BOM files to be good for that?
>> >
>> >
>> > They are not untested (at least in my model), as they are used for our
>> > own
>> > build.
>> >
>> >> Sanne
>> >
>> >
>> > --Gunnar
>> >
>> >>
>> >> On 14 July 2014 11:21, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >> > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >> >
>> >> >> I've been explaining $subject to a forum user [1]. I'm confident
>> >> >> it's
>> >> >> only a problem for newcomers, but are we expecting more expert
>> >> >> developers to pass this lore by word of mouth?
>> >> >
>> >> >
>> >> > Not so sure whether it's not a problem for expert users as well every
>> >> > now
>> >> > and then.
>> >> >
>> >> > Looking at OGM for instance, we're currently in the situation that we
>> >> > depend
>> >> > on a specific micro version of ORM (4.3.6 once it's out), which may
>> >> > be a
>> >> > surprising fact. Personally, I think it'd be rational for a user to
>> >> > expect
>> >> > compatibility based on minor version families of our projects, e.g.
>> >> > that
>> >> > each OGM 4.1.x release is compatible with each ORM 4.3.x release.
>> >> >
>> >> > As we can't guarantee this due to the rapid evolvement atm. (e.g. we
>> >> > add
>> >> > new
>> >> > SPIs in ORM micro releases for the sake of OGM), some clear
>> >> > documentation is
>> >> > highly desirable.
>> >> >
>> >> >> I think we should add an explanation on these on the website but I'm
>> >> >> not sure where this would be more appropriate to present.
>> >> >>
>> >> >> Should we highlight compatible versions of other integration points
>> >> >> on
>> >> >> each sub section?
>> >> >> For example I could edit the Search area to mention which versions
>> >> >> of
>> >> >> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
>> >> >> different ones!), Commons Annotations, etc.. are supposed to work
>> >> >> for
>> >> >> each release.
>> >> >
>> >> >
>> >> > Documenting the matching/required versions of upstream projects in
>> >> > each
>> >> > project area may be one way. E.g. Search could document its
>> >> > requirements,
>> >> > OGM its own etc. I don't think Search should document any
>> >> > expectations
>> >> > towards OGM versions as the dependency is the other way around?
>> >> >
>> >> > Speaking in Maven terms, I still think that providing this
>> >> > information
>> >> > in
>> >> > form of bill-of-materials POMs would be the approach most helpful to
>> >> > users.
>> >> > Such project BOM would contain the versions of all its components and
>> >> > dependencies. Users would reference this BOM using the "import" scope
>> >> > in
>> >> > their dependency management configuration and thus get matching
>> >> > versions
>> >> > when declaring a dependency to any of the artifacts listed in the
>> >> > BOM.
>> >> >
>> >> > I vaguely remember though that in the past there had been
>> >> > reservations
>> >> > towards providing such BOMs?
>> >> >
>> >> > @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574
>> >> > to
>> >> > do
>> >> > this for OGM; Shall we give it a try?
>> >> >
>> >> > --Gunnar
>> >> >
>> >> >
>> >> >>
>> >> >> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
>> >> >>
>> >> >> -- Sanne
>> >> >> _______________________________________________
>> >> >> hibernate-dev mailing list
>> >> >> hibernate-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >
>> >> >
>> >
>> >
>
>

From emmanuel at hibernate.org  Tue Jul 15 17:26:20 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 15 Jul 2014 23:26:20 +0200
Subject: [hibernate-dev] Explaining versioning and dependency
	compatibility
In-Reply-To: <CAFm4XO23k3K9C-Gw6BiQBD2uu-L23fYiN0-sntaqiRe=haM_mg@mail.gmail.com>
References: <CAFm4XO08YPe34Z=sZQc9yZTkPZSQauKUdhfAoND9kf2t1tnrnQ@mail.gmail.com>
	<CADGJaX9J4P5M-BJx0Vk-FWw2jfVDnKrN8wrhQFc8Nbs262Q=jQ@mail.gmail.com>
	<CAFm4XO2EYa+1_xJ-HXOT56N0d-XjnWV_DX8ED2PyQRN+io87OQ@mail.gmail.com>
	<CADGJaX8AHDjSiO3SidciuZtB1ZByZbR3pFT=kaANZvWxHR+vmg@mail.gmail.com>
	<CAFm4XO0D0ud=bDaJb-dJEeb3ccymx8KbR6RgscDyQdwotK8E3Q@mail.gmail.com>
	<CADGJaX-ViDOw+_Gmg94dKHvBoLuX71dVUxoikhdZEy2ML3vK6w@mail.gmail.com>
	<CAFm4XO23k3K9C-Gw6BiQBD2uu-L23fYiN0-sntaqiRe=haM_mg@mail.gmail.com>
Message-ID: <DD21D433-CC7D-44E5-8BC4-A27C5D3E7611@hibernate.org>


On 15 Jul 2014, at 12:27, Sanne Grinovero <sanne at hibernate.org> wrote:

> For Validator, I don't understand why you all say there is no
> dependency: it might be a wide range, but there is integration code in
> ORM which has not always be there, and not always the same. I don't
> expect Validator 3.x to work with latest ORM, and you should state
> that somewhere.

The shared dependencies might be problematic but I think ORM uses Bean Validation?s APIs only so we are very well isolated from Hibernate Validator per se.

> Indeed for Search one might want to simply add some very basic
> full-text search capability on an existing complex ORM application and
> not wish to change ORM, or in a different case one wants to play with
> the latest power features in the latest Search version. Depending on
> the case one searches for compatibility for a specific version of ORM
> or for a particular version of Search. I think it would be nice if
> both project had some kind of informational box close to the version
> details to list which "recommended" compatible version we suggest.

Remember we had that in the first wiki and that was a nightmare. I know I was the one maintaining it :)

> 
> Even for OGM if we do BOM files, I would still like to see such an
> information box on the website as not everyone is versed with Maven.

For OGM indeed it seems to be useful not only to list the other Hibernate project versions but also to show which version of which driver we test against.
Now that would break if we plan to support multiple versions of a driver or more likely embedded datastores like Noe4J and Infinispan that might break their APIs.
While we can create different modules, the BOM would be at a loss to express that.

Emmanuel



From emmanuel at hibernate.org  Wed Jul 16 03:51:06 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 16 Jul 2014 09:51:06 +0200
Subject: [hibernate-dev] Disable JIRA notifications for "edits"
Message-ID: <20140716075106.GC7229@hibernate.org>

Anyone knows a way to disable JIRA notification when someone edits an
entry or comment? This creates a lot of noise and is 99% of the time
either a minor typo or some wiki syntax fixes / improvements.

That would make my day.

From emmanuel at hibernate.org  Wed Jul 16 14:08:39 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 16 Jul 2014 20:08:39 +0200
Subject: [hibernate-dev] Disable JIRA notifications for "edits"
In-Reply-To: <20140716075106.GC7229@hibernate.org>
References: <20140716075106.GC7229@hibernate.org>
Message-ID: <96E7CE55-BBBF-4C6F-BBDB-DFDF136C9631@hibernate.org>

Anyone against me removing notifications when comments are edited ? Still a small subset but that's progress. 

> On 16 juil. 2014, at 09:51, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> Anyone knows a way to disable JIRA notification when someone edits an
> entry or comment? This creates a lot of noise and is 99% of the time
> either a minor typo or some wiki syntax fixes / improvements.
> 
> That would make my day.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Wed Jul 16 14:14:06 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 16 Jul 2014 19:14:06 +0100
Subject: [hibernate-dev] Disable JIRA notifications for "edits"
In-Reply-To: <96E7CE55-BBBF-4C6F-BBDB-DFDF136C9631@hibernate.org>
References: <20140716075106.GC7229@hibernate.org>
	<96E7CE55-BBBF-4C6F-BBDB-DFDF136C9631@hibernate.org>
Message-ID: <CAFm4XO2MKmFLTOWJjSy2oD6fj+xcrPnrpp2kq0tJLTK59HRygg@mail.gmail.com>

+1 to remove them.
Actually didn't we once had an option enabled to disable editing?

On 16 July 2014 19:08, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Anyone against me removing notifications when comments are edited ? Still a small subset but that's progress.
>
>> On 16 juil. 2014, at 09:51, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>
>> Anyone knows a way to disable JIRA notification when someone edits an
>> entry or comment? This creates a lot of noise and is 99% of the time
>> either a minor typo or some wiki syntax fixes / improvements.
>>
>> That would make my day.
>> _______________________________________________
>> 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

From jlesinge at gmail.com  Wed Jul 16 14:17:27 2014
From: jlesinge at gmail.com (John Worrell)
Date: Wed, 16 Jul 2014 19:17:27 +0100
Subject: [hibernate-dev] Contributing to OGM / Cassandra
Message-ID: <CAHAjH-PhStA5mPjsbDWp9Qxu9rxR+9GSKOXkhDK+A9XfR5w3uA@mail.gmail.com>

Hi,

I'm interested in contributing to the Cassandra module of Hibernate-OGM -
what would be the baest way to go about this?

Thanks,

John

From steve at hibernate.org  Wed Jul 16 14:35:42 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 16 Jul 2014 13:35:42 -0500
Subject: [hibernate-dev] Disable JIRA notifications for "edits"
In-Reply-To: <CAFm4XO2MKmFLTOWJjSy2oD6fj+xcrPnrpp2kq0tJLTK59HRygg@mail.gmail.com>
References: <20140716075106.GC7229@hibernate.org>
	<96E7CE55-BBBF-4C6F-BBDB-DFDF136C9631@hibernate.org>
	<CAFm4XO2MKmFLTOWJjSy2oD6fj+xcrPnrpp2kq0tJLTK59HRygg@mail.gmail.com>
Message-ID: <CAFdSV9u9W6HT21keryOJBc4HtU2yGjeu5ciauoV7U2GyLFBXdw@mail.gmail.com>

We limited who can edit which comments.

I'm ok with disabling that notifications for comment edits


On Wed, Jul 16, 2014 at 1:14 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> +1 to remove them.
> Actually didn't we once had an option enabled to disable editing?
>
> On 16 July 2014 19:08, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > Anyone against me removing notifications when comments are edited ?
> Still a small subset but that's progress.
> >
> >> On 16 juil. 2014, at 09:51, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >>
> >> Anyone knows a way to disable JIRA notification when someone edits an
> >> entry or comment? This creates a lot of noise and is 99% of the time
> >> either a minor typo or some wiki syntax fixes / improvements.
> >>
> >> That would make my day.
> >> _______________________________________________
> >> 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
>

From gunnar at hibernate.org  Thu Jul 17 02:57:07 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 17 Jul 2014 08:57:07 +0200
Subject: [hibernate-dev] Disable JIRA notifications for "edits"
In-Reply-To: <CAFdSV9u9W6HT21keryOJBc4HtU2yGjeu5ciauoV7U2GyLFBXdw@mail.gmail.com>
References: <20140716075106.GC7229@hibernate.org>
	<96E7CE55-BBBF-4C6F-BBDB-DFDF136C9631@hibernate.org>
	<CAFm4XO2MKmFLTOWJjSy2oD6fj+xcrPnrpp2kq0tJLTK59HRygg@mail.gmail.com>
	<CAFdSV9u9W6HT21keryOJBc4HtU2yGjeu5ciauoV7U2GyLFBXdw@mail.gmail.com>
Message-ID: <CADGJaX8eHVEkSB3J6-hungvLEyPCOtuEnd0GcofFjFYWFENZ+Q@mail.gmail.com>

I'm fine with disabling the notifications, but is it ensured that one still
gets notified if one is explicitly mentioned (@username ...)? I would not
like to miss those.


2014-07-16 20:35 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> We limited who can edit which comments.
>
> I'm ok with disabling that notifications for comment edits
>
>
> On Wed, Jul 16, 2014 at 1:14 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > +1 to remove them.
> > Actually didn't we once had an option enabled to disable editing?
> >
> > On 16 July 2014 19:08, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > > Anyone against me removing notifications when comments are edited ?
> > Still a small subset but that's progress.
> > >
> > >> On 16 juil. 2014, at 09:51, Emmanuel Bernard <emmanuel at hibernate.org>
> > wrote:
> > >>
> > >> Anyone knows a way to disable JIRA notification when someone edits an
> > >> entry or comment? This creates a lot of noise and is 99% of the time
> > >> either a minor typo or some wiki syntax fixes / improvements.
> > >>
> > >> That would make my day.
> > >> _______________________________________________
> > >> 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
>

From gbadner at redhat.com  Thu Jul 17 03:33:19 2014
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 17 Jul 2014 03:33:19 -0400 (EDT)
Subject: [hibernate-dev] Released 4.2.15.Final and 4.3.6.Final
In-Reply-To: <1282259584.20485379.1405582218636.JavaMail.zimbra@redhat.com>
Message-ID: <624248073.20487002.1405582399938.JavaMail.zimbra@redhat.com>

I've finished the releases. Everything went fine except I had trouble with uploading the documentation (via ./gradlew :release:uploadDocumentation).

I'll upload the docs, blog, and finish announcements tomorrow.

Regards,
Gail

From steve at hibernate.org  Thu Jul 17 08:11:19 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 17 Jul 2014 07:11:19 -0500
Subject: [hibernate-dev] Released 4.2.15.Final and 4.3.6.Final
In-Reply-To: <624248073.20487002.1405582399938.JavaMail.zimbra@redhat.com>
References: <1282259584.20485379.1405582218636.JavaMail.zimbra@redhat.com>
	<624248073.20487002.1405582399938.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9v9T-bvGG2+HHq+Gk5eCrQU7QvucWLEm4QWY_43BAKC5g@mail.gmail.com>

What went wrong with uploadDocumentation task?


On Thu, Jul 17, 2014 at 2:33 AM, Gail Badner <gbadner at redhat.com> wrote:

> I've finished the releases. Everything went fine except I had trouble with
> uploading the documentation (via ./gradlew :release:uploadDocumentation).
>
> I'll upload the docs, blog, and finish announcements tomorrow.
>
> Regards,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Thu Jul 17 08:59:20 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 17 Jul 2014 14:59:20 +0200
Subject: [hibernate-dev] [OGM-441] Pull request workflow in JIRA
Message-ID: <7465D22B-3F41-40F7-913E-4D902DD671D8@hibernate.org>

Hibernate Search has a pull request workflow where a specific status Pull Request Sent exists.
Do we want it for OGM? Do you think it would add more value to the clutter it brings?

That question is mostly for Gunnar and Davide. I am neutral personally.

Sanne what?s your feedback after using it in HSearch?

Emmanuel

From emmanuel at hibernate.org  Thu Jul 17 09:04:59 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 17 Jul 2014 15:04:59 +0200
Subject: [hibernate-dev] Disable JIRA notifications for "edits"
In-Reply-To: <96E7CE55-BBBF-4C6F-BBDB-DFDF136C9631@hibernate.org>
References: <20140716075106.GC7229@hibernate.org>
	<96E7CE55-BBBF-4C6F-BBDB-DFDF136C9631@hibernate.org>
Message-ID: <108FFF5D-37E2-40E8-8AC9-38C624B2C2C0@hibernate.org>

Done.

On 16 Jul 2014, at 20:08, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> Anyone against me removing notifications when comments are edited ? Still a small subset but that's progress. 
> 
>> On 16 juil. 2014, at 09:51, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> 
>> Anyone knows a way to disable JIRA notification when someone edits an
>> entry or comment? This creates a lot of noise and is 99% of the time
>> either a minor typo or some wiki syntax fixes / improvements.
>> 
>> That would make my day.
>> _______________________________________________
>> 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



From sanne at hibernate.org  Thu Jul 17 09:17:15 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 17 Jul 2014 14:17:15 +0100
Subject: [hibernate-dev] [OGM-441] Pull request workflow in JIRA
In-Reply-To: <7465D22B-3F41-40F7-913E-4D902DD671D8@hibernate.org>
References: <7465D22B-3F41-40F7-913E-4D902DD671D8@hibernate.org>
Message-ID: <CAFm4XO2e5At5kfXLRhDZSfLUK-ON0dRj78U_nxekhfSZONMa8A@mail.gmail.com>

On 17 July 2014 13:59, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Hibernate Search has a pull request workflow where a specific status Pull Request Sent exists.
> Do we want it for OGM? Do you think it would add more value to the clutter it brings?
>
> That question is mostly for Gunnar and Davide. I am neutral personally.
>
> Sanne what?s your feedback after using it in HSearch?

Personally I like it as it's good to be able to track the current
state of release progress; I use filters to plan releases and that
gives a quick visibility sorting by issue status.

The link is useful but not essential; apparently JIRA is now supposed
to automatically create the links but it seems not perfect yet, I'm
not understanding why it sometimes auto-links and sometimes there's
nothing. Ideally if that improves I'd be happy with a status change,
*especially* as all of this can eventually be scripted in a REST based
script to send PRs and all status updates in one go (both github and
JIRA have nice REST APIs).

Also JIRA tends to flag the PR as "rejected" when you merge & close it
after rebasing. I guess that's not going to be fixed easily so we need
to help it somehow.

Sanne

>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From gunnar at hibernate.org  Thu Jul 17 11:53:00 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 17 Jul 2014 17:53:00 +0200
Subject: [hibernate-dev] [OGM-441] Pull request workflow in JIRA
In-Reply-To: <CAFm4XO2e5At5kfXLRhDZSfLUK-ON0dRj78U_nxekhfSZONMa8A@mail.gmail.com>
References: <7465D22B-3F41-40F7-913E-4D902DD671D8@hibernate.org>
	<CAFm4XO2e5At5kfXLRhDZSfLUK-ON0dRj78U_nxekhfSZONMa8A@mail.gmail.com>
Message-ID: <CADGJaX9ULprFnQwSJFiQcW2mNXFzQ1r7y0xjWbFvVKEhghLh8w@mail.gmail.com>

I've no strong opinion, both ways work for me.

At least I haven't missed the feature so far, and as Sanne is saying, pull
requests are referenced automatically now anyways. Is there any strong
advantage of using that workflow?


Am 17.07.2014 15:18 schrieb "Sanne Grinovero" <sanne at hibernate.org>:
>
> On 17 July 2014 13:59, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > Hibernate Search has a pull request workflow where a specific status
Pull Request Sent exists.
> > Do we want it for OGM? Do you think it would add more value to the
clutter it brings?
> >
> > That question is mostly for Gunnar and Davide. I am neutral personally.
> >
> > Sanne what?s your feedback after using it in HSearch?
>
> Personally I like it as it's good to be able to track the current
> state of release progress; I use filters to plan releases and that
> gives a quick visibility sorting by issue status.
>
> The link is useful but not essential; apparently JIRA is now supposed
> to automatically create the links but it seems not perfect yet, I'm
> not understanding why it sometimes auto-links and sometimes there's
> nothing. Ideally if that improves I'd be happy with a status change,
> *especially* as all of this can eventually be scripted in a REST based
> script to send PRs and all status updates in one go (both github and
> JIRA have nice REST APIs).
>
> Also JIRA tends to flag the PR as "rejected" when you merge & close it
> after rebasing. I guess that's not going to be fixed easily so we need
> to help it somehow.
>
> Sanne
>
> >
> > Emmanuel
> > _______________________________________________
> > 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

From sanne at hibernate.org  Thu Jul 17 12:15:24 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 17 Jul 2014 17:15:24 +0100
Subject: [hibernate-dev] [OGM-441] Pull request workflow in JIRA
In-Reply-To: <CADGJaX9ULprFnQwSJFiQcW2mNXFzQ1r7y0xjWbFvVKEhghLh8w@mail.gmail.com>
References: <7465D22B-3F41-40F7-913E-4D902DD671D8@hibernate.org>
	<CAFm4XO2e5At5kfXLRhDZSfLUK-ON0dRj78U_nxekhfSZONMa8A@mail.gmail.com>
	<CADGJaX9ULprFnQwSJFiQcW2mNXFzQ1r7y0xjWbFvVKEhghLh8w@mail.gmail.com>
Message-ID: <CAFm4XO392zbiBiXVmk6M931kzqXHwehNsm2T7LL=P0ykD5kZ3A@mail.gmail.com>

On 17 July 2014 16:53, Gunnar Morling <gunnar at hibernate.org> wrote:
> I've no strong opinion, both ways work for me.
>
> At least I haven't missed the feature so far, and as Sanne is saying, pull
> requests are referenced automatically now anyways. Is there any strong
> advantage of using that workflow?

No it's not going to solve the world's problems.

I listed why I like it, and how I minimize the hassle. And as a I
said, PRs are not consistently tracked.

But the benefits of traceability which I listed are used only
occasionally, and the "status overview" is used only by a a few of us
and I could use labels or just a status without link to achieve
similar benefits.

The question is if the small burden paid by everyone are a reasonable
cost for the benefits of the few.

I have no strong opinion either.

>
>
> Am 17.07.2014 15:18 schrieb "Sanne Grinovero" <sanne at hibernate.org>:
>
>
>>
>> On 17 July 2014 13:59, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> > Hibernate Search has a pull request workflow where a specific status
>> > Pull Request Sent exists.
>> > Do we want it for OGM? Do you think it would add more value to the
>> > clutter it brings?
>> >
>> > That question is mostly for Gunnar and Davide. I am neutral personally.
>> >
>> > Sanne what?s your feedback after using it in HSearch?
>>
>> Personally I like it as it's good to be able to track the current
>> state of release progress; I use filters to plan releases and that
>> gives a quick visibility sorting by issue status.
>>
>> The link is useful but not essential; apparently JIRA is now supposed
>> to automatically create the links but it seems not perfect yet, I'm
>> not understanding why it sometimes auto-links and sometimes there's
>> nothing. Ideally if that improves I'd be happy with a status change,
>> *especially* as all of this can eventually be scripted in a REST based
>> script to send PRs and all status updates in one go (both github and
>> JIRA have nice REST APIs).
>>
>> Also JIRA tends to flag the PR as "rejected" when you merge & close it
>> after rebasing. I guess that's not going to be fixed easily so we need
>> to help it somehow.
>>
>> Sanne
>>
>> >
>> > Emmanuel
>> > _______________________________________________
>> > 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


From gbadner at redhat.com  Thu Jul 17 17:58:22 2014
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 17 Jul 2014 17:58:22 -0400 (EDT)
Subject: [hibernate-dev] Released 4.2.15.Final and 4.3.6.Final
In-Reply-To: <CAFdSV9v9T-bvGG2+HHq+Gk5eCrQU7QvucWLEm4QWY_43BAKC5g@mail.gmail.com>
References: <1282259584.20485379.1405582218636.JavaMail.zimbra@redhat.com>
	<624248073.20487002.1405582399938.JavaMail.zimbra@redhat.com>
	<CAFdSV9v9T-bvGG2+HHq+Gk5eCrQU7QvucWLEm4QWY_43BAKC5g@mail.gmail.com>
Message-ID: <1763282792.21049051.1405634302321.JavaMail.zimbra@redhat.com>

For some reason, I couldn't upload the documentation using gradle. I was able to upload them manually as described here. [1]

No idea why it would make a difference though.

[1] https://community.jboss.org/wiki/ReleasingHibernateCore#docs

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Thursday, July 17, 2014 5:11:19 AM
> Subject: Re: [hibernate-dev] Released 4.2.15.Final and 4.3.6.Final
> 
> What went wrong with uploadDocumentation task?
> 
> 
> On Thu, Jul 17, 2014 at 2:33 AM, Gail Badner <gbadner at redhat.com> wrote:
> 
> > I've finished the releases. Everything went fine except I had trouble with
> > uploading the documentation (via ./gradlew :release:uploadDocumentation).
> >
> > I'll upload the docs, blog, and finish announcements tomorrow.
> >
> > Regards,
> > Gail
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 

From gbadner at redhat.com  Thu Jul 17 20:48:29 2014
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 17 Jul 2014 20:48:29 -0400 (EDT)
Subject: [hibernate-dev] Hibernate ORM 4.3.6.Final and 4.2.15.Final Released
In-Reply-To: <290889052.21102067.1405644475559.JavaMail.zimbra@redhat.com>
Message-ID: <131581881.21102198.1405644509078.JavaMail.zimbra@redhat.com>

For details, please see http://in.relation.to/Bloggers/HibernateORM436FinalAnd4215FinalReleased .

Gail Badner
Red Hat, Hibernate ORM

From m.schipperheyn at gmail.com  Sat Jul 19 12:41:57 2014
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Sat, 19 Jul 2014 13:41:57 -0300
Subject: [hibernate-dev] Hibernate Search Alpha/Beta
Message-ID: <CAGvEgx4jNBAwtLardMqWzDTGUtghSwf-AZ+grqVQfH+WgPkBcw@mail.gmail.com>

I'm eagerly awaiting Hibernate Search 5 but recently all the progress seems
to be contextual (testsuites/updating dependencies/etc). Should a due date
be put on alpha 5? The Hibernate team has always been excellent at meeting
deadlines. Or is this a holidays lull?

From sanne at hibernate.org  Sat Jul 19 14:43:47 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 19 Jul 2014 19:43:47 +0100
Subject: [hibernate-dev] Hibernate Search Alpha/Beta
In-Reply-To: <CAGvEgx4jNBAwtLardMqWzDTGUtghSwf-AZ+grqVQfH+WgPkBcw@mail.gmail.com>
References: <CAGvEgx4jNBAwtLardMqWzDTGUtghSwf-AZ+grqVQfH+WgPkBcw@mail.gmail.com>
Message-ID: <CAFm4XO3VmVRsVxsYo_vhcWFfY7eq4-UQseAgg-kPgipb658J2g@mail.gmail.com>

Hi Marc,
I'm planning an Alpha5 for next week. The more interesting feature
changes are not being merged yet as there still is some research and
experimentation being done.

Sanne

On 19 July 2014 17:41, Marc Schipperheyn <m.schipperheyn at gmail.com> wrote:
> I'm eagerly awaiting Hibernate Search 5 but recently all the progress seems
> to be contextual (testsuites/updating dependencies/etc). Should a due date
> be put on alpha 5? The Hibernate team has always been excellent at meeting
> deadlines. Or is this a holidays lull?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at hibernate.org  Sun Jul 20 05:08:16 2014
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Sun, 20 Jul 2014 11:08:16 +0200
Subject: [hibernate-dev] Search - HSEARCH-1580 - Dependency graph
Message-ID: <CALt0+o8dXJYwKfk8mGwS=9-3bmn1CWvbaV6j771PyYnYcLCUTw@mail.gmail.com>

Hi,

Following the discussion about releasing 5 sooner rather than later, I
wanted to point out that we still have to take a decision about
HSEARCH-1580:
- either commit in 5 the fix we committed to 4.x and update the documentation;
- or work on defining another concept.

I don't have a strong opinion about what we should do but I have a
strong one about doing something before we release 5 :).

References:
https://hibernate.atlassian.net/browse/HSEARCH-1580
https://hibernate.atlassian.net/browse/HSEARCH-1573

Feedback welcome.

(sorry for the long silence - busy months...)

-- 
Guillaume

From emmanuel at hibernate.org  Mon Jul 21 08:06:04 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 21 Jul 2014 07:06:04 -0500
Subject: [hibernate-dev] Contributing to OGM / Cassandra
In-Reply-To: <CAHAjH-PhStA5mPjsbDWp9Qxu9rxR+9GSKOXkhDK+A9XfR5w3uA@mail.gmail.com>
References: <CAHAjH-PhStA5mPjsbDWp9Qxu9rxR+9GSKOXkhDK+A9XfR5w3uA@mail.gmail.com>
Message-ID: <6B5FA68A-59CD-4CAD-81EB-3AC2CCBBE55C@hibernate.org>

Hi John,

I thought I had replied to you on Friday but apparently the email never went through :/

That is good news :)
Jonathan worked on a Cassandra prototype but had to drop due to other duties. He pushed everything at
https://github.com/jhalliday/hibernate-ogm/tree/jonathan_cassandra

Have a look at what he has done and come ask any question to Gunnar, Davide or me. There are a bunch of moving pieces. We are mostly on freenode?s #hibernate-dev ( you need a freenode login http://freenode.net/faq.shtml#nicksetup ). If you are allergic to IRC, let me know and we will find alternatives.

The most interesting challenge will be to see how we can map time series into a collection and make sure we let the user decide how much he wants to load.

Emmanuel

On 16 Jul 2014, at 13:17, John Worrell <jlesinge at gmail.com> wrote:

> Hi,
> 
> I'm interested in contributing to the Cassandra module of Hibernate-OGM -
> what would be the baest way to go about this?
> 
> Thanks,
> 
> John
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From jlesinge at gmail.com  Mon Jul 21 11:48:33 2014
From: jlesinge at gmail.com (John Worrell)
Date: Mon, 21 Jul 2014 16:48:33 +0100
Subject: [hibernate-dev] Contributing to OGM / Cassandra
In-Reply-To: <6B5FA68A-59CD-4CAD-81EB-3AC2CCBBE55C@hibernate.org>
References: <CAHAjH-PhStA5mPjsbDWp9Qxu9rxR+9GSKOXkhDK+A9XfR5w3uA@mail.gmail.com>
	<6B5FA68A-59CD-4CAD-81EB-3AC2CCBBE55C@hibernate.org>
Message-ID: <CAHAjH-NcZMLYFRGEPrJu21FF4qEXkNqu+GdY=Tq1_nXCr46hFA@mail.gmail.com>

Hi Emmanuel,

I'll take a look at what is there, and I'll get up and running on IRC.

I'll particularly look at the time-series issue - non-trivial I think.

Cheers,

John


On Mon, Jul 21, 2014 at 1:06 PM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Hi John,
>
> I thought I had replied to you on Friday but apparently the email never
> went through :/
>
> That is good news :)
> Jonathan worked on a Cassandra prototype but had to drop due to other
> duties. He pushed everything at
> https://github.com/jhalliday/hibernate-ogm/tree/jonathan_cassandra
>
> Have a look at what he has done and come ask any question to Gunnar,
> Davide or me. There are a bunch of moving pieces. We are mostly on
> freenode?s #hibernate-dev ( you need a freenode login
> http://freenode.net/faq.shtml#nicksetup ). If you are allergic to IRC,
> let me know and we will find alternatives.
>
> The most interesting challenge will be to see how we can map time series
> into a collection and make sure we let the user decide how much he wants to
> load.
>
> Emmanuel
>
> On 16 Jul 2014, at 13:17, John Worrell <jlesinge at gmail.com> wrote:
>
> > Hi,
> >
> > I'm interested in contributing to the Cassandra module of Hibernate-OGM -
> > what would be the baest way to go about this?
> >
> > Thanks,
> >
> > John
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From sanne at hibernate.org  Wed Jul 23 12:00:24 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 23 Jul 2014 17:00:24 +0100
Subject: [hibernate-dev] Released Hibernate Search 5.0.0.Alpha5
Message-ID: <CAFm4XO3t0a=Y6ceB35UUs2_mUwctsezY2fBtnYrnfwra=TdrFw@mail.gmail.com>

Another milestone towards the Hibernate Search 5 release!

http://in.relation.to/Bloggers/AnotherMilestoneHibernateSearch500Alpha5

 -- Sanne

From guillaume.smet at gmail.com  Fri Jul 25 15:59:43 2014
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 25 Jul 2014 21:59:43 +0200
Subject: [hibernate-dev] Search - HSEARCH-1580 - Dependency graph
In-Reply-To: <68C8A0F4-69D1-4C07-B8B7-147813F3EC51@hibernate.org>
References: <CALt0+o8dXJYwKfk8mGwS=9-3bmn1CWvbaV6j771PyYnYcLCUTw@mail.gmail.com>
	<68C8A0F4-69D1-4C07-B8B7-147813F3EC51@hibernate.org>
Message-ID: <CALt0+o9kxATDTPBe7ROT-1=k7pZay_vaBj4_gOmxLQ=H6iTRPw@mail.gmail.com>

Hi Hardy,

Thanks for your feedback. I'll see what I can do next week about it.

-- 
Guillaume

On Fri, Jul 25, 2014 at 9:12 PM, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> took a while to respond, but I  tend to agree that @ContainedIn would be good enough.
> I don?t think a new annotation would make things clearer. As discussed before, the main
> issue was that the original intention was that @ContainedIn always requires an @IndexedEmbedded.
> It just happened to work also without and during the refactoring the behaviour was changed to
> match the original intentions.
>
> The important thing is to make sure that the documentation and javadocs are documenting the
> behaviour properly and consistently.
>
> So +1 for getting the old behaviour back
>
> ?Hardy
>
>
>
>
>
> On 20 Jan 2014, at 11:08, Guillaume Smet <guillaume.smet at hibernate.org> wrote:
>
>> Hi,
>>
>> Following the discussion about releasing 5 sooner rather than later, I
>> wanted to point out that we still have to take a decision about
>> HSEARCH-1580:
>> - either commit in 5 the fix we committed to 4.x and update the documentation;
>> - or work on defining another concept.
>>
>> I don't have a strong opinion about what we should do but I have a
>> strong one about doing something before we release 5 :).
>>
>> References:
>> https://hibernate.atlassian.net/browse/HSEARCH-1580
>> https://hibernate.atlassian.net/browse/HSEARCH-1573
>>
>> Feedback welcome.
>>
>> (sorry for the long silence - busy months...)
>>
>> --
>> Guillaume
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From gunnar at hibernate.org  Mon Jul 28 02:36:32 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 28 Jul 2014 08:36:32 +0200
Subject: [hibernate-dev] Adding support for Java 8's Optional to ORM
Message-ID: <CADGJaX-FT3_eWDnMidHZgdfEvUWzH8DPxn8zeL94d6zb3q0J1g@mail.gmail.com>

Hi,

Java 8 introduced a new type Optional which may be used to represent
objects which may be set or not set:

    private Optional<String> name;

Hibernate Validator will allow to validate properties of this type in the
next release. Now someone brought up the question whether the same is
planned for ORM, so one can use Optional in entity properties.

Any thoughts?

Thanks,

--Gunnar

From sanne at hibernate.org  Mon Jul 28 05:48:45 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 28 Jul 2014 10:48:45 +0100
Subject: [hibernate-dev] Adding support for Java 8's Optional to ORM
In-Reply-To: <CADGJaX-FT3_eWDnMidHZgdfEvUWzH8DPxn8zeL94d6zb3q0J1g@mail.gmail.com>
References: <CADGJaX-FT3_eWDnMidHZgdfEvUWzH8DPxn8zeL94d6zb3q0J1g@mail.gmail.com>
Message-ID: <CAFm4XO3EPSO8ViVRSQ=HF2o7y_L8nm2fjB5pzRf0yf-_kxAsmA@mail.gmail.com>

We'd also love to support some features (especially the new user types
such as Date/Time) in Hibernate Search.

I don't think we should require Java8 for all users though, so I'd
like this to be an independent module.. troublesome with Maven though,
so this wasn't done yet.

--Sanne

On 28 July 2014 07:36, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> Java 8 introduced a new type Optional which may be used to represent
> objects which may be set or not set:
>
>     private Optional<String> name;
>
> Hibernate Validator will allow to validate properties of this type in the
> next release. Now someone brought up the question whether the same is
> planned for ORM, so one can use Optional in entity properties.
>
> Any thoughts?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Mon Jul 28 05:54:04 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 28 Jul 2014 11:54:04 +0200
Subject: [hibernate-dev] Adding support for Java 8's Optional to ORM
In-Reply-To: <CAFm4XO3EPSO8ViVRSQ=HF2o7y_L8nm2fjB5pzRf0yf-_kxAsmA@mail.gmail.com>
References: <CADGJaX-FT3_eWDnMidHZgdfEvUWzH8DPxn8zeL94d6zb3q0J1g@mail.gmail.com>
	<CAFm4XO3EPSO8ViVRSQ=HF2o7y_L8nm2fjB5pzRf0yf-_kxAsmA@mail.gmail.com>
Message-ID: <CADGJaX82Q8E1cGh87hzo8QzCadekgCzaVBB-YVL=qGkzEaoFQA@mail.gmail.com>

2014-07-28 11:48 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> We'd also love to support some features (especially the new user types
> such as Date/Time) in Hibernate Search.
>

Ah, right. I've heard requests about the 310 date/time types as well.

>
> I don't think we should require Java8 for all users though, so I'd
> like this to be an independent module.. troublesome with Maven though,
> so this wasn't done yet.
>

Yes, it should definitely be optional.

I think it depends on the specific case how easy or hard this will be to
achieve. If it's something rather isolated such as a specific user type
it's easy, but in other cases it's more painful (e.g. marking annotation
types as repeatable cannot really be done in a backwards-compatible manner,
so it needs effectively two variants of such an annotation).

--Sanne
>
> On 28 July 2014 07:36, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hi,
> >
> > Java 8 introduced a new type Optional which may be used to represent
> > objects which may be set or not set:
> >
> >     private Optional<String> name;
> >
> > Hibernate Validator will allow to validate properties of this type in the
> > next release. Now someone brought up the question whether the same is
> > planned for ORM, so one can use Optional in entity properties.
> >
> > Any thoughts?
> >
> > Thanks,
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jul 29 10:28:23 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 29 Jul 2014 09:28:23 -0500
Subject: [hibernate-dev] Adding support for Java 8's Optional to ORM
In-Reply-To: <CADGJaX82Q8E1cGh87hzo8QzCadekgCzaVBB-YVL=qGkzEaoFQA@mail.gmail.com>
References: <CADGJaX-FT3_eWDnMidHZgdfEvUWzH8DPxn8zeL94d6zb3q0J1g@mail.gmail.com>
	<CAFm4XO3EPSO8ViVRSQ=HF2o7y_L8nm2fjB5pzRf0yf-_kxAsmA@mail.gmail.com>
	<CADGJaX82Q8E1cGh87hzo8QzCadekgCzaVBB-YVL=qGkzEaoFQA@mail.gmail.com>
Message-ID: <CAFdSV9ui+G8mi=Y2z1oJt3CXbjf-KeD1oOayzpreMe4bZ=uWXw@mail.gmail.com>

Making stuff like this optional in 4.x is difficult though because it needs
to tie into the metamodel resolution.  Today that process is very
closed-off and static.


On Mon, Jul 28, 2014 at 4:54 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> 2014-07-28 11:48 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
> > We'd also love to support some features (especially the new user types
> > such as Date/Time) in Hibernate Search.
> >
>
> Ah, right. I've heard requests about the 310 date/time types as well.
>
> >
> > I don't think we should require Java8 for all users though, so I'd
> > like this to be an independent module.. troublesome with Maven though,
> > so this wasn't done yet.
> >
>
> Yes, it should definitely be optional.
>
> I think it depends on the specific case how easy or hard this will be to
> achieve. If it's something rather isolated such as a specific user type
> it's easy, but in other cases it's more painful (e.g. marking annotation
> types as repeatable cannot really be done in a backwards-compatible manner,
> so it needs effectively two variants of such an annotation).
>
> --Sanne
> >
> > On 28 July 2014 07:36, Gunnar Morling <gunnar at hibernate.org> wrote:
> > > Hi,
> > >
> > > Java 8 introduced a new type Optional which may be used to represent
> > > objects which may be set or not set:
> > >
> > >     private Optional<String> name;
> > >
> > > Hibernate Validator will allow to validate properties of this type in
> the
> > > next release. Now someone brought up the question whether the same is
> > > planned for ORM, so one can use Optional in entity properties.
> > >
> > > Any thoughts?
> > >
> > > Thanks,
> > >
> > > --Gunnar
> > > _______________________________________________
> > > 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
>

From steve at hibernate.org  Tue Jul 29 13:16:38 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 29 Jul 2014 12:16:38 -0500
Subject: [hibernate-dev] IRC Developer Meeting - 7/29
Message-ID: <CAFdSV9txQjATxzpJe-Q_CNo=4uyKYkg=cybHNjtx1_t0CS41bQ@mail.gmail.com>

Mainly discussed the ongoing JdbcSession work.

[10:44] <jbott> Meeting ended Tue Jul 29 15:44:14 2014 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
[10:44] <jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-29-15.07.html
[10:44] <jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-29-15.07.txt
[10:44] <jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-29-15.07.log.html

From sanne at hibernate.org  Wed Jul 30 07:53:01 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 30 Jul 2014 12:53:01 +0100
Subject: [hibernate-dev] HHH-8839
Message-ID: <CAFm4XO2_mdsz+JV4ct18n6=y7LRYzOusre9wnFBdG5d0YB8Pag@mail.gmail.com>

Hi Steve,
I promised the below forum users to get your attention on this issue,
and there seem to be many votes. May I optimistically mark it for the
next minor?

There is a test as well.

https://forum.hibernate.org/viewtopic.php?f=1&t=1035834

https://hibernate.atlassian.net/browse/HHH-8839

Cheers,
Sanne

From gbadner at redhat.com  Thu Jul 31 02:04:03 2014
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 31 Jul 2014 02:04:03 -0400 (EDT)
Subject: [hibernate-dev] HHH-8839
In-Reply-To: <CAFm4XO2_mdsz+JV4ct18n6=y7LRYzOusre9wnFBdG5d0YB8Pag@mail.gmail.com>
References: <CAFm4XO2_mdsz+JV4ct18n6=y7LRYzOusre9wnFBdG5d0YB8Pag@mail.gmail.com>
Message-ID: <1087515327.29296579.1406786643580.JavaMail.zimbra@redhat.com>

I've set the fix versions to 5.0.0 and 4.3.7.

I'll take a look when I have a chance.

Thanks,
Gail

----- Original Message -----
> From: "Sanne Grinovero" <sanne at hibernate.org>
> To: "Steve Ebersole" <steve at hibernate.org>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Wednesday, July 30, 2014 4:53:01 AM
> Subject: [hibernate-dev] HHH-8839
> 
> Hi Steve,
> I promised the below forum users to get your attention on this issue,
> and there seem to be many votes. May I optimistically mark it for the
> next minor?
> 
> There is a test as well.
> 
> https://forum.hibernate.org/viewtopic.php?f=1&t=1035834
> 
> https://hibernate.atlassian.net/browse/HHH-8839
> 
> Cheers,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From sanne at hibernate.org  Thu Jul 31 04:23:32 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 31 Jul 2014 09:23:32 +0100
Subject: [hibernate-dev] HHH-8839
In-Reply-To: <1087515327.29296579.1406786643580.JavaMail.zimbra@redhat.com>
References: <CAFm4XO2_mdsz+JV4ct18n6=y7LRYzOusre9wnFBdG5d0YB8Pag@mail.gmail.com>
	<1087515327.29296579.1406786643580.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO0of4YT3Q5otYy5LuchQJjhYzPa9V5O+O5MDWeBum84zA@mail.gmail.com>

Thanks Gail!

On 31 July 2014 07:04, Gail Badner <gbadner at redhat.com> wrote:
> I've set the fix versions to 5.0.0 and 4.3.7.
>
> I'll take a look when I have a chance.
>
> Thanks,
> Gail
>
> ----- Original Message -----
>> From: "Sanne Grinovero" <sanne at hibernate.org>
>> To: "Steve Ebersole" <steve at hibernate.org>
>> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
>> Sent: Wednesday, July 30, 2014 4:53:01 AM
>> Subject: [hibernate-dev] HHH-8839
>>
>> Hi Steve,
>> I promised the below forum users to get your attention on this issue,
>> and there seem to be many votes. May I optimistically mark it for the
>> next minor?
>>
>> There is a test as well.
>>
>> https://forum.hibernate.org/viewtopic.php?f=1&t=1035834
>>
>> https://hibernate.atlassian.net/browse/HHH-8839
>>
>> Cheers,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>

From gunnar at hibernate.org  Thu Jul 31 08:02:29 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 31 Jul 2014 14:02:29 +0200
Subject: [hibernate-dev] Exposing Hibernate statistics via JMX
Message-ID: <CADGJaX-G7+qq0Vu4rxfKk0_6ererF02=L_XXPKw1pgoSMxeeiA@mail.gmail.com>

Steve, all,

I've been asked about the Hibernate statistics functionality which used to
be accessible via JMX.

There used to be StatisticsService which was an MBean and which one could
register with the JMX platform. This has been removed a while ago, and
there is the related issue HHH-6190 which still is open.

Until this is resolved, what is the recommended strategy towards making the
statistics available via JMX? Should users create and export their own
MBean based on SessionFactory#getStatistics()? Or is there any other
replacement for StatisticsService?

Thanks,

--Gunnar

[1] https://hibernate.atlassian.net/browse/HHH-6190

From sanne at hibernate.org  Thu Jul 31 14:01:31 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 31 Jul 2014 19:01:31 +0100
Subject: [hibernate-dev] Voting for Hibernate OGM: Duke Awards
Message-ID: <CAFm4XO01urk90Lt8JfWwJGa-vE5zki3mEqM1AYqfeoxM+pY7Jg@mail.gmail.com>

Hi All!
I hope you've seen our post on in.relation.to [1].

Please vote, and it would be very helpful if you could help spreading
the news as well:

https://twitter.com/Hibernate/status/494903681817792513

Unfortunately we didn't know that the project was nominated so we
started very late to advertise it, so we're quite behind but with your
help we might still make it to a decent result.

TiA,
Sanne

1 - http://in.relation.to/Bloggers/HibernateOGMNominatedForDukesChoiceAward2014