Re: [hibernate-dev] HIbernate ORM CI builds

[Steve Ebersole]

http://ci.hibernate.org/job/hibernate-orm-master-h2-main/
http://ci.hibernate.org/job/hibernate-orm-master-h2-check/

Initial attempt

On Sat, Jun 18, 2016 at 12:58 PM Sanne Grinovero 
wrote:

> On 18 June 2016 at 18:50, Chris Cranford  wrote:
> > +1
> >
> > I think (1) and (2) on each push still makes sense with (3) being
> nightly.
>
> +1
>
>  -- Sanne
>
> >
> > Chris
> >
> >
> > On 06/18/2016 11:33 AM, Steve Ebersole wrote:
> >> We have been having a lot of timeouts on the ORM CI builds.  Mainly
> this is
> >> due to ancillary tasks.  Currently the ORM jobs execute:
> >>
> >> 1. clean
> >> 2. test
> >> 3. check
> >> 4. :documentation:aggregateJavadocs
> >> 5. publish
> >>
> >> A huge chunk of the time is taken up in (3) which performs (a)
> checkstyle
> >> and (b) findbugs.  Also, I am not sure of the benefit of building
> >> aggregated javadocs for each and every CI build.  So I propose we break
> >> these up as follows:
> >>
> >>
> >> 1. A check job
> >> 2. A clean/test/publish job
> >> 3. (?) aggregated javadocs job (?)
> >>
> >> This would allow us to split the cost of the Job timeout across the
> jobs.
> >> In fact we might even consider making some of these into nightly job(s).
> >> Initially in setting up this server we decided to just have singular,
> >> all-encompassing jobs because moving to a new dedicated set of hardware
> >> (dedicated to Hibernate team) was supposed to free us from jobs fighting
> >> for resources.  But as our jobs have grown on the dedicated hardware we
> are
> >> seeing some of the same.  For certain we want a clean/test/publish job
> that
> >> is run on every push.  To me the others are more flexible in terms of
> >> scheduling.  We could have a separate check job that is run on each
> push,
> >> or it could be a nightly job.  We might even decide to leave off
> building
> >> aggregated javadocs as an automated job/task, or we might decide to
> make it
> >> a nightly job as well (maybe even with full documentation builds).
> >>
> >> WDYT?
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HIbernate ORM CI builds

[Sanne Grinovero]

On 18 June 2016 at 18:50, Chris Cranford  wrote:
> +1
>
> I think (1) and (2) on each push still makes sense with (3) being nightly.

+1

 -- Sanne

>
> Chris
>
>
> On 06/18/2016 11:33 AM, Steve Ebersole wrote:
>> We have been having a lot of timeouts on the ORM CI builds.  Mainly this is
>> due to ancillary tasks.  Currently the ORM jobs execute:
>>
>> 1. clean
>> 2. test
>> 3. check
>> 4. :documentation:aggregateJavadocs
>> 5. publish
>>
>> A huge chunk of the time is taken up in (3) which performs (a) checkstyle
>> and (b) findbugs.  Also, I am not sure of the benefit of building
>> aggregated javadocs for each and every CI build.  So I propose we break
>> these up as follows:
>>
>>
>> 1. A check job
>> 2. A clean/test/publish job
>> 3. (?) aggregated javadocs job (?)
>>
>> This would allow us to split the cost of the Job timeout across the jobs.
>> In fact we might even consider making some of these into nightly job(s).
>> Initially in setting up this server we decided to just have singular,
>> all-encompassing jobs because moving to a new dedicated set of hardware
>> (dedicated to Hibernate team) was supposed to free us from jobs fighting
>> for resources.  But as our jobs have grown on the dedicated hardware we are
>> seeing some of the same.  For certain we want a clean/test/publish job that
>> is run on every push.  To me the others are more flexible in terms of
>> scheduling.  We could have a separate check job that is run on each push,
>> or it could be a nightly job.  We might even decide to leave off building
>> aggregated javadocs as an automated job/task, or we might decide to make it
>> a nightly job as well (maybe even with full documentation builds).
>>
>> WDYT?
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HIbernate ORM CI builds

[Vlad Mihalcea]

+1 too.

On Sat, Jun 18, 2016 at 8:50 PM, Chris Cranford  wrote:

> +1
>
> I think (1) and (2) on each push still makes sense with (3) being nightly.
>
> Chris
>
>
> On 06/18/2016 11:33 AM, Steve Ebersole wrote:
> > We have been having a lot of timeouts on the ORM CI builds.  Mainly this
> is
> > due to ancillary tasks.  Currently the ORM jobs execute:
> >
> > 1. clean
> > 2. test
> > 3. check
> > 4. :documentation:aggregateJavadocs
> > 5. publish
> >
> > A huge chunk of the time is taken up in (3) which performs (a) checkstyle
> > and (b) findbugs.  Also, I am not sure of the benefit of building
> > aggregated javadocs for each and every CI build.  So I propose we break
> > these up as follows:
> >
> >
> > 1. A check job
> > 2. A clean/test/publish job
> > 3. (?) aggregated javadocs job (?)
> >
> > This would allow us to split the cost of the Job timeout across the jobs.
> > In fact we might even consider making some of these into nightly job(s).
> > Initially in setting up this server we decided to just have singular,
> > all-encompassing jobs because moving to a new dedicated set of hardware
> > (dedicated to Hibernate team) was supposed to free us from jobs fighting
> > for resources.  But as our jobs have grown on the dedicated hardware we
> are
> > seeing some of the same.  For certain we want a clean/test/publish job
> that
> > is run on every push.  To me the others are more flexible in terms of
> > scheduling.  We could have a separate check job that is run on each push,
> > or it could be a nightly job.  We might even decide to leave off building
> > aggregated javadocs as an automated job/task, or we might decide to make
> it
> > a nightly job as well (maybe even with full documentation builds).
> >
> > WDYT?
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HIbernate ORM CI builds

[Chris Cranford]

+1

I think (1) and (2) on each push still makes sense with (3) being nightly.

Chris


On 06/18/2016 11:33 AM, Steve Ebersole wrote:
> We have been having a lot of timeouts on the ORM CI builds.  Mainly this is
> due to ancillary tasks.  Currently the ORM jobs execute:
>
> 1. clean
> 2. test
> 3. check
> 4. :documentation:aggregateJavadocs
> 5. publish
>
> A huge chunk of the time is taken up in (3) which performs (a) checkstyle
> and (b) findbugs.  Also, I am not sure of the benefit of building
> aggregated javadocs for each and every CI build.  So I propose we break
> these up as follows:
>
>
> 1. A check job
> 2. A clean/test/publish job
> 3. (?) aggregated javadocs job (?)
>
> This would allow us to split the cost of the Job timeout across the jobs.
> In fact we might even consider making some of these into nightly job(s).
> Initially in setting up this server we decided to just have singular,
> all-encompassing jobs because moving to a new dedicated set of hardware
> (dedicated to Hibernate team) was supposed to free us from jobs fighting
> for resources.  But as our jobs have grown on the dedicated hardware we are
> seeing some of the same.  For certain we want a clean/test/publish job that
> is run on every push.  To me the others are more flexible in terms of
> scheduling.  We could have a separate check job that is run on each push,
> or it could be a nightly job.  We might even decide to leave off building
> aggregated javadocs as an automated job/task, or we might decide to make it
> a nightly job as well (maybe even with full documentation builds).
>
> WDYT?
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Java 9: progress on compatibility

[Steve Ebersole]

Sanne I do not have rights to edit your ORM JDK 9 job.  I wanted to look at
the job config to make sure it is ok, but I cannot even see it.

On Fri, Jun 17, 2016 at 7:22 PM Steve Ebersole  wrote:

> For the most part we have gotten ORM buildable with Java 9.  Some "open
> items":
>
>1. Javassist does not seem to support Java 9 much, if at all.  I had
>to disable some tests in hibernate-core that test enhancement as well as
>tests for hibernate-hikari since it uses Javassist extensively too.
> hibernate-envers has a bunch of test failures that seem related to
>Javassist as well.
>2. The tests for hibernate-osgi simply hang.  Something in that test
>stack does not like Java 9.
>
> Longer term we need to decide how we want to handle non standard modules
> moving forward.  This mostly came up in regards to JAXB and XJC.  For the
> moment I added a set of non-transitive dependencies for JAXB and XJC to
> hibernate-core and hibernate-jpamodelgen.  Since the hibernate-core one is
> non-transitive I then had to add a similar fragment to each and every
> module that depends on hibernate-core tries to run tests using it.  This
> gets fugly :)  For reference the fragment looks like:
>
> // ~~
>
> // Java 9 ftw!
> if ( JavaVersion.current().isJava9Compatible() ) {
> // The JDK used to run Gradle is Java 9+, and we assume that that is the 
> same
> //JDK for executing tasks
> compile( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
> compile( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
> compile( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
> compile( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
> compile( 'javax:javaee-api:7.0' )
>
> testCompile( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
> testCompile( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
> testCompile( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
> testCompile( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
> testCompile( 'javax:javaee-api:7.0' )
>
> testRuntime( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
> testRuntime( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
> testRuntime( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
> testRuntime( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
> testRuntime( 'javax:javaee-api:7.0' )
> }
> // ~~
>
>
> I decided to do this non-transitively since users may (probably) would
> want to use a better JAXB impl.  Not sure the best way to handle this.
>
> On Wed, Jun 15, 2016 at 3:14 PM Steve Ebersole 
> wrote:
>
>> No worries, I understand.
>>
>> On Wed, Jun 15, 2016 at 3:13 PM Sanne Grinovero 
>> wrote:
>>
>>> On 15 June 2016 at 19:29, Steve Ebersole  wrote:
>>> > WRT JAXB (XJC) I am completely lost.
>>> >
>>> > Sanne I tried your solution of specifying an addmod for jaxb to
>>> GRADLE_OPTS
>>> > but get the same result (ExceptionInInitializerError) with and without
>>> that
>>> > change.  So not sure how you got that to work.
>>>
>>> Steve, sorry if that wasn't clear: this didn't work for me either.
>>> I used the GRADLE_OPTS to bypass other issues which I had before
>>> reaching this point, but then I got stuck on the 'xjc' plugin, and
>>> that's were I asked if we could bypass/skip/rewrite the plugin.
>>>
>>> >
>>> > I did try the alternative we discussed of defining an explicit build
>>> > dependency on JAXB (which again has no effect):
>>> >
>>> >
>>> > xjc 'org.glassfish.jaxb:jaxb-core:2.2.11'
>>> > xjc 'org.glassfish.jaxb:jaxb-xjc:2.2.11'
>>> > xjc 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0'
>>> > xjc 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0'
>>> >
>>> >
>>> > For some background, XJC is currently performed via Gradle's AntBuilder
>>> > support using the jaxb2_commons Ant task
>>> > (org.jvnet.jaxb2_commons.xjc.XJC2Task). I also have tried using Sun's
>>> > com.sun.tools.xjc.XJCTask directly.  Neither make any difference.  The
>>> > fundamental problem is that for Ant execution Gradle simply reuses its
>>> VM.
>>> > So to get this applied (iiuc) the only real option is to configure the
>>> > Gradle launch to include the addmod (which makes it more odd that
>>> > GRADLE_OPTS did not work for me).
>>> >
>>> > The other option is to write a new Gradle XjcTask that executes the
>>> XJC tool
>>> > directly.  That we can use Gradle to help us fork and pass the addmod
>>> option
>>> > to the forked process.  I think :)
>>> >
>>> >
>>> > On Mon, Jun 13, 2016 at 3:00 AM Gunnar Morling 
>>> wrote:
>>> >>
>>> >> Yep, we discussed that approach last year already:
>>> >> http://lists.jboss.org/pipermail/hibernate-dev/2015-March/012250.html
>>> >>
>>> >> 2016-06-13 9:49 GMT+02:00 Sanne Grinovero :
>>> >>
>>> >> > On 13 June 2016 at 07:34, Gunnar Morling 
>>> wrote:
>>> 

[hibernate-dev] HIbernate ORM CI builds

[Steve Ebersole]

We have been having a lot of timeouts on the ORM CI builds.  Mainly this is
due to ancillary tasks.  Currently the ORM jobs execute:

   1. clean
   2. test
   3. check
   4. :documentation:aggregateJavadocs
   5. publish

A huge chunk of the time is taken up in (3) which performs (a) checkstyle
and (b) findbugs.  Also, I am not sure of the benefit of building
aggregated javadocs for each and every CI build.  So I propose we break
these up as follows:


   1. A check job
   2. A clean/test/publish job
   3. (?) aggregated javadocs job (?)

This would allow us to split the cost of the Job timeout across the jobs.
In fact we might even consider making some of these into nightly job(s).
Initially in setting up this server we decided to just have singular,
all-encompassing jobs because moving to a new dedicated set of hardware
(dedicated to Hibernate team) was supposed to free us from jobs fighting
for resources.  But as our jobs have grown on the dedicated hardware we are
seeing some of the same.  For certain we want a clean/test/publish job that
is run on every push.  To me the others are more flexible in terms of
scheduling.  We could have a separate check job that is run on each push,
or it could be a nightly job.  We might even decide to leave off building
aggregated javadocs as an automated job/task, or we might decide to make it
a nightly job as well (maybe even with full documentation builds).

WDYT?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Is org.hibernate.cache.spi.OptimisticCacheSource#getVersionComparator obsolete?

[Steve Ebersole]

TIMESTAMP is a deprecated synonym for the TSQL rownumber datatype, at least
on SQL Server.  Not sure specifically about Sybase.  So I'll use "rownumber"
here...

As we discussed in HipChat yesterday OptimisticCacheSource was added a long
time ago to facilitate leveraging JBossCache's MVCC support for versioned
data.  The idea was to allow JBossCache to reuse a versioned entity's
version as its MVCC version via the comparator.

JBossCache is of course no more, now morphed into Infinispan.  To my
knowledge, Infinispan does not have the same MVCC support if any.  Either
way, hibernate-infinispan does not support MVCC in the Infinispan cache by
leveraging the entity version.  Radim, Galder - is this something we want
to consider?

Depending on the version (and I forget the exact version this changed) the
role played by OptimisticCacheSource is actually now handled by
org.hibernate.cache.spi.CacheDataDescription.
So that is one of the reasons you do not find any uses of
OptimisticCacheSource#getVersionComparator.  Do a usage search for
CacheDataDescription#getVersionComparator instead.

Same question, different contract.

Some of the cache providers do leverage this version comparator (via
CacheDataDescription#getVersionComparator) for read-write locking.  So
really the question is whether we want to allow the combination of:


   1.  these cache providers with those access strategies using the version
   comparator
   2. versions based on TSQL rowversion datatype.

Aside from a general dislike of versions based on TSQL rowversion datatype
(for many reasons), there is no fundamental reason to not allow it as a
comparator (provided we find the right comparison algorithm).  If you have
found the secret incantation for writing a proper Java Comparator based on
the TSQL rowversion datatype, then I think we should just implement that.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [Question] Target runtime WildFly is unpacked after maven tests

[Mincong Huang]

Hi everybody,

I'm Mincong, your intern from Google Summer of Code. I'm working on
a new implement of mass indexer for Hibernate Search but I get some
difficulties to configure correctly the test cases. It seems that the tests
try to run before the WF10 setup. I've post this question on Stack Overflow
[1]. The question itself is really long, so please click the link to see
it. Any
tip will be helpful.

Thank you and have a good weekend :)

Mincong

[1]:
http://stackoverflow.com/questions/37898297/target-runtime-wildfly-is-unpacked-after-maven-tests
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev