[hibernate-dev] Hibernate Reactive 2.3.1.Final is now available

[Davide D'Alto]

This version is compatible with Hibernate ORM 6.5.2.Final
and contains some bug fixes

You can find more information in the release post:
https://in.relation.to/2024/05/28/hibernate-reactive-2_3_1_Final/
<https://in.relation.to/2024/04/29/hibernate-reactive-2_3_0/>

Thanks,
Davide D'Alto (he/him)
Hibernate Team
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: 
https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/message/HOPFVWJDUQYYB235O4TVFIZYVN2WARPR/

[hibernate-dev] Hibernate Reactive 2.3.0.Final is now available

[Davide D'Alto]

This version is compatible with Hibernate ORM 6.5.0.Final
and supports soft deletes.

You can find more information in the release post:
https://in.relation.to/2024/04/29/hibernate-reactive-2_3_0/

Thanks,
Davide D'Alto (he/him)
Hibernate Team
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: 
https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/message/KLO6HDXUVRK5ZH6DG6YDP5FSFFDMJNAF/

[hibernate-dev] Hibernate Reactive 2.2.2.Final is now available

[Davide D'Alto]

This version is compatible with Hibernate ORM 6.4.2.Final and Vert.x 4.5.1

You can find more details in the release post:
https://in.relation.to/2024/01/24/hibernate-reactive-2_2_2/

Thanks,
Davide D'Alto (he/him)
Hibernate Team
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: 
https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/message/BJBR6A6SBO4XJZB55DFWBDNGHTC4NJEN/

[hibernate-dev] Hibernate Reactive 2.2.0.Final is now available

[Davide D'Alto]

This version is compatible with Hibernate ORM 6.4.0.Final and Vert.x
4.5.0.Final.

You can find more information in the release post:
https://in.relation.to/2023/11/28/hibernate-reactive-2_2_Final/

Thanks,
Davide D'Alto (he/him)
Hibernate Team
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: 
https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/message/EOUPFHDT3X6DNF77TEF3IYBBDIKODT33/

[hibernate-dev] Hibernate Reactive 2.0.1.Final is available!

[Davide D'Alto]

This version is compatible with Hibernate ORM 6.2.5.Final.

More information in the release post:
https://in.relation.to/2023/06/16/hibernate-reactive-2_0_1_Final/

Thanks,
Davide D'Alto (he/him)
Hibernate Team
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 2.0.0.Final is now available

[Davide D'Alto]

This is the first stable release compatible with Hibernate ORM 6.2.0.Final
and Vert.x 4.4.2

You can find more information in the release post:
https://in.relation.to/2023/06/02/hibernate-reactive-2_0_0_Final/

Thanks,
Davide D'Alto (he/him)
Hibernate Team
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.1.8.Final is now available

[Davide D'Alto]

Hibernate Reactive 1.1.8.Final has been released.
It's a maintenance release with a couple of bug fixes.

All the details in the blog post:
https://in.relation.to/2022/09/28/hibernate-reactive-1_1_8_Final/

Thanks,
Davide D'Alto (he/him)
Hibernate Team
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.1.7.Final is now available

[Davide D'Alto]

We fixed a couple of bugs in this release.
You can find all the details in the blog post:
https://in.relation.to/2022/07/05/hibernate-reactive-1_1_7_Final/

Thanks,
Davide D'Alto (he/him)
Hibernate Team
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.1.6.Final is now available

[Davide D'Alto]

This release contains a couple of performance and bug fixes.

You can find more information in the release post:
https://in.relation.to/2022/05/23/hibernate-reactive-1_1_6_Final/
<https://in.relation.to/2022/02/11/hibernate-reactive-1_1_3_Final/>

Thanks,
Davide D'Alto (he/him)
Hibernate Team
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.1.4.Final is available

[Davide D'Alto]

Hibernate Reactive 1.1.4.Final has been released.
It contains some bug fixes and upgrades Hibernate ORM to 5.6.7.Final

You can find more information in the release post:
https://in.relation.to/2022/03/22/hibernate-reactive-1_1_4_Final/
<https://in.relation.to/2022/02/11/hibernate-reactive-1_1_3_Final/>

Thanks,
Davide D'Alto (he/him)
Hibernate Team
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.1.3.Final is available

[Davide D'Alto]

Hibernate Reactive 1.1.3.Final has been released.
This release add Oracle to the list of supported databases.

All the details are in the release post:
https://in.relation.to/2022/02/11/hibernate-reactive-1_1_3_Final/

Thanks,
Davide D'Alto (he/him)
Hibernate Team
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.1.1.Final

[Davide D'Alto]

Hibernate Reactive 1.1.1.Final is now available
and it is compatible with Hibernate ORM 5.6.2.Final:
https://in.relation.to/2021/12/13/hibernate-reactive-1_1_1_Final/

Thanks

Davide
(He/him/his)
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.1.0.Final (correct link)

[Davide D'Alto]

Apologies, the link in the previous email was wrong.

Here's the link to the right blog post:
https://in.relation.to/2021/11/09/hibernate-reactive-1_1_0_Final

Thanks!

Davide D'Alto
He/him/his
dav...@hibernate.org
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.1.0.Final is available

[Davide D'Alto]

Now with Vert.x 4.2

All the details are available in the release post:
https://in.relation.to/2021/11/09/hibernate-reactive-1_1_0_Fi
<https://in.relation.to/2021/10/13/hibernate-reactive-1_0_0_CR10/>nal/

Thanks a lot!

Davide D'Alto
He/him/his
dav...@hibernate.org
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.0.1.Final

[Davide D'Alto]

Hibernate Reactive 1.0.1.Final is now available!
This is a maintenance release containing several performance improvements.

All the details in the blog post:
https://in.relation.to/2021/11/01/hibernate-reactive-1_0_1_Final/

Thanks!

Davide
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.0.0.CR10 is now available

[Davide D'Alto]

This release adds support for automatic schema validation and update for
MySQL, Db2 and MS SQL Server.

We’ve also changed the methods for the creation of a new session, so you
might see some compilation errors after the upgrade.

All the details are available in the release post:
https://in.relation.to/2021/10/13/hibernate-reactive-1_0_0_CR10/

Thanks a lot!
Davide D'Alto
He/him/his
Hibernate Team
dav...@hibernate.org
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.0.0.CR7 is out!

[Davide D'Alto]

Hibernate Reactive 1.0.0.CR7 is available and is now licensed under the
Apache License, Version 2.0.
Find all the details about this release in the blog post:
https://in.relation.to/2021/06/18/hibernate-reactive-1_0_0_CR7/

Thank you all!

Davide D'Alto
He/him/his
Hibernate Team
dav...@hibernate.org
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.0.0.CR6 is out!

[Davide D'Alto]

This new release has been upgraded to Hibernate ORM 5.5.0.Final and Vert.x
4.1.0.
It also contains several bug fixes about the session not being closed
correctly in some cases.

Find all the details in the release post:
https://in.relation.to/2021/06/02/hibernate-reactive-1_0_0_CR6/

Thanks all!

Davide D'Alto
He/him/his
Hibernate Team
dav...@hibernate.org
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.0.0.CR5 is out!

[Davide D'Alto]

This new release improves the multitenancy support, requires Hibernate ORM
5.4.32.Final and improves how withTransaction and withSession work.

Find all the details in the release post:
https://in.relation.to/2021/05/24/hibernate-reactive-1_0_0_CR5/

Thanks all!

Davide D'Alto
He/him/his
Hibernate Team
dav...@hibernate.org
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.0.0.CR4 has been released

[Davide D'Alto]

Hibernate Reactive 1.0.0.CR4 is out now!

Hibernate Reactive is now compatible with both Hibernate ORM 5.4 and 5.5.
There are also some changes on how to close a reactive session
because the method "Session#close" is now reactive.

Find all the details in the blog post:
https://in.relation.to/2021/04/30/hibernate-reactive-1_0_0_CR4/

Thank you!

Davide D'Alto
He/him/his
Hibernate Team
dav...@hibernate.org
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.0.0.CR3 released

[Davide D'Alto]

We've just released Hibernate Reactive 1.0.0.CR3.

It contains an important bugfix for the id generation.

Find all the details in the blog post:
https://in.relation.to/2021/04/16/hibernate-reactive-1_0_0_CR3/

Thank you!

Davide D'Alto
Hibernate Team
dav...@hibernate.org
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.0.0.CR3 released

[Davide D'Alto]

We've just released Hibernate Reactive 1.0.0.CR3.

It contains an important bugfix for the id generation.

Find all the details in the blog post:
https://in.relation.to/2021/04/16/hibernate-reactive-1_0_0_CR3/

Thank you!

Davide D'Alto
Hibernate Team
dav...@hibernate.org
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate Reactive 1.0.0.CR2 released

[Davide D'Alto]

Hello everyone,

Hibernate Reactive 1.0.0.CR2 is out and it now depends on Vert.x 4.0.3.

Find all the details in the blog:
https://in.relation.to/2021/04/15/hibernate-reactive-1_0_0_CR2/

Thank you,
Davide D'Alto
Hibernate Team
dav...@hibernate.org 
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Hibernate Search 6.0.0.Final is out!

[Davide D'Alto]

Awesome! Congratulations!

On Fri, Dec 11, 2020 at 12:05 PM Sanne Grinovero 
wrote:

> Congratulations!
>
> Really cool, and that was a huge amount of work.
>
> On Fri, 11 Dec 2020 at 10:31, Yoann Rodiere  wrote:
> >
> > Hello,
> >
> > We just published the first stable release of Hibernate Search 6: version
> > 6.0.0.Final.
> >
> > With more than 900 tickets addressed
> > <
> https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HSEARCH%20AND%20fixVersion%20in%20(6.0.0.Final%2C%206.0.0.CR2%2C%206.0.0.CR1%2C%206.0.0.Beta11%2C%206.0.0.Beta10%2C%206.0.0.Beta9%2C%206.0.0.Beta8%2C%206.0.0.Beta7%2C%206.0.0.Beta6%2C%206.0.0.Beta5%2C%206.0.0.Beta4%2C%206.0.0.Beta3%2C%206.0.0.Beta2%2C%206.0.0.Beta1%2C%206.0.0.Alpha9%2C%206.0.0.Alpha8%2C%206.0.0.Alpha7%2C%206.0.0.Alpha6%2C%206.0.0.Alpha5%2C%206.0.0.Alpha4%2C%206.0.0.Alpha3%2C%206.0.0.Alpha2%2C%206.0.0.Alpha1)%20ORDER%20BY%20updated
> >
> > over the course of 20 alphas and betas, Hibernate Search 6 really is a
> > major release, and it shows.
> >
> > The most obvious changes: an overhauled API better suited to working with
> > Elasticsearch (but that still works perfectly with embedded Lucene), and
> > upgrades from Lucene 5 to 8 and from Elasticsearch 5.6 to 7.
> >
> > But it doesn’t stop there: a safer and more concise Search DSL, easier
> > mapping, more powerful bridges, smarter automatic indexing, nested
> > documents, …
> >
> > For more information (what's new, getting started, migrating, ...), see
> our
> > blog:
> >
> > https://in.relation.to/2020/12/11/hibernate-search-6-0-0-Final/
> >
> > Yoann Rodière
> > Hibernate Team
> > yo...@hibernate.org
> > ___
> > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Hibernate Search 6.0.0.Final is out!

[Davide D'Alto]

Awesome! Congratulations!

On Fri, Dec 11, 2020 at 6:21 PM Davide D'Alto  wrote:

> Awesome! Congratulations!
>
> On Fri, Dec 11, 2020 at 12:05 PM Sanne Grinovero 
> wrote:
>
>> Congratulations!
>>
>> Really cool, and that was a huge amount of work.
>>
>> On Fri, 11 Dec 2020 at 10:31, Yoann Rodiere  wrote:
>> >
>> > Hello,
>> >
>> > We just published the first stable release of Hibernate Search 6:
>> version
>> > 6.0.0.Final.
>> >
>> > With more than 900 tickets addressed
>> > <
>> https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HSEARCH%20AND%20fixVersion%20in%20(6.0.0.Final%2C%206.0.0.CR2%2C%206.0.0.CR1%2C%206.0.0.Beta11%2C%206.0.0.Beta10%2C%206.0.0.Beta9%2C%206.0.0.Beta8%2C%206.0.0.Beta7%2C%206.0.0.Beta6%2C%206.0.0.Beta5%2C%206.0.0.Beta4%2C%206.0.0.Beta3%2C%206.0.0.Beta2%2C%206.0.0.Beta1%2C%206.0.0.Alpha9%2C%206.0.0.Alpha8%2C%206.0.0.Alpha7%2C%206.0.0.Alpha6%2C%206.0.0.Alpha5%2C%206.0.0.Alpha4%2C%206.0.0.Alpha3%2C%206.0.0.Alpha2%2C%206.0.0.Alpha1)%20ORDER%20BY%20updated
>> >
>> > over the course of 20 alphas and betas, Hibernate Search 6 really is a
>> > major release, and it shows.
>> >
>> > The most obvious changes: an overhauled API better suited to working
>> with
>> > Elasticsearch (but that still works perfectly with embedded Lucene), and
>> > upgrades from Lucene 5 to 8 and from Elasticsearch 5.6 to 7.
>> >
>> > But it doesn’t stop there: a safer and more concise Search DSL, easier
>> > mapping, more powerful bridges, smarter automatic indexing, nested
>> > documents, …
>> >
>> > For more information (what's new, getting started, migrating, ...), see
>> our
>> > blog:
>> >
>> > https://in.relation.to/2020/12/11/hibernate-search-6-0-0-Final/
>> >
>> > Yoann Rodière
>> > Hibernate Team
>> > yo...@hibernate.org
>> > ___
>> > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
>> > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
>> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>> ___
>> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
>> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Re: [hibernate-dev] Renamed the Hibernate Reactive repository

[Davide D'Alto]

Thanks a lot

On Tue, May 12, 2020 at 3:15 PM Sanne Grinovero  wrote:

> Hi all,
>
> I've just renamed the repository on github.
>
> Please update your bookmarks, scripts, git remotes and habits :)
>  - https://github.com/hibernate/hibernate-reactive
>
> I see github automatically activated redirects, but I don't know how
> well that works.
>
> You might want to rename your own forks as well?
>
> sorry for the inconvenience, better soon than later!
>
> Thanks,
> Sanne
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Rx: Mutiny in the API

[Davide D'Alto]

For anybody interested, there is a discussion here about using Mutiny in
the API and how it would look like:
https://github.com/hibernate/hibernate-rx/issues/94

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

[hibernate-dev] Hibernate Rx: Remove Optional from API

[Davide D'Alto]

Hi,
Gavin sent this PR: https://github.com/hibernate/hibernate-rx/pull/93

It removes Optional from the API, for example:

 CompletionStage> fetch(T association);

becomes:

 CompletionStage fetch(T association);

Is there anybody here with strong opinions about keeping Optional in the
API?

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

Re: [hibernate-dev] Jenkins upgrade

[Davide D'Alto]

On a related note, I've created a new AMI to use as slave and
configure Jenkins to use it.
If there are issues, it is still possible to use the old one  by
updating the Jenkins configuration (http://ci.hibernate.org/configure)
to the AMI ID we used before (custom fedora v23).

Cheers,
Davide

On Tue, Apr 30, 2019 at 11:46 AM Yoann Rodiere  wrote:
>
> Hello,
>
> TL;DR: I just updated Jenkins and its plugins. If things stop working
> correctly, please let me know.
>
> Some details below, in case I'm not here when things start to break down...
>
> I updated Jenkins and its plugins to the latest versions, hoping to fix the
> problem we've been having lately where we would only ever get a single EC2
> slave.
>
> The result was an AWS EC2 plugin that started many, many EC2 slaves, but on
> the Jenkins side mapped all slaves to the same URL, which resulted in
> multiple builds running concurrently on the same EC2 instance, which
> obviously resulted in many failures.
>
> I rolled back the AWS EC2 plugin from 1.42 to 1.39 (like I had to do a few
> weeks ago), and things to be back to normal. It even works better than
> before I attempted the upgrade: the plugin correctly spawns multiple slaves
> as required.
>
> Frankly I don't understand what is going on, but it works again so I'll
> stop touching it. I suppose I should take the time to investigate, attempt
> to reproduce the problem and report it to the plugin maintainers. I
> currently do not have a few days to spare for that, so it'll wait...
>
> For the record, I also had to do the following during the upgrade:
>
>- I had to update the AWS permissions for the EC2 plugin:
>
> https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+Plugin#AmazonEC2Plugin-Version1.41(Oct24th,2018)
>- I had to install a plugin to ensure running builds are no longer
>allowed to do whatever they want (~root permissions):
>
> https://jenkins.io/doc/book/system-administration/security/build-authorization/
>
> Cheers,
>
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
> ___
> 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] Hibernate OGM 5.4.1.Final released!

[Davide D'Alto]

Hibernate OGM 5.4.1.Final has been released!

The feature packs included in this release are now compatible with
WildFly 14 and we added support for the @OrderBy annotation.

All the details are in the blog post:
http://in.relation.to/2018/12/18/hibernate-ogm-5-4-1-Final-released/

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

Re: [hibernate-dev] master and 6.0 branch

[Davide D'Alto]

Weekly meetings sounds.
I can also help with porting things to 6.

PS: Sorry if you have received 2 emails, I used the wrong address in
the first one.
On Fri, Dec 14, 2018 at 11:02 AM Davide D'Alto  wrote:
>
> Weekly meeting sounds.
> I can also help with porting things to 6.
>
>
> On Fri, Dec 14, 2018 at 8:27 AM andrea boriero  wrote:
> >
> > Agree a meeting is a good idea especially when there are fixes that are not
> > easily portable to 6, as pointed out by Steve I think/hope that most of the
> > fixes will be easily ported by simply cherry-picking them.
> >
> > On Thu, 13 Dec 2018 at 17:56, Steve Ebersole  wrote:
> >
> > > I would not even put it on Gail specifically per-se from the 5.x side.
> > > Really we just need to be able to identify what fixes done on 5.x need to
> > > be ported across to 6.  And then, depending on the complexity,  I would
> > > expect some help from the person who implemented the fix in 5 porting that
> > > change to 6 - most of the time, I'd expect to just apply those changes
> > > myself (or Andrea or Chris).
> > >
> > > I think a meeting is a good idea
> > >
> > > On Thu, Dec 13, 2018 at 10:09 AM Guillaume Smet 
> > > wrote:
> > >
> > > > Sorry for not replying earlier, got very busy on other things.
> > > >
> > > > So, now that we agree, how do we do things? I think we should have a
> > > > weekly meeting at a fixed time to discuss master -> 6, probably either
> > > with
> > > > Andrea or Chris.
> > > >
> > > > I could do it for a few months if it helps but in the end, I think it
> > > > should be Gail for 5.x + whoever volunteers for the 6 part.
> > > >
> > > > On Thu, Dec 6, 2018 at 8:56 PM Steve Ebersole 
> > > wrote:
> > > >
> > > >> I completely agree with everything you say.  A few thoughts in-line...
> > > >>
> > > >> On Thu, Dec 6, 2018 at 12:37 PM Guillaume Smet <
> > > guillaume.s...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> == What to do then
> > > >>>
> > > >>
> > > >>> There are a couple of options:
> > > >>> 1/ no workaround, then we should consider it for 5.x
> > > >>>
> > > >>
> > > >> If it is fixed in 5 then it should be fixed in 6 as well.  Either it is
> > > >> no longer a problem or because we port the fix from 5 to 6.  Not saying
> > > >> exactly how that happens - just that that needs to be the end result.
> > > >>
> > > >>
> > > >>
> > > >>> 2/ there is a viable workaround, we can postpone it to 6, but we
> > > >>> definitely would need to have something to mark them as we need to fix
> > > them
> > > >>> (a version, maybe, or a tag?) - one thing is that it would probably be
> > > a
> > > >>> good idea to categorize things a bit because when you revisit
> > > something for
> > > >>> 6, it would be a good idea to have the existing bugs in mind as it
> > > could
> > > >>> influence the design.
> > > >>>
> > > >>
> > > >> Using a tag seems enticing, but experience tells me that won't really
> > > >> have the effect I think you want.
> > > >>
> > > >>
> > > >>
> > > >>> * if it's something we want to fix in 6, there might be several
> > > options:
> > > >>> 2.1/ we can already fix it in 6 because the features are already
> > > >>> implemented
> > > >>> 2.2/ we can't fix it right now
> > > >>>
> > > >>> IMHO, we should start considering taking into account 2.1/ into the
> > > >>> daily work for 6 if we want to make this work as otherwise we will end
> > > up
> > > >>> with a very big pile of bugs when 6 finally gets finalized.
> > > >>>
> > > >>
> > > >>
> > > >>>
> > > >>> As for 2.2/, we should really have a way to keep track of them and 
> > > >>> push
> > > >>> them to case 2.1/ when we can. Note that it's the same case if it's
> > > more an
> > > >>> improvement but we consider it as something we want: if we want it, we
> > > >

Re: [hibernate-dev] master and 6.0 branch

[Davide D'Alto]

Weekly meeting sounds.
I can also help with porting things to 6.


On Fri, Dec 14, 2018 at 8:27 AM andrea boriero  wrote:
>
> Agree a meeting is a good idea especially when there are fixes that are not
> easily portable to 6, as pointed out by Steve I think/hope that most of the
> fixes will be easily ported by simply cherry-picking them.
>
> On Thu, 13 Dec 2018 at 17:56, Steve Ebersole  wrote:
>
> > I would not even put it on Gail specifically per-se from the 5.x side.
> > Really we just need to be able to identify what fixes done on 5.x need to
> > be ported across to 6.  And then, depending on the complexity,  I would
> > expect some help from the person who implemented the fix in 5 porting that
> > change to 6 - most of the time, I'd expect to just apply those changes
> > myself (or Andrea or Chris).
> >
> > I think a meeting is a good idea
> >
> > On Thu, Dec 13, 2018 at 10:09 AM Guillaume Smet 
> > wrote:
> >
> > > Sorry for not replying earlier, got very busy on other things.
> > >
> > > So, now that we agree, how do we do things? I think we should have a
> > > weekly meeting at a fixed time to discuss master -> 6, probably either
> > with
> > > Andrea or Chris.
> > >
> > > I could do it for a few months if it helps but in the end, I think it
> > > should be Gail for 5.x + whoever volunteers for the 6 part.
> > >
> > > On Thu, Dec 6, 2018 at 8:56 PM Steve Ebersole 
> > wrote:
> > >
> > >> I completely agree with everything you say.  A few thoughts in-line...
> > >>
> > >> On Thu, Dec 6, 2018 at 12:37 PM Guillaume Smet <
> > guillaume.s...@gmail.com>
> > >> wrote:
> > >>
> > >>> == What to do then
> > >>>
> > >>
> > >>> There are a couple of options:
> > >>> 1/ no workaround, then we should consider it for 5.x
> > >>>
> > >>
> > >> If it is fixed in 5 then it should be fixed in 6 as well.  Either it is
> > >> no longer a problem or because we port the fix from 5 to 6.  Not saying
> > >> exactly how that happens - just that that needs to be the end result.
> > >>
> > >>
> > >>
> > >>> 2/ there is a viable workaround, we can postpone it to 6, but we
> > >>> definitely would need to have something to mark them as we need to fix
> > them
> > >>> (a version, maybe, or a tag?) - one thing is that it would probably be
> > a
> > >>> good idea to categorize things a bit because when you revisit
> > something for
> > >>> 6, it would be a good idea to have the existing bugs in mind as it
> > could
> > >>> influence the design.
> > >>>
> > >>
> > >> Using a tag seems enticing, but experience tells me that won't really
> > >> have the effect I think you want.
> > >>
> > >>
> > >>
> > >>> * if it's something we want to fix in 6, there might be several
> > options:
> > >>> 2.1/ we can already fix it in 6 because the features are already
> > >>> implemented
> > >>> 2.2/ we can't fix it right now
> > >>>
> > >>> IMHO, we should start considering taking into account 2.1/ into the
> > >>> daily work for 6 if we want to make this work as otherwise we will end
> > up
> > >>> with a very big pile of bugs when 6 finally gets finalized.
> > >>>
> > >>
> > >>
> > >>>
> > >>> As for 2.2/, we should really have a way to keep track of them and push
> > >>> them to case 2.1/ when we can. Note that it's the same case if it's
> > more an
> > >>> improvement but we consider it as something we want: if we want it, we
> > >>> should find a way to keep track of it somehow.
> > >>>
> > >>> That also means that we would need someone familiar with 6 to help
> > >>> triaging the issues. IMHO, this can be done once a week, if done
> > regularly
> > >>> and steadily.
> > >>>
> > >>> If we continue fixing bugs, even in 6 only, that still says to the
> > >>> contributor "we hear you, we are improving". If we just stop fixing
> > bugs
> > >>> until 6 is more or less feature-complete, then we send a very bad
> > message
> > >>> IMHO. And we will end up with a pile of unfixed issues in the
> > bugtracker
> > >>> that we won't really be able to deal with. And less users.
> > >>>
> > >>
> > >> Alpha1 just released the fix for HHH-37.  Yep, that's right 37 - the
> > 37th
> > >> issue ever since we moved to Jira.  We *do* keep improving ;)  And
> > that's
> > >> just one of the many.
> > >>
> > >> But yes your point is valid.  It is very important to keep fixing bugs.
> > >>
> > >
> > ___
> > 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] Moderation of in.relation.to

[Davide D'Alto]

> You mean answers to your own comments, right?

Not really, quite often I receive notification of somebody comment on a post.
But I will double check,maybe I don't remember correctly
On Mon, Nov 19, 2018 at 8:04 AM Yoann Rodiere  wrote:
>
> > To clarify, I get notified when there are new comments.
>
> You mean answers to your own comments, right? As Steve mentioned, Disqus 
> doesn't seem to send notifications for "root" comments.
>
> I just noticed the disqus integration seems to be done with a "crawler" on 
> our end. If that "crawler" is faulty and doesn't indicate to disqus the 
> proper author for each thread, that might explain the problems we have. I'm 
> having a look.
>
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
>
> On Sat, 17 Nov 2018 at 12:53, Davide D'Alto  wrote:
>>
>> To clarify, I get notified when there are new comments.
>> But I haven't seen a request about enabling users comments in a while.
>>
>> On Fri, Nov 16, 2018 at 7:24 PM Guillaume Smet  
>> wrote:
>> >
>> > I, for one, don't receive any email from disqus when there is a new 
>> > comment.
>> >
>> > On Fri, Nov 16, 2018 at 7:42 PM Sanne Grinovero  
>> > wrote:
>> >
>> > > On Fri, 16 Nov 2018 at 13:47, Yoann Rodiere  wrote:
>> > > >
>> > > > I think we need to be moderators, but I don't think I currently am. And
>> > > apparently I do not have access to the organization settings, where I
>> > > suppose we can define who is a moderator. (
>> > > https://disqus.com/admin/orgs/2655592/default/settings/general/ doesn't
>> > > work for me)
>> > > >
>> > > > Sanne, maybe you can register us?
>> > >
>> > > You're all registered as moderators already, except Fabio, Andrea and
>> > > Koen who don't seem to have an account (please register if at all
>> > > interested?).  You also all have the admin password, it's in the usual
>> > > wiki page ;)
>> > >
>> > > But I can't find other options either. I remember occasionally
>> > > receiving a moderator email request, I just don't seem to receive them
>> > > consistently?
>> > >
>> > >
>> > > >
>> > > > Thanks.
>> > > >
>> > > > Yoann Rodière
>> > > > Hibernate NoORM Team
>> > > > yo...@hibernate.org
>> > > >
>> > > >
>> > > > On Fri, 16 Nov 2018 at 14:26, Davide D'Alto 
>> > > wrote:
>> > > >>
>> > > >> I can join. What do I need to do to enable the notifications?
>> > > >> On Fri, Nov 16, 2018 at 7:16 AM Yoann Rodiere 
>> > > wrote:
>> > > >> >
>> > > >> > Count me in. At least one person per project would be ideal, since
>> > > these
>> > > >> > notifications are the only way we can get notified of comments on 
>> > > >> > our
>> > > >> > posts...
>> > > >> >
>> > > >> >
>> > > >> > Yoann Rodière
>> > > >> > Hibernate NoORM Team
>> > > >> > yo...@hibernate.org
>> > > >> >
>> > > >> >
>> > > >> > On Thu, 15 Nov 2018 at 13:37, Sanne Grinovero 
>> > > wrote:
>> > > >> >
>> > > >> > > Apparently I stopped receiving notifications from Discus about
>> > > needing
>> > > >> > > to approve a comment, and it looks like you all did?
>> > > >> > >
>> > > >> > > I just noticed as someome mentioned "while my other comment is not
>> > > >> > > approved" and I thought "wait, what? I know nothing about other
>> > > >> > > pending comments.." and didn't see any clue on the UI either.
>> > > >> > >
>> > > >> > > I eventually found the comments approval queue, and there were a
>> > > dozen
>> > > >> > > comments waiting; some >8 months old. Embarassing :(
>> > > >> > >
>> > > >> > > Let's make sure that at least some of us receive a timely
>> > > >> > > notification. Any volunteers to register for this? I will register
>> > > >> > > myself, hoping that some more of you will join on this.
>> > > >> > >
>> > > >> > > Thanks,
>> > > >> > > Sanne
>> > > >> > > ___
>> > > >> > > 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
>>
>> ___
>> 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] Moderation of in.relation.to

[Davide D'Alto]

To clarify, I get notified when there are new comments.
But I haven't seen a request about enabling users comments in a while.

On Fri, Nov 16, 2018 at 7:24 PM Guillaume Smet  wrote:
>
> I, for one, don't receive any email from disqus when there is a new comment.
>
> On Fri, Nov 16, 2018 at 7:42 PM Sanne Grinovero  wrote:
>
> > On Fri, 16 Nov 2018 at 13:47, Yoann Rodiere  wrote:
> > >
> > > I think we need to be moderators, but I don't think I currently am. And
> > apparently I do not have access to the organization settings, where I
> > suppose we can define who is a moderator. (
> > https://disqus.com/admin/orgs/2655592/default/settings/general/ doesn't
> > work for me)
> > >
> > > Sanne, maybe you can register us?
> >
> > You're all registered as moderators already, except Fabio, Andrea and
> > Koen who don't seem to have an account (please register if at all
> > interested?).  You also all have the admin password, it's in the usual
> > wiki page ;)
> >
> > But I can't find other options either. I remember occasionally
> > receiving a moderator email request, I just don't seem to receive them
> > consistently?
> >
> >
> > >
> > > Thanks.
> > >
> > > Yoann Rodière
> > > Hibernate NoORM Team
> > > yo...@hibernate.org
> > >
> > >
> > > On Fri, 16 Nov 2018 at 14:26, Davide D'Alto 
> > wrote:
> > >>
> > >> I can join. What do I need to do to enable the notifications?
> > >> On Fri, Nov 16, 2018 at 7:16 AM Yoann Rodiere 
> > wrote:
> > >> >
> > >> > Count me in. At least one person per project would be ideal, since
> > these
> > >> > notifications are the only way we can get notified of comments on our
> > >> > posts...
> > >> >
> > >> >
> > >> > Yoann Rodière
> > >> > Hibernate NoORM Team
> > >> > yo...@hibernate.org
> > >> >
> > >> >
> > >> > On Thu, 15 Nov 2018 at 13:37, Sanne Grinovero 
> > wrote:
> > >> >
> > >> > > Apparently I stopped receiving notifications from Discus about
> > needing
> > >> > > to approve a comment, and it looks like you all did?
> > >> > >
> > >> > > I just noticed as someome mentioned "while my other comment is not
> > >> > > approved" and I thought "wait, what? I know nothing about other
> > >> > > pending comments.." and didn't see any clue on the UI either.
> > >> > >
> > >> > > I eventually found the comments approval queue, and there were a
> > dozen
> > >> > > comments waiting; some >8 months old. Embarassing :(
> > >> > >
> > >> > > Let's make sure that at least some of us receive a timely
> > >> > > notification. Any volunteers to register for this? I will register
> > >> > > myself, hoping that some more of you will join on this.
> > >> > >
> > >> > > Thanks,
> > >> > > Sanne
> > >> > > ___
> > >> > > 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

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

Re: [hibernate-dev] Moderation of in.relation.to

[Davide D'Alto]

I have the same issue.

On Fri, Nov 16, 2018 at 1:47 PM Yoann Rodiere  wrote:
>
> I think we need to be moderators, but I don't think I currently am. And 
> apparently I do not have access to the organization settings, where I suppose 
> we can define who is a moderator. 
> (https://disqus.com/admin/orgs/2655592/default/settings/general/ doesn't work 
> for me)
>
> Sanne, maybe you can register us?
>
> Thanks.
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
>
> On Fri, 16 Nov 2018 at 14:26, Davide D'Alto  wrote:
>>
>> I can join. What do I need to do to enable the notifications?
>> On Fri, Nov 16, 2018 at 7:16 AM Yoann Rodiere  wrote:
>> >
>> > Count me in. At least one person per project would be ideal, since these
>> > notifications are the only way we can get notified of comments on our
>> > posts...
>> >
>> >
>> > Yoann Rodière
>> > Hibernate NoORM Team
>> > yo...@hibernate.org
>> >
>> >
>> > On Thu, 15 Nov 2018 at 13:37, Sanne Grinovero  wrote:
>> >
>> > > Apparently I stopped receiving notifications from Discus about needing
>> > > to approve a comment, and it looks like you all did?
>> > >
>> > > I just noticed as someome mentioned "while my other comment is not
>> > > approved" and I thought "wait, what? I know nothing about other
>> > > pending comments.." and didn't see any clue on the UI either.
>> > >
>> > > I eventually found the comments approval queue, and there were a dozen
>> > > comments waiting; some >8 months old. Embarassing :(
>> > >
>> > > Let's make sure that at least some of us receive a timely
>> > > notification. Any volunteers to register for this? I will register
>> > > myself, hoping that some more of you will join on this.
>> > >
>> > > Thanks,
>> > > Sanne
>> > > ___
>> > > 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] Moderation of in.relation.to

[Davide D'Alto]

I can join. What do I need to do to enable the notifications?
On Fri, Nov 16, 2018 at 7:16 AM Yoann Rodiere  wrote:
>
> Count me in. At least one person per project would be ideal, since these
> notifications are the only way we can get notified of comments on our
> posts...
>
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
>
> On Thu, 15 Nov 2018 at 13:37, Sanne Grinovero  wrote:
>
> > Apparently I stopped receiving notifications from Discus about needing
> > to approve a comment, and it looks like you all did?
> >
> > I just noticed as someome mentioned "while my other comment is not
> > approved" and I thought "wait, what? I know nothing about other
> > pending comments.." and didn't see any clue on the UI either.
> >
> > I eventually found the comments approval queue, and there were a dozen
> > comments waiting; some >8 months old. Embarassing :(
> >
> > Let's make sure that at least some of us receive a timely
> > notification. Any volunteers to register for this? I will register
> > myself, hoping that some more of you will join on this.
> >
> > Thanks,
> > Sanne
> > ___
> > 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] Hibernate OGM 5.4.0.Final release

[Davide D'Alto]

Hibernate OGM 5.4.0.Final has been released!

Here's some of the new features included in this release:

- Infinispan remote transactions over HotRod client
- JPQL and native queries support for Infinispan remote
- server side procedures calls for Infinispan Remote
- Cache creation and configuration for Infinispan remote
- GridFS support for MongoDB

More details available in the blog post:
http://in.relation.to/2018/10/30/hibernate-ogm-5-4-Final-released/

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

Re: [hibernate-dev] Jenkins updates

[Davide D'Alto]

Hi,
Jenkins is up-to-date now.

Please, keep that in mind if you face some problems.

Cheers,
Davide

On Fri, Jul 20, 2018 at 11:16 AM, Davide D'Alto  wrote:
> Hello,
> I'm planning to update Jenkins today.
>
> This means that there might be some disruptions on CI.
>
> Let me know if you have something planned that requires CI.
>
> Cheers,
> Davide
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Jenkins updates

[Davide D'Alto]

Hello,
I'm planning to update Jenkins today.

This means that there might be some disruptions on CI.

Let me know if you have something planned that requires CI.

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

Re: [hibernate-dev] Releases and CI setup

[Davide D'Alto]

Using docker might be a nice idea if the machines are powerful enough.

I will just mention it here but for the release only we can also not
use Jenkins and run the command
we need from the terminal of ci.hibernate.org. We already have the
scripts ready so it shouldn't be too hard.

If the Jenkins plugin doesn't work the way we need I don't feel like
creating our own branch and
I will consider it only if it's about sending a PR somewhere.

But all this won't solve the problem with SourceForge that seems to be
the main reason
we see failures lately.

On Mon, Apr 30, 2018 at 7:42 PM, Guillaume Smet
 wrote:
> On Mon, Apr 30, 2018 at 8:34 PM, Sanne Grinovero 
> wrote:
>
>> Starting a new slave only takes 3 minutes, but I believe it has to be
>> a "manual start" from its admin dashboard as Jenkins's scaling plugin
>> is limited.
>>
>> Fixing the Jenkins triggers would be my preference.
>>
>
> Yeah, last time we discussed this on HipChat, I have all the useful
> pointers. The code changes to the official plugin would be minimal. The
> only thing I'm worried about is how we would maintain this plugin.
>
> Alternatively:
>>  - we could look at pipelines
>>
>
> How would they solve the issue?
>
>
>>  - run all jobs within Docker -> improved isolation would allow us to
>> run N builds per machine
>>
>
> Would that help? I.e. are the machines we start powerful enough to run
> several jobs in parallel?
>
> I suspect, it wouldn't change the issue, just change the numbers of servers
> we would need (which might be good anyway but is not related to the issue
> at hand).
>
> --
> Guillaume
> ___
> 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] Hibernate OGM 5.4.0.Alpha1 release

[Davide D'Alto]

We’re happy to announce the release of Hibernate OGM 5.4.0.Alpha1.

Hibernate OGM is now compatible with Hibernate ORM 5.3 (still a
candidate release) and JPA 2.2. We support Infinipan 9.2 and JBoss
modules are now available as WildFly feature packs.

You can run server-side JavaScript on MongoDB or Java code in
Infinispan Embedded as if they were stored procedures using the JPA
approach.

When using the Infinispan Remote dialect, it is now possible to
configure new caches using the @CacheConfiguration annotation.

You can find all the details in the blog post:
http://in.relation.to/2018/04/17/hibernate-ogm-5-4-Alpha1-released/

Thanks,
Davide

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

[hibernate-dev] Jenkins Updates

[Davide D'Alto]

Hi,
I've run some updates on CI.

Everything seems to work fine but keep that in mind if something weird happens.

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

Re: [hibernate-dev] Why do we have the date in the URL of blog posts?

[Davide D'Alto]

By the way, if some articles are more technical and we put some effort
 in keeping them up-to-date,
we could put them in a separate section and just post in the blog
about their existence and updates.

Davide

On Thu, Mar 22, 2018 at 1:14 PM, Davide D'Alto <daltodav...@gmail.com> wrote:
>> I personally don't see the problem with dates in URLs. I don't see any
>> problem with not having them, either. But I do see a problem with changing
>> the URL scheme: potential dead links, SEO nightmare... We would need a damn
>> good reason to do it, and I'm not sure those you mentioned are enough...
>
> +1
>
>> In our case, the data works against us as people might think an article is
>> outdated by just inspecting the slug and thinking that
>> a 3 year-old article might not be relevant anymore.
>
> Even if you remove it from the URL, you still have the published date
> on every article. The user can still see when the article has been
> written.
> This makes sense because we are talking about blog posts.
>
> And this argument can also be used in favor of dates:
> without the date, you might give the impression that the article is
> always up-to-date and I don't think that's realistic.
>
> I'm not against changing it, but, unless we have some real reasons
> related to SEO or similar,
> I wouldn't worry too much. Most users are probably more interested to
> know when the article has been updated anyway (and not when has been
> published).
>
> Davide
>
> On Thu, Mar 22, 2018 at 12:24 PM, Yoann Rodiere <yo...@hibernate.org> wrote:
>>> The data in the post slug only makes sense for news sites where posts are
>> highly associated to a given date.
>>
>> A lot of our posts are. Release announcements and weekly newsletters in
>> particular.
>>
>> I personally don't see the problem with dates in URLs. I don't see any
>> problem with not having them, either. But I do see a problem with changing
>> the URL scheme: potential dead links, SEO nightmare... We would need a damn
>> good reason to do it, and I'm not sure those you mentioned are enough...
>>
>> On Thu, 22 Mar 2018 at 12:29 Vlad Mihalcea <mihalcea.v...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> The data in the post slug only makes sense for news sites where posts are
>>> highly associated to a given date.
>>>
>>> In our case, the data works against us as people might think an article is
>>> outdated by just inspecting the slug and thinking that
>>> a 3 year-old article might not be relevant anymore.
>>>
>>> It's better if we use simple slug names that capture the article focus
>>> keywords and remove the date altogether.
>>>
>>> Vlad
>>>
>>> On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling <gun...@hibernate.org>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > While talking to a few bloggers from the Java ecosphere at JavaLand last
>>> > week, the question came up why we have the date in the URL of blog posts.
>>> >
>>> > Arguably, it doesn't add value there (we show the date on the actual
>>> posts
>>> > themselves), and makes the URLs slightly worse to read. In particular, we
>>> > don't allow for browsing posts by year or month (e.g.
>>> > http://in.relation.to/2018/), so it's even a bit misleading. Omitting
>>> the
>>> > date would also make the original idea of the URL fly again ("in relation
>>> > to xyz").
>>> >
>>> > Anyone with thoughts whether we should change the scheme (keeping
>>> existing
>>> > ones of course)?
>>> >
>>> > That all said, I've no idea whether the date in there is good to have or
>>> > not in terms of SEO. I suppose it doesn't matter.
>>> >
>>> > --Gunnar
>>> > ___
>>> > 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
>>>
>> --
>> Yoann Rodiere
>> yo...@hibernate.org / yrodi...@redhat.com
>> Software Engineer
>> Hibernate NoORM team
>> ___
>> 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] Why do we have the date in the URL of blog posts?

[Davide D'Alto]

> I personally don't see the problem with dates in URLs. I don't see any
> problem with not having them, either. But I do see a problem with changing
> the URL scheme: potential dead links, SEO nightmare... We would need a damn
> good reason to do it, and I'm not sure those you mentioned are enough...

+1

> In our case, the data works against us as people might think an article is
> outdated by just inspecting the slug and thinking that
> a 3 year-old article might not be relevant anymore.

Even if you remove it from the URL, you still have the published date
on every article. The user can still see when the article has been
written.
This makes sense because we are talking about blog posts.

And this argument can also be used in favor of dates:
without the date, you might give the impression that the article is
always up-to-date and I don't think that's realistic.

I'm not against changing it, but, unless we have some real reasons
related to SEO or similar,
I wouldn't worry too much. Most users are probably more interested to
know when the article has been updated anyway (and not when has been
published).

Davide

On Thu, Mar 22, 2018 at 12:24 PM, Yoann Rodiere  wrote:
>> The data in the post slug only makes sense for news sites where posts are
> highly associated to a given date.
>
> A lot of our posts are. Release announcements and weekly newsletters in
> particular.
>
> I personally don't see the problem with dates in URLs. I don't see any
> problem with not having them, either. But I do see a problem with changing
> the URL scheme: potential dead links, SEO nightmare... We would need a damn
> good reason to do it, and I'm not sure those you mentioned are enough...
>
> On Thu, 22 Mar 2018 at 12:29 Vlad Mihalcea  wrote:
>
>> Hi,
>>
>> The data in the post slug only makes sense for news sites where posts are
>> highly associated to a given date.
>>
>> In our case, the data works against us as people might think an article is
>> outdated by just inspecting the slug and thinking that
>> a 3 year-old article might not be relevant anymore.
>>
>> It's better if we use simple slug names that capture the article focus
>> keywords and remove the date altogether.
>>
>> Vlad
>>
>> On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling 
>> wrote:
>>
>> > Hi,
>> >
>> > While talking to a few bloggers from the Java ecosphere at JavaLand last
>> > week, the question came up why we have the date in the URL of blog posts.
>> >
>> > Arguably, it doesn't add value there (we show the date on the actual
>> posts
>> > themselves), and makes the URLs slightly worse to read. In particular, we
>> > don't allow for browsing posts by year or month (e.g.
>> > http://in.relation.to/2018/), so it's even a bit misleading. Omitting
>> the
>> > date would also make the original idea of the URL fly again ("in relation
>> > to xyz").
>> >
>> > Anyone with thoughts whether we should change the scheme (keeping
>> existing
>> > ones of course)?
>> >
>> > That all said, I've no idea whether the date in there is good to have or
>> > not in terms of SEO. I suppose it doesn't matter.
>> >
>> > --Gunnar
>> > ___
>> > 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
>>
> --
> Yoann Rodiere
> yo...@hibernate.org / yrodi...@redhat.com
> Software Engineer
> Hibernate NoORM team
> ___
> 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] CI Updates

[Davide D'Alto]

I'm going to run some updates on CI this Friday.

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

Re: [hibernate-dev] NoORM - Improve consistency of our pom files with JBoss parent and WildFly parent

[Davide D'Alto]

Sure, thanks

On Mon, Mar 5, 2018 at 11:37 AM, Guillaume Smet
 wrote:
> Hi,
>
> So, I started the effort of making our version properties consistent with
> JBoss parent/WildFly parent with Search but the idea is to generalize this
> to all our NoORM projects and be as consistent as possible between the
> projects.
>
> The idea is to, as much as possible, use the exact same notation as the
> other JBoss projects when declaring the version properties of our
> dependencies
>
> You can see what it implies in this diff:
> https://github.com/hibernate/hibernate-search/pull/1639/files#diff-600376dffeb79835ede4a0b285078036R184
>
> So, from now on, when you need to add new dependencies in Search:
> - check if JBoss parent or WildFly parent already contains this dependency,
> if so use the exact same property name
> - if not, use  if it is descriptive and
> discriminating enough
> - if the package name is used for several artifacts or is not descriptive
> enough, use 
>
> My plan is to be done with OGM in 2 weeks and do it for HV 6.1 as I don't
> want to do it in a micro.
>
> So please avoid big pom refactorings in OGM for the next 2 weeks.
> Dependency upgrades are OK, I'll merge them along the way.
>
> Thanks!
>
> --
> Guillaume
> ___
> 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] [OGM] Validating our artifacts don't rely on JBoss-only dependencies

[Davide D'Alto]

Not sure about it, those are specific integration tests for infinispan remote.
The integrationtest folder is more to test the hibernate-ogm-modules
and have some
checks that the dialects work with WildFly really.

> after all, since they need a running Infinispan server
to work.

All the tests in Hibernat OGM are basically integration tests, except
for embedded databases
they need a remote db to work.

In fact, I think it was a mistake to put them in the maven test phase.
They should be in the integration-test one.

Can't we keep them in the same module but in a different profile
disabled by default?
Actually, it should already skip them with the option skipITs.

On Thu, Feb 22, 2018 at 11:07 AM, Yoann Rodiere  wrote:
> Hello,
>
> TL;DR: can I move hibernate-ogm-infinispan-remote tests to the
> integrationtest module, since they are actually integration tests?
>
> During one of our previous IRC meetings, I mentioned that we did some
> changes in the Hibernate Search POMs to remove the need for custom settings
> when building. The idea was to hard-code the JBoss repositories in the POMs
> of modules that need them, so that other modules would be built using Maven
> Central only. This way, we would make sure our modules only rely on
> dependencies that are available in Maven Central, not some obscure
> artifacts only available in the JBoss Maven repository.
>
> I am trying to do the same in OGM, but there is one problem: for this to be
> possible at all, integration tests that do require those exotic
> dependencies need to be in a separate Maven module.
> It turns out some tests implemented in the infinispan-remote module require
> to spin up an Infinispan server, which does have exotic dependencies (it's
> basically a WildFly server, if I understood correctly).
>
> Thus, in order to remove the need for custom settings when building, I
> would need to move those tests to the integrationtest module. They are
> integration tests, after all, since they need a running Infinispan server
> to work.
>
> Would anyone object to that?
>
>
> --
> Yoann Rodiere
> yo...@hibernate.org / yrodi...@redhat.com
> Software Engineer
> Hibernate NoORM team
> ___
> 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] Hibernate OGM 5.1 Final is out

[Davide D'Alto]

I’m happy to announce the latest stable release of Hibernate OGM:
Hibernate OGM 5.1 Final

== What’s new compared to 5.0 Final?

I’m glad you asked, this version:

- uses Hibernate ORM 5.1
- supports Infinispan Remote via the Hot Rod protocol
- supports Neo4j remote via the Bolt protocol and the Http interface
- can integrate with Hibernate Search 5.6, which works with Elasticsearch
- reduces the number of database calls by grouping the operations
- supports aggregation in MongoDB native queries with CLI syntax

More details in the blog post:
http://in.relation.to/2017/03/02/hibernate-ogm-5-1-Final-released/

Thanks,
Davide

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

[hibernate-dev] Favicon on CI

[Davide D'Alto]

hi,
not critical, but I've upgraded the plugin for the Theme on Jenkins
and it is now possible to add a favicon from Jenkins settings page.

Just thought of mentioning it here in case we want to change the default one.

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

[hibernate-dev] Hibernate OGM integration with ORM 5.3

[Davide D'Alto]

Hi,
I'm working on the integration with ORM 5.3 and I've created a branch
where I'm applying the changes.

You can see some initial discussions on the pull request I've sent as
preview: https://github.com/hibernate/hibernate-ogm/pull/961

I didn't find any specific issue with ORM 5.3 that could create a
problem for OGM so far.

Main problems are
1)  check the JpaCompliance property and behave the same way as ORM
from a user point of view when possible
2) Positional parameters can now start from 1
3) The method that creates the factory doesn't thow exceptions anymoew
and in OGM we will have to do something similar when the OGM provider
is used


Anyway, it doesn't seem that these issues require changes in ORM.
I still have to update the integration tests with WildFly, so
something else might appears.

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

Re: [hibernate-dev] ORM CI jobs - erroneous github triggers

[Davide D'Alto]

I can have a look at this issue.

If you have any suggestions, let me know.

Thanks

On Tue, Feb 13, 2018 at 2:22 PM, Sanne Grinovero  wrote:
> Unfortunately we have to reopen this thread. The issue is affecting us
> again (since some weeks I think) and in larger scale, affecting all
> builds. I guess it means the previous workaround is no longer
> effective after some of the recent Jenkins / plugins updates.
>
> On IRC we where wondering if we could fix this issue ourselves, or if
> it's even possible with the metadata that GitHub provides. I'm not
> sure of that but since we have the impression this previously worked
> fine, maybe the metadata is available?
>
> I won't have time for this this week but if someone else wishes to
> look into it I can give some pointers, let me know.
>
> Thanks,
> Sanne
>
>
> On 4 January 2018 at 12:09, Sanne Grinovero  wrote:
>> Also these jobs were configured to build automatically every 5 hours:
>>  - hibernate-orm-4.2-h2
>>  - hibernate-orm-4.3-h2
>>
>> I removed the schedule, they will be built when (and only when)
>> anything is committed to their respective branches.
>>
>>
>> On 3 January 2018 at 19:15, Steve Ebersole  wrote:
>>> Nice!  Glad you found something.  Thanks for making the changes.
>>>
>>>
>>>
>>> On Wed, Jan 3, 2018 at 12:16 PM Sanne Grinovero  wrote:

 I've made the change on:
- hibernate-orm-5.0-h2
- hibernate-orm-5.1-h2
- hibernate-orm-master-h2-main

 Let's see if it helps, then we can figure out a way to check all jobs
 are using this workaround.


 On 3 January 2018 at 18:12, Sanne Grinovero  wrote:
 > Hi Steve,
 >
 > this rings a bell, we had this bug in the past and apparently it's
 > regressed again :(
 >
 > The latest Jenkins bug seems to be:
 >  - https://issues.jenkins-ci.org/browse/JENKINS-42161
 >
 > I'll try the suggested workarount, aka to enable SCM poll without any
 > frequency.
 >
 > Thanks,
 > Sanne
 >
 >
 > On 3 January 2018 at 17:35, Steve Ebersole  wrote:
 >> So I just pushed to the ORM master branch, which has caused the
 >> following
 >> jobs to be queued up:
 >>
 >>
 >>- hibernate-orm-5.0-h2
 >>- hibernate-orm-5.1-h2
 >>- hibernate-orm-master-h2-main
 >>
 >> Only one of those jobs is configured to "watch" master.  So why do
 >> these
 >> other jobs keep getting triggered?
 >>
 >> I see the same exact thing on my personal fork as well.  At the same
 >> time I
 >> pushed to my fork's 5.3 branch, which triggered the 6.0 job to be
 >> queued.
 >>
 >>
 >>
 >> On Tue, Jan 2, 2018 at 1:54 PM Steve Ebersole 
 >> wrote:
 >>
 >>> The legacy ORM jobs (5.1-based ones at least) are getting triggered
 >>> when
 >>> they should not be.  Generally they all show they the run is triggered
 >>> by a
 >>> "SCM change", but it does not show any changes.  The underlying
 >>> problem
 >>> (although I am at a loss as to why) is that there has indeed been SCM
 >>> changes pushed to Github, but against completely different branches.
 >>> As
 >>> far as I can tell these job's Github setting are correct.  Any ideas
 >>> what
 >>> is going on?
 >>>
 >>> This would not be such a big deal if the CI environment did not
 >>> throttle
 >>> all waiting jobs down to one active job.  So the jobs I am actually
 >>> interested in are forced to wait (sometimes over an hour) for these
 >>> jobs
 >>> that should not even be running.
 >>>
 >>>
 >>>
 >> ___
 >> 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] Jenkins Updates on Friday

[Davide D'Alto]

Hi,
I'm going to run some updates on Jenkins this Friday.

They are minor updates and should be painless but you never know.

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

Re: [hibernate-dev] Jenkins updates tomorrow

[Davide D'Alto]

CSS should be fixed as well now.

There was a problem when going to the Nodes page where the buttons
overlapped with the logout link.

Let me know if there is something else weird.

Cheers,
Davide

On Fri, Feb 9, 2018 at 7:23 PM, Davide D'Alto <dav...@hibernate.org> wrote:
> I finished the Jenkins upgrades, I'm working on fixing some CSS issues.
>
> If you have some problems with the Jobs, let me know.
>
> Cheers,
> Davide
>
> On Thu, Feb 8, 2018 at 3:48 PM, Guillaume Smet <guillaume.s...@gmail.com> 
> wrote:
>> Thanks for warning and thanks for doing the update!
>>
>>
>> On Thu, Feb 8, 2018 at 4:34 PM, Davide D'Alto <dav...@hibernate.org> wrote:
>>>
>>> Hi,
>>> I'm planning to update Jenkins tomorrow, it should painless but, just in
>>> case,
>>> expect possible disruptions.
>>>
>>> Cheers,
>>> Davide
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins updates tomorrow

[Davide D'Alto]

I finished the Jenkins upgrades, I'm working on fixing some CSS issues.

If you have some problems with the Jobs, let me know.

Cheers,
Davide

On Thu, Feb 8, 2018 at 3:48 PM, Guillaume Smet <guillaume.s...@gmail.com> wrote:
> Thanks for warning and thanks for doing the update!
>
>
> On Thu, Feb 8, 2018 at 4:34 PM, Davide D'Alto <dav...@hibernate.org> wrote:
>>
>> Hi,
>> I'm planning to update Jenkins tomorrow, it should painless but, just in
>> case,
>> expect possible disruptions.
>>
>> Cheers,
>> Davide
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Jenkins updates tomorrow

[Davide D'Alto]

Hi,
I'm planning to update Jenkins tomorrow, it should painless but, just in case,
expect possible disruptions.

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

[hibernate-dev] Hibernate OGM 5.2 CR1 has been released!

[Davide D'Alto]

Hibernate OGM 5.2 CR1 is arrived!

This will become the next 5.2 Final soon and we added support for
Geospatial integration and new native operator support with MongoDB,
Neo4j queries performance improvements and integration with cluster
counters for Infinispan embedded.

More details in the blog post:
http://in.relation.to/2018/01/29/hibernate-ogm-5-2-CR1-released/

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

Re: [hibernate-dev] Jenkins job priorities

[Davide D'Alto]

Well done, thanks a lot.


On Fri, Jan 12, 2018 at 8:12 AM, Yoann Rodiere  wrote:
> Quick update: the priority plugin seems to be working fine, and I disabled
> the Heavy Job plugin. It turns out the Heavy Job plugin was preventing the
> Amazon EC2 plugin to spin up new slaves, probably because the Amazon EC2
> plugin only saw two empty slots on an existing slave and couldn't
> understand that the waiting jobs couldn't be ran with only two slots.
> Consequently, the Amazon EC2 plugin now spins up lots of instances, with a
> limit of 5. In order to avoid a big hit on the budget, Sanne reduced the
> idle timeout to 30 minutes. Please allow 2 minutes for the slave to boot if
> there is no slave up when you start your job.
>
> So now we have working Amazon EC2 plugin, ensuring new slaves will be spun
> up if there are waiting jobs, and a priority queue, ensuring release/PR
> jobs will be ran first in the (hopefully unlikely) event a lot of jobs are
> waiting in the queue.
> It looks like a reasonable setup, so let's see how it goes for the next
> releases and discuss it afterwards.
>
>
> On Wed, 10 Jan 2018 at 17:46 Steve Ebersole  wrote:
>
>> I know ;)
>>
>> Anyway I do agree that any release jobs should be given the highest
>> priority in the job queue
>>
>> On Wed, Jan 10, 2018, 10:29 AM Guillaume Smet 
>> wrote:
>>
>> > On Wed, Jan 10, 2018 at 5:00 PM, Steve Ebersole 
>> > wrote:
>> >
>> >> And in advance I say I would not be cool with you killing my jobs for
>> >> your job to run
>> >>
>> >
>> > Yeah, that was my understanding.
>> >
>> > I don't expect anyone to be cool with it.
>> >
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
> --
> Yoann Rodiere
> yo...@hibernate.org / yrodi...@redhat.com
> Software Engineer
> Hibernate NoORM team
> ___
> 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] Awestruct upgrade to version 0.5.7

[Davide D'Alto]

Thanks,
I will only add the additional commits I made.



On Wed, Jan 10, 2018 at 11:45 AM, Guillaume Smet
<guillaume.s...@gmail.com> wrote:
> Thanks for taking care of that.
>
> I clicked here and there, especially on the complex pages, and it looks good
> to me.
>
> Be careful when merging, we don't want the Corporate contributors page on
> the public website yet.
>
> Thanks!
>
> --
> Guillaume
>
> On Wed, Jan 10, 2018 at 12:25 PM, Davide D'Alto <dav...@hibernate.org>
> wrote:
>>
>> Just to clarify, The websites to check are:
>> http://staging.in.relation.to and http://staging.hibernate.org
>> Sorry, I forgot to add the links in the previous mail.
>>
>>
>> On Wed, Jan 10, 2018 at 11:08 AM, Davide D'Alto <dav...@hibernate.org>
>> wrote:
>> > Hello,
>> > I've upgraded awestruct to version 0.5.7.
>> >
>> > Except for the minification of our stylesheets it seems to work fine
>> > but It would be nice if someone else can have a look at generate site
>> > and confirm to me that's
>> > OK to apply the changes in production.
>> >
>> > On the same note, I've noticed that we are using some custom
>> > extensions to execute the minification, specifically the one in
>> > _ext/css_minifier.rb.
>> >
>> > Is there any reason to do that? I'm asking because Awestruct comes
>> > with its own minification class called: Awestruct::Extension::Minify
>> >
>> > The main difference I noticed is that this extension doesn't copy the
>> > original file during deploy on the server and only uses the minified
>> > one.
>> > Also currently, this extension doesn't work for CSS but I guess they
>> > are going to fix it in the next releases (it works for html and js).
>> >
>> > Cheers,
>> > Davide
>> ___
>> 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] Jenkins job priorities

[Davide D'Alto]

> Let's not forget that many Apache projects take a week or two to
> perform a release, we all know of other projects needing months, so by
> the law of diminishing returns I don't think we should invest much
> more of out time to shave on the 10 minutes.. just spin up some extra
> nodes :)

+1



On Wed, Jan 10, 2018 at 11:08 AM, Sanne Grinovero  wrote:
> On 10 January 2018 at 10:25, Guillaume Smet  wrote:
>> Hi,
>>
>> On Wed, Jan 10, 2018 at 11:06 AM, Yoann Rodiere  wrote:
>>>
>>> I hope we will be able to use this priority feature instead of the Heavy
>>> Job plugin (which allows to assign weights to jobs), and avoid concurrent
>>> builds completely. With the current setup, someone releasing his/her
>>> project will only have to wait for the currently executing build to finish,
>>> and will get the highest priority on the release builds. Maybe this is
>>> enough? If you disagree, please raise your concerns now: I will disable the
>>> Heavy Job plugin soon and set each slave to only offer one execution slot.
>
> Thanks Yoann! that sounds great.
>
>>>
>>
>> I'm not really convinced by this solution. Some jobs still take quite a lot
>> of time and having to wait 20 minutes for each job I would trigger is a bit
>> annoying.
>>
>> If it was for only one job, it would be acceptable, but let's take the
>> worst case of a coordinated HV release :
>> - TCK release
>> - API release
>> - HV release
>> - website
>> - blog
>>
>> I won't have to wait for each of them as some of them will be grouped by
>> the prioritization but I'm pretty sure I will have to wait for several of
>> them.
>>
>> So, I'm +1 on having this plugin as it seems to be helpful on its own but
>> I'm -1 on considering it is a solution to the "let's roll a release" thing.
>
> Some of our test suites used to take 2 hours to run (even 5 days some
> years ago); now you say waiting 20 minutes is not good enough? You'll
> have to optimise our code better :P
>
> It's very easy to spin up extra nodes; my recommendation is that when
> you know you're about to release [for example approximately one hour
> in advance while you might be double-checking JIRA state and such
> things] hit that manual scale-up button and have CI "warmed up" with
> one or two extra nodes.
>
> By the time you need to trigger the release job you'll have the build
> queue flushed, the priority plugin helping you out, and still
> additional extra slaves running to run it all in parallel.
>
> And of course for many releases we don't care for an extra 30 minutes
> so you're free to skip this all if it's not important; incidentally
> for "work in progress" milestones like the module packs which we
> recently re-released several times while polishing up the PR I've been
> releasing from my local machine; it's good to have CI automate things
> but I don't think we should get in a position to require 100%
> availability from CI: practice releases locally sometimes.
>
> If we really wanted to invest more in it (both time and budget),
> there's the option of spinning up new containers for each job as soon
> as you need one but I feel like we've spent too much time on CI
> already; such technology is maturing so my take is let it mature a bit
> more, and in 6 months we'll do another step of improvement; jumping on
> those things makes us otherwise the beta testers and steals critical
> time from our own projects.
> Let's not forget that many Apache projects take a week or two to
> perform a release, we all know of other projects needing months, so by
> the law of diminishing returns I don't think we should invest much
> more of out time to shave on the 10 minutes.. just spin up some extra
> nodes :)
>
> Thanks,
> Sanne
>
>>
>> --
>> Guillaume
>> ___
>> 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] Awestruct upgrade to version 0.5.7

[Davide D'Alto]

Hello,
I've upgraded awestruct to version 0.5.7.

Except for the minification of our stylesheets it seems to work fine
but It would be nice if someone else can have a look at generate site
and confirm to me that's
OK to apply the changes in production.

On the same note, I've noticed that we are using some custom
extensions to execute the minification, specifically the one in
_ext/css_minifier.rb.

Is there any reason to do that? I'm asking because Awestruct comes
with its own minification class called: Awestruct::Extension::Minify

The main difference I noticed is that this extension doesn't copy the
original file during deploy on the server and only uses the minified
one.
Also currently, this extension doesn't work for CSS but I guess they
are going to fix it in the next releases (it works for html and js).

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

Re: [hibernate-dev] Keeping CI from being confusing.

[Davide D'Alto]

I think using "Slave" alone might be goo enough.
It's generic and in the future, if we have some other different clouds,
jobs can use some additional labels to be more specific

At the moment, I think the only labels we need are: Master, Slave and HANA

On Sat, Dec 16, 2017 at 8:03 PM, Steve Ebersole  wrote:
> Perhaps I am just dense here, but I still have no idea what you are
> expecting me to use as the label for my ORM jobs
>
>
> On Sat, Dec 16, 2017 at 12:53 PM Sanne Grinovero 
> wrote:
>
>> On 16 December 2017 at 16:44, Steve Ebersole  wrote:
>> > For the main ORM job I see someone changed the label to "AWS&",
>> which
>> > is obviously different from the "Slave" label you recommended.
>> Basically at
>> > this point I am completely lost as to what to use for these labels.
>>
>> We used to have machines on either OS1 or AWS (two different clouds).
>> ORM jobs used to require AWS as only the nodes on AWS have enough
>> memory.
>> Today using "AWS" is fine but not required as all our nodes are on AWS.
>>
>> >
>> > Since I did not add this "AWS&" I am going to leave it alone.  For
>> the
>> > other ORM jobs, I do see many have the "OS1" label.  I can fix those to
>> > "Slave".  But I have to ask... if "Slave" is the more appropriate value
>> for
>> > the vast majority of builds, can't that just be the default?  What if we
>> > leave off the label?  As you say, labels are supposed to indicate that
>> the
>> > job "requires such capabilities" as in the capabilities implied by that
>> > label.  But if a job has no such requirement, why is it a requirement to
>> add
>> > any label?
>>
>> The machine identified as "Master" actually runs the ci.hibernate.org
>> main service and various other important services (e.g.
>> in.relation.to) so we'd like to keep any non necessary load from it;
>> also it doesn't have all the databases installed which many jobs might
>> need.
>> The only reason it's listed as a node capable to run a CI job at all
>> is that it's useful to keep it available for some specific jobs,
>> specifically we had problems with urgent changes to the website
>> getting stuck in a long and busy build queue; the decision was to
>> allow website publication jobs to be executed directly by the master
>> node.
>> Essentially, it helps with priorities.
>>
>> >
>> > On Tue, Dec 12, 2017 at 6:31 AM Sanne Grinovero 
>> wrote:
>> >>
>> >> I see many jobs are still explicitly configured to request a build on
>> >> slaves tagged as "OS1".
>> >>
>> >> Please get rid of that: we have no longer any slave running on OS1,
>> >> some of the new slaves use the "OS1" label to allow a smooth migration
>> >> - but it's a lie and it's been a long time since we removed OS1.
>> >>
>> >> I will need to eventually cleanup such things, as it's getting messy
>> >> and confusing.
>> >>
>> >> Labels are expected to be used to tag specific slaves to have specific
>> >> capabilities, so that some jobs can flag they require such
>> >> capabilities.
>> >>
>> >> Typically the only label you need is "Slave" as we don't want most
>> >> jobs to run on the master node.
>> >>
>> >> An example of a valid label is "HANA" for the job running integration
>> >> tests on the HANA database; for obvious reasons this job needs to be
>> >> run on the only slave actually having HANA running.
>> >>
>> >> While at it, if you installed any Jenkins plugin which you no longer
>> >> need please remove it.
>> >>
>> >> General reminder: there's no dedicated team to keep CI or
>> >> infrastructure running efficiently, we're all responsible so try to
>> >> dedicate it some 20 minutes every month making sure your jobs are
>> >> still necessary and configurations are up to date.
>> >> For more extensive operations ask Davide or myself and we'll see to
>> help.
>> >>
>> >> Thanks,
>> >> Sanne
>> >> ___
>> >> 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] Getting rid of our specific JavaDoc CSS?

[Davide D'Alto]

Sounds good to me.


On Thu, Nov 30, 2017 at 3:11 PM, Guillaume Smet
 wrote:
> Hi,
>
> So, apparently, our JavaDoc CSS is a bit outdated as we now have a "Skip
> navigation links" link at the top of our doc that should be hidden by
> default.
>
> Frankly, I see very little value in maintaining our own JavaDoc CSS. It
> requires work (see above and the future JDK 9 upgrade - Marko did a first
> pass on Validator but it required some time).
>
> Moreover, I find the new default CSS much more readable and attractive than
> ours.
>
> Compare:
> https://docs.jboss.org/hibernate/stable/search/api/
> with:
> http://docs.jboss.org/jberet/1.3.0.Beta2/javadoc/jberet-core/
>
> I would say a JavaDoc is a JavaDoc and I would prefer if our users just got
> the standard layout they are used to on other projects.
>
> Bonus point: when we include external projects javadoc in ours, we end up
> having both layouts mixed, which is not very nice.
>
> And if it saves us some work, it's all good, isn't it?
>
> Thoughts?
>
> --
> Guillaume
> ___
> 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] Hibernate OGM 5.2 Beta1 Release

[Davide D'Alto]

HIbernate OGM 5.2 Beta1 is ready!

This version is compatible with Infinispan 9.1 and it makes it
possible to create caches when they are missing on the remote server

All the details in the blog post:
http://in.relation.to/2017/10/17/hibernate-ogm-5-2-Beta1-released/

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

Re: [hibernate-dev] Property "ogm.datastore.create_database": fit for purpose?

[Davide D'Alto]

I'm working on it.



On Tue, Oct 10, 2017 at 11:36 AM, Guillaume Smet
 wrote:
> On Wed, Sep 27, 2017 at 2:55 PM, Sanne Grinovero  wrote:
>> But essentially looks we're on the same page about using HBM2DDL_AUTO
>> and ignoring "create_database" for the sake of practical usage.
>
> Just to be sure, in the end, did we do it?
>
> --
> Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Property "ogm.datastore.create_database": fit for purpose?

[Davide D'Alto]

> Thanks, but before you jump onto specifics of feasability, do we agree
> that "create_database" as a name is not good for Infinispan ?

Well, we are using infinispan as a database, it's not an ideal name
but it is not so terrible considering
that we are trying to use a single property for all the dialects.

I guess I didn't understand what you are proposing, the issue I linked is about:

1. Use HBM2DDL_AUTO for database and "table" creation
2. Remove create_database

Isn't that what you asked initially?

I'm inclined to have a distinct property for each dialect,  the only
thing that I don't like about it
is that we will have several properties doing the same thing
(basically, create what's missing).

On Wed, Sep 27, 2017 at 10:26 AM, Sanne Grinovero <sa...@hibernate.org> wrote:
> On 27 September 2017 at 10:23, Davide D'Alto <dav...@hibernate.org> wrote:
>>> Let the fight begin!
>>
>> I don't think we have to fight about it:
>> https://hibernate.atlassian.net/browse/OGM-571
>>
>> It wasn't possible to use Environment.HBM2DDL_AUTO when we introduced
>> the property,
>> it should be possible now.
>>
>> I'll have a look at it. It seems gunnar had a branch with something
>> already done.
>
> Thanks, but before you jump onto specifics of feasability, do we agree
> that "create_database" as a name is not good for Infinispan ?
>
> Sanne
>
>>
>> Davide
>>
>> On Wed, Sep 27, 2017 at 9:55 AM, Guillaume Smet
>> <guillaume.s...@gmail.com> wrote:
>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero <sa...@hibernate.org>
>>> wrote:
>>>
>>>> In fact
>>>> I'd like to simply use Environment.HBM2DDL_AUTO to create / define
>>>> Caches ?
>>>>
>>>
>>> Makes sense to me.
>>>
>>> --
>>> Guillaume
>>> ___
>>> 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] Property "ogm.datastore.create_database": fit for purpose?

[Davide D'Alto]

> Let the fight begin!

I don't think we have to fight about it:
https://hibernate.atlassian.net/browse/OGM-571

It wasn't possible to use Environment.HBM2DDL_AUTO when we introduced
the property,
it should be possible now.

I'll have a look at it. It seems gunnar had a branch with something
already done.

Davide

On Wed, Sep 27, 2017 at 9:55 AM, Guillaume Smet
 wrote:
> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero 
> wrote:
>
>> In fact
>> I'd like to simply use Environment.HBM2DDL_AUTO to create / define
>> Caches ?
>>
>
> Makes sense to me.
>
> --
> Guillaume
> ___
> 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] New layout for the website

[Davide D'Alto]

Overall it looks great and I think it can be merged as it is and wee
can fix anything else later.

The major thing that I don't think it is working is the use of the
coloured background in some texts.

I think this page highlights well the problem:
http://new.hibernate.org/ogm/documentation/

There is a background behind the title, the subtitle, the release
version and the  "Documentation".
The end result is that it's hard to understand what's a link or button
and therefore can be clicked.

I think it would work better without any background colour.

I like the documentation page, I was surprised that we didn't use the
same approach for the releases page.

Thanks,
Davide







On Tue, Sep 26, 2017 at 12:37 PM, Christian Beikov
 wrote:
> I like it, good work!
>
> As you already noticed yourself, there are some problems on mobile
> devices like images overlapping text and the menus being expanded, but
> other than that it already looks fine!
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 26.09.2017 um 13:19 schrieb Guillaume Smet:
>> Hi,
>>
>> Following Yoann's work and based on it, I tried to work on a new layout for
>> the website.
>>
>> The idea was to make it more modern while not starting a full discussion
>> about the content. I think we could benefit from making more iterative
>> improvements.
>>
>> I know a few things bother some people to who I already presented this
>> work, but this is what I would like to present as "my proposal for a new
>> website".
>>
>> I tried to take into account the remarks I found consistent with my vision
>> (which unfortunately prevents you to see my first ugly try at a new home
>> page, blame Sanne for that :)).
>>
>> I didn't change the content (except for reorganizing a few links in the
>> menu to put "Source code" before "Wiki" for instance). That's not the point
>> of this exercise.
>>
>> I added a short baseline on each About page. They are just placeholders,
>> better propositions very welcome!
>> The hero text below coming from the old site can also probably be tweaked
>> for the new layout.
>>
>> Generally I think some changes are due to the content but that's for
>> another day and for another discussion.
>>
>> To play with it:
>> http://new.hibernate.org/
>> with
>> 54.174.65.136 new.hibernate.org
>> in your /etc/hosts
>>
>> The branch on GitHub is "new-layout".
>>
>> I consider the conversion work completed, so if you see any issue, it's not
>> normal, please report it.
>>
>> The only thing I have in mind for the near future is to improve the mobile
>> experience but I think it can be kept as a second step. It's usable as of
>> now, even if not perfect.
>>
>
> ___
> 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] Hibernate OGM 5.2 Alpha1 release

[Davide D'Alto]

HIbernate OGM 5.2 Alpha1 is ready.

The first thing you will notice in this release is that several
dialects are not part of the core project anymore. We decided to focus
our work on the Infinispan, Neo4j and MongoDB dialects.

Highlights of the release:

- Fixed bugs related to polymorphic hierarchies
- Improved query performance in Neo4j
- Infinispan Remote dialect via Hot Rod now supports operation grouping
- Removed Fongo dialect
- Support map-reduce and distinct operations in MongoDB using the
MongoDB CLI query language

All the details in the blog post:
http://in.relation.to/2017/09/11/hibernate-ogm-5-2-Alpha1-released/

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

[hibernate-dev] CI Updates

[Davide D'Alto]

Hello,
I'm going to update Jenkins next Monday, I'll do my best to keep the
downtime to a minimum but,
because there are several plugins to update, I expect some disruption.
I'll do my best to keep it at a minimum

The exact date is going to be the 6th of August.

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

Re: [hibernate-dev] JDK 9 build 180 support

[Davide D'Alto]

Thanks Guillaume,

I've already copied the latest build on CI but the Job are still using
the previous one.

Can I make the switch?

On Mon, Jul 31, 2017 at 7:21 PM, Guillaume Smet
 wrote:
> Hi,
>
> To support the latest JDK 9, you need to upgrade the enforcer and javadoc
> plugins to 3.0.0-M1.
>
> See:
> https://github.com/hibernate/hibernate-validator/pull/822/commits/e94ecc1d05ed75dbd37bc000b337917dc7c23b17
>
> --
> Guillaume
> ___
> 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] "rebranding" the Hibernate Search "ram" directory

[Davide D'Alto]

+1 for moving it in the test library

Neo4j uses the term "impermanent" for its testing db.

I'm not a big fun of the "testing" in the name because it does not convey
the main characteristics of the directory; it only tells that you
should not use it in
production (why is it included in the main library then?).

My 0.02£


On Thu, May 18, 2017 at 6:05 PM, Sanne Grinovero  wrote:
> On 18 May 2017 at 17:31, Gunnar Morling  wrote:
>> Can't you just move it to the test JAR if it's for testing only?
>
> Interesting idea, we can try that as well.
>
> I'd still want to set the name straight though. Let's agree on a name first.
>
>>
>> Am 18.05.2017 6:29 nachm. schrieb "Sanne Grinovero" :
>>
>> Right technically it's not a unit test. But I'd like to focus on the
>> testing aspect, as "local-ram" might still convey concepts as "fast",
>> maybe even expect it to engage Infinispan's off-heap capabilities, or
>> just being an option to consider for other reasons.
>>
>> "testing" ?
>>
>> On 18 May 2017 at 17:20, Adrian Nistor  wrote:
>>> I agree, but probably "unit-testing" is not such a good name either.
>>> Technically, that's a functional test.
>>> I think I like "local-ram" better, implying that it is not
>>> shared/distributed and it is also volatile.
>>>
>>>
>>> On 05/18/2017 06:07 PM, Sanne Grinovero wrote:

 As anyone who's bothered to read the manual knows, the "ram" directory
 should really only be used for unit tests. The other implementations,
 while typically disk based, are also faster (memory mapped files) and
 more efficient (better locking design) so there's really no reason to
 use it, not even performance except for trivial, small, non important
 data sets.

 For example the Elasticsearch team is making sure of this by having
 totally removed the option of using the RAMDirectory - something I
 actually don't appreciate as our unit tests could benefit from it,
 having slow storage on our test environments.

 Tristan is reporting that the "ram" terminology is confusing people,
 not least in the Infinispan community as "RAM" might be ambiguous
 since everything is in memory, and people get surprised it's not
 replicated in the "in memory cluster".

 I wouldn't want to go to the extremes of the Elasticsearch team as I
 believe having this option is very useful, especially for testing.

 Should we rename (rebrand) its short name "ram" into "unit-testing" ?

 I suspect that would make people think a bit more before pushing it
 into production...


 Thanks,
 Sanne
>>>
>>>
>>>
>> ___
>> 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] Maven 3.2.5 on CI

[Davide D'Alto]

Hi,
We still have an old version of Maven installed on CI, is there
anybody using it?

Otherwise I would prefer to remove it.

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

[hibernate-dev] CI Updates on the 20th of April

[Davide D'Alto]

 I will run some updates on Jenkins next Thursday (20th of April).

This should remove the red Warning one sees when logged in.
Problem is that some plugins changed the way they store configuration
and it might affects some jobs.

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

Re: [hibernate-dev] [OGM] Hibernat OGM contrib repository

[Davide D'Alto]

If I understand correctly the consensus for the contrib dialects is:

* Keep the same group id of core: org.hibernate.ogm
* Keep the same license we use in OGM
* Create a repository per dialect: each repository will have it's own
life-cycle, it will depend on core and it won't impact the other
dialects.

I'm not sure if I like the idea to have a repository per dialect in
term of maintenance but it seems the most flexible approach.

Would that work for everybody?

Thanks,
Davide

On Tue, Apr 11, 2017 at 10:39 AM, Sanne Grinovero <sa...@hibernate.org> wrote:
> On 11 April 2017 at 10:24, Gunnar Morling <gun...@hibernate.org> wrote:
>> Hi,
>>
>> On the group id, I'd prefer to keep it as is. This will make it less
>> disruptive if dialects are demoted/promoted between contrib and core.
>> On the license I also think it needs to remain as is.
>
> +1
>
>> Overall, I'm still unsure what's the implication of the split and how
>> the lifecycle of dialects is going to look like. Will there be a
>> release of the contrib repo's dialects whenever core is released? What
>> does it mean if a dialect is in contrib? Will it be ensured that it
>> generally works with the latest OGM, but it will not benefit from any
>> new optimizations in core? How will people know which versions work
>> together?
>
> This is very important to clarify, as it's supposed to be "the" reason
> for the split.
>
> As far as I understood from our previous debates, the problem being
> addressed is that we have no bandwidth / interest in maintaining all
> of them.
> So if that's the case, I believe it's important that *we will allow*
> for the main repository to go ahead with new development and releases
> while not necessarily bringing the contrib dialects on par.
>
> This implies that the "contrib" dialects will not necessarily be
> released for each latest version of OGM and there might be gaps in
> compatibility.
>
> The problem I see with this, is that not all "contrib dialects" will
> be equal. So while someone might want to volunteer to bring dialect A
> up to speed with latest OGM versions, they will want to see it
> released and yet we might not have been able to update the other
> dialects in the contrib repository: the other dialects being in bad
> state shouldn't block the ones ready for a release.
>
> So we need to be able to release each contrib dialect independently. I
> probably wouldn't use a single repository for them, this clearly is a
> set of different projects depending on OGM/core.
>
>>
>> I'd probably be a good idea to have a document describing the policies
>> and lifecycles around these modules and the repo split.
>
> +1
>
>> Did you take a look at how it's done in Spring Data btw.? There they
>> have a repo per datastore, each with their own release cycle AFAIKU.
>> And then there are "release trains", which essentially is a family of
>> releases of the datastores, with all matching versions grouped in a
>> BOM.
>
> BOMs are dead. Long live modules!
>
> 
>
> +1 for trains, but allow gaps please.
> For example there might be no interest in getting all dialects updated
> for 5.2 - while they existed for 5.1 - and yet someone might want to
> restore some of them for 5.3.
>
>> That model seems the most flexible in terms of independent releases,
>> and it'd also allow to abandon a specific datastore if no one steps up
>> to maintain it (by excluding it from the next release train), but I
>> could imagine the plethora of repos and required releases doesn't make
>> it easy to manage necessarily.
>
> Thanks,
> Sanne
>
>
>>
>> --Gunnar
>>
>>
>>
>> 2017-03-28 13:08 GMT+02:00 Sanne Grinovero <sa...@hibernate.org>:
>>> Regarding the License I think we have no choice, we have to use the
>>> same license as alternatively we'd need to get permission to change
>>> the license as it's existing code.
>>> I'm assuming we have no interest in that, and if we had this process
>>> would take some time so we'd have to propose such a change as an
>>> independent step from the repository move.
>>>
>>> Regarding group-id : I see no reason to change it but have no strong
>>> opinion on that. I'd similarly suggest to make such changes as a
>>> follow-up though, and not treat it as a blocker.
>>> (If we decide to change it, it would be a breaking change so we'd need
>>> redirection poms so we might as well do it later)
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>> On 28 March 2017 at 11:28, Davide D'Alto <dav...@

Re: [hibernate-dev] Documentation for people not using dependency management tools

[Davide D'Alto]

I'm not against it but could you give an example?

I think it would help to clarify what you are talking about.

Thanks

On Wed, Mar 29, 2017 at 12:39 PM, Sanne Grinovero  wrote:
> I'm brushing up some OGM documentation, and noting that we regularly
> make examples for both people consuming Maven pom definitions, and
> people downloading our distribution and trying to figure out which
> jars they need.
>
> I am not aware of specific problems with the instructions we give, but
> they all look highly suspicious; instructions are incomplete at best
> as we don't go into details.
>
> And we don't test these either.. I'm confident that if I were to test
> these instructions most would be out of date.
>
> While I'm aware that some people still don't use dependency management
> tools; I'm inclined to remove these documentation sections and abandon
> this population to their fate... at least we'd be slimming down the
> docs a bit for the sake of most developers.
>
> Any strong objections?
>
> If we really want to keep these, it would be great to have a
> documentation section generated from the maven dependencies but I
> don't think this is our priority now.
>
> Thanks,
> Sanne
> ___
> 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] JIRA usage for OGM

[Davide D'Alto]

I would prefer to release both at the same time even if there are no
big changes.

As for creating a new project, wouldn't have a new label or component be enough?

On Fri, Mar 17, 2017 at 8:21 AM, Yoann Rodiere  wrote:
> Isn't marking those as "New feature" enough? Or, if necessary, tagging them?
> I obviously can't tell how others use JIRA, but personally I don't dive
> into old tickets every day. Most of the time I only check the new
> (incoming) tickets and those assigned to the next release. So, those extra
> tickets are only a problem when setting the goals for the next release, and
> we could easily tag them so as to exclude them from our searches.
>
> The actual question may be: when those tickets are solved, will they be
> released synchronously with OGM releases? I.e., will the contrib repository
> be released at the same time as OGM? If not, then yes, I'd say we'd better
> move these tickets to another JIRA project.
>
>
> Yoann Rodière 
> Hibernate NoORM Team
>
> On 16 March 2017 at 14:14, Sanne Grinovero  wrote:
>
>> There are more than 300 open issues, which is fine but rather than
>> being these well-defined issues most sound like wishful thinking of
>> someone having a (possibly cool) idea but not really executing on it.
>>
>> Since JIRA is an issue tracker and not really a planning tool / note
>> taking app I wish we could limit this practice of having issues like
>> "explore integration with.." ?
>>
>> More specifically, could we move "out of the way" all issues related
>> to Databases which we're moving into the "contrib" repository?
>> I think it would be nice to have these in a different JIRA project.
>>
>> Thanks,
>> Sanne
>> ___
>> 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] [OGM] WildFly modules imposing versions

[Davide D'Alto]

I'll have a look,I would expect that modules with the same family would work.

I suspect we used the specific version instead of the family version somewhere,
I'll check

Davide

On Tue, Mar 7, 2017 at 9:43 AM, Emmanuel Bernard  wrote:
> I’ve upgraded the OGM demo to OGM 5.1 Final (from CR1).
>
> Again I’ve got deployment errors because it does not find the specific search 
> version: 5.6.1.Final. I had 5.6.0.Final in my WF module deployment.
> Is that the behavior we want? Do we want the OGM module to impose specific 
> versions of Hibernate Search to work? I don’t even use Hibernate Search for 
> the demo…
>
> How can we improve things?
>
> Emmanuel
> ___
> 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] Removing the BlueOcean plugin on CI

[Davide D'Alto]

I suspect the WildFLy instance was still active because I've aborted
the job or restarted Jenkins at the wrong time while
appying the changes.

Speaking about the job weight, I didn't change the releases job, I'll
let the owners of each job to do that but I think it would make sense
to cahnge their weight to 2 (unless one don't mind to wait).

Thanks,
Davide

On Thu, Feb 23, 2017 at 10:24 AM, Sanne Grinovero <sa...@hibernate.org> wrote:
> Thanks Davide!
>
> All, we need your help now: please make sure that any job you enable
> which uses any network port (like using Byteman, Arquillian, WildFly,
> Databases, Elasticsearch, etc..) has set a "Job Weight" of 3.
>
> When failing to do so, we'll see sporadic failures of both your job
> and some other random job, so let's be nice to each other ;)
>
> I think the setup is not perfect yet, as I've reviewed some failure
> reports and they seem caused by an already running WildFly instance on
> the same machine. So either we have a bad job configuration somewhere,
> or a WildFly instance which didn't shut down correctly.
>
> Thanks,
> Sanne
>
>
>
> On 22 February 2017 at 21:48, Davide D'Alto <dav...@hibernate.org> wrote:
>> I've removed the Blue Ocean plugin.
>>
>> Let me know if there are still some problems.
>>
>> I've also configured the jobs so that the website jobs can be executed
>> in parallel with the  others.
>>
>> This should make publishing of a page faster.
>>
>> Cheers,
>> Davide
>>
>>
>> On Wed, Feb 22, 2017 at 10:47 AM, Davide D'Alto <dav...@hibernate.org> wrote:
>>> Hi.
>>> I'm going to remove the BlueOcean plugin from Ci.
>>>
>>> Currently, when we receive an email because a build is failed, the
>>> link to the job is wrong and it seems that BlueOcena is the cause.
>>>
>>> I don't think anybody is actually using it but if there are some
>>> objections, let me know.
>>>
>>> Regards,
>>> Davide
>> ___
>> 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] Removing the BlueOcean plugin on CI

[Davide D'Alto]

I've removed the Blue Ocean plugin.

Let me know if there are still some problems.

I've also configured the jobs so that the website jobs can be executed
in parallel with the  others.

This should make publishing of a page faster.

Cheers,
Davide


On Wed, Feb 22, 2017 at 10:47 AM, Davide D'Alto <dav...@hibernate.org> wrote:
> Hi.
> I'm going to remove the BlueOcean plugin from Ci.
>
> Currently, when we receive an email because a build is failed, the
> link to the job is wrong and it seems that BlueOcena is the cause.
>
> I don't think anybody is actually using it but if there are some
> objections, let me know.
>
> Regards,
> Davide
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Removing the BlueOcean plugin on CI

[Davide D'Alto]

Hi.
I'm going to remove the BlueOcean plugin from Ci.

Currently, when we receive an email because a build is failed, the
link to the job is wrong and it seems that BlueOcena is the cause.

I don't think anybody is actually using it but if there are some
objections, let me know.

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

[hibernate-dev] Update JDK 9 to build 154 on CI

[Davide D'Alto]

Are there any problems if I update the JDK 9 on Jenkins?

Let me know,
Davide
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Blog posts not featured on the hibernate.org website

[Davide D'Alto]

Great, thanks

On Wed, Feb 1, 2017 at 3:38 PM, Guillaume Smet  wrote:
> Hi,
>
> FYI, I just fixed the issue and the blogs posts are now featured on the
> website again.
>
> The good news:
> - we don't rely on an external service anymore
> - there is no cache so new blog posts are displayed on the website as soon
> as the blog post is published
>
> The in.relation.to blog now generates static jsonp feeds that are consumed
> by the website.
>
> For those interested:
> -
> https://github.com/hibernate/in.relation.to/commit/c50acd51dd84ef0dad1cd9798108f0ec85a525ab
> -
> https://github.com/hibernate/hibernate.org/commit/2a6b41e83c0308440837633d25b14a5ea87a289b
>
> --
> Guillaume
> ___
> 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] Update Jenkins plugins

[Davide D'Alto]

I didn't have time to do it.

I'll postponed the updates to next week: the 9th of February

Thanks,
Davide

On Tue, Jan 17, 2017 at 4:56 PM, Davide D'Alto <dav...@hibernate.org> wrote:
> Hi,
> there are some plugins to upgrade on Jenkins and it seems they have
> some non trivial changes.
>
> I'll do that on Thursday and hopefully it won't cause too many issues.
>
> Thanks,
> Davideb
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Update Jenkins plugins

[Davide D'Alto]

Hi,
there are some plugins to upgrade on Jenkins and it seems they have
some non trivial changes.

I'll do that on Thursday and hopefully it won't cause too many issues.

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

Re: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB

[Davide D'Alto]

I've created a JIRA for this https://hibernate.atlassian.net/browse/OGM-1236

Thanks

On Fri, Jan 13, 2017 at 2:26 PM, Sanne Grinovero <sa...@hibernate.org> wrote:
> Hi Yoann,
>
> while you might be using a specific implementation when persisting
> your new entities, when you're loading the object back from the
> database how is Hibernate supposed to know
>  A) which implementation you want it to use
>  B) which order to use, if you didn't map e.g. an order column to
> store the ordering information (MongoDB not needing a strategy is an
> exception)
>
> The entity model expresses the intent of the end user, but also it
> expresses its requirements which will be taken into account by ORM
> when it needs to provide an implementation for the "Collection"
> interface.
>
> A List expresses the ordering requirement by contract; if you map a
> relation as "Collection" I wage you're not interested in the order,
> but you're rather more interested in accepting a wide range of
> implementations, some of which might ignore the ordering requirement.
> By doing so, you're explicitly telling both ORM and your other code
> interacting with the model that ignoring the order is acceptable.
>
> BTW I suspect mapping things as a generic Collection is a very unusual
> (or lazy) choice; I don't remember ever using it as it's quite
> ambiguous, and there's no way any specification diagram will lead you
> to recommend using a Collection (other than cleanly and explicitly
> wanting to express you don't care about ordering, nor other properties
> like uniqueness...)
>
> Thanks,
> Sanne
>
>
> On 13 January 2017 at 13:29, Yoann Rodiere <yrodi...@redhat.com> wrote:
>>> I think it's a reasonable expectation, as long as we're talking
>>> specifically about mapping a *List* and not just a generic Collection.
>>
>>
>> Ah, this topic again :) I know I'll be all lone, but I'll try anyway!
>>
>> If we do it for List, and unless there are technical issues that prevent us
>> from doing so, I would be in favor of doing it for any kind of collection.
>>
>> In Collections, the fact that iteration order is deterministic is mostly up
>> to the implementation, which is different from saying it's not
>> deterministic. From the javadoc for Collection#iterator():
>>
>>> There are no guarantees concerning the order in which the elements are
>>> returned
>>> (unless this collection is an instance of some class that provides a
>>> guarantee).
>>
>>
>> Deterministic, and even predictable order is not exclusive to List, either:
>> for instance, LinkedHashSet is not a List, it has a specific iteration
>> order, but there is nothing in its implemented interfaces (Collection, Set)
>> that defines this order.
>>
>> My point is, we can't rely on the implemented interface to decide whether
>> the iteration order is important or not, so we may as well decide it is
>> always important. Unless there are annoying technical challenges, of course.
>>
>> Yoann Rodière <yrodi...@redhat.com>
>> Software Engineer
>> Red Hat / Hibernate NoORM Team
>>
>> On 13 January 2017 at 13:48, Sanne Grinovero <sa...@hibernate.org> wrote:
>>>
>>> I think it's a reasonable expectation, as long as we're talking
>>> specifically about mapping a *List* and not just a generic Collection.
>>>
>>> On 13 January 2017 at 12:18, Davide D'Alto <dav...@hibernate.org> wrote:
>>> > Hi,
>>> > it seems that when using Collection of elements in MongoDB, users
>>> > expect to have the elements in the same order as in the db. You can
>>> > see the question on the forum here:
>>> >
>>> > https://forum.hibernate.org/viewtopic.php?f=31=1043903=2491218#p2491218
>>> >
>>> > I also found this StackOverflow question:
>>> >
>>> > http://stackoverflow.com/questions/9013916/do-arrays-stored-in-mongodb-keep-their-order
>>> >
>>> > What do you think? Is it something that we should support?
>>> >
>>> > Cheers,
>>> > Davide
>>> > ___
>>> > 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] [OGM] Keeping the order of the collection of elements in MongoDB

[Davide D'Alto]

Hi,
it seems that when using Collection of elements in MongoDB, users
expect to have the elements in the same order as in the db. You can
see the question on the forum here:
https://forum.hibernate.org/viewtopic.php?f=31=1043903=2491218#p2491218

I also found this StackOverflow question:
http://stackoverflow.com/questions/9013916/do-arrays-stored-in-mongodb-keep-their-order

What do you think? Is it something that we should support?

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

Re: [hibernate-dev] CI Jenkins upgraded to version 2.38

[Davide D'Alto]

> If a job build does not trigger from a PR and everything seems right,
> check the advance configuration option under:

I meant, if a build does not start when you leave the comment:
"Jenkins, rebuild this please"

On Thu, Jan 5, 2017 at 4:04 PM, Davide D'Alto <dav...@hibernate.org> wrote:
> For future reference,
> these problems should be fixed now.
>
> If a job build does not trigger from a PR and everything seems right,
> check the advance configuration option under:
>
> Build Triggers > GitHub Pull Request Builder > Trigger phrase
>
> If it's blank try set it to something like: .*test\W+this\W+please.*
>
> This might change on future Jenkins updates.
>
> Cheers
>
> On Tue, Jan 3, 2017 at 10:39 PM, Guillaume Smet
> <guillaume.s...@gmail.com> wrote:
>> On Tue, Jan 3, 2017 at 6:23 PM, Yoann Rodiere <yo...@hibernate.org> wrote:
>>>
>>> It's a bit odd, because the OGM PR job seems to work fine... From what I
>>> can see there hasn't been any particular change on the OGM job.
>>
>>
>> As for OGM, the build is triggered but does not report back to GitHub. I
>> pinged Davide about it a few hours ago, he's working on it.
>>
>> --
>> Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] CI Jenkins upgraded to version 2.38

[Davide D'Alto]

For future reference,
these problems should be fixed now.

If a job build does not trigger from a PR and everything seems right,
check the advance configuration option under:

Build Triggers > GitHub Pull Request Builder > Trigger phrase

If it's blank try set it to something like: .*test\W+this\W+please.*

This might change on future Jenkins updates.

Cheers

On Tue, Jan 3, 2017 at 10:39 PM, Guillaume Smet
 wrote:
> On Tue, Jan 3, 2017 at 6:23 PM, Yoann Rodiere  wrote:
>>
>> It's a bit odd, because the OGM PR job seems to work fine... From what I
>> can see there hasn't been any particular change on the OGM job.
>
>
> As for OGM, the build is triggered but does not report back to GitHub. I
> pinged Davide about it a few hours ago, he's working on it.
>
> --
> Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate OGM 5.1 Beta3 and 5.0.4 released

[Davide D'Alto]

Hello everybody, holidays are over and we decided to start back with a
small release.

Hibernate OGM 5.1 Beta3 and a new 5.0 maintainance releases are now available.

In these releases we fixed some issues around sequence generation and
queries on entities using the single table per class inheritance
strategy. An update is highly recommended.

You can find all the details in the blog post [1].

Thanks,
Davide

[1] http://in.relation.to/2017/01/05/hibernate-ogm-5-beta3-and-5/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] CI Jenkins upgraded to version 2.38

[Davide D'Alto]

Thanks for the feedback,

header and footer should be fine now.

Thanks,
Davide

On Thu, Dec 29, 2016 at 11:37 PM, Sanne Grinovero <sa...@hibernate.org> wrote:
> Thanks Davide!
> The builds seems to work just fine, the only minor defect I've noticed
> is with the stylesheet doing some strange things when scrolling down:
> the breadcrumbs will "float" down as well. Definitely not urgent,
> great to have all updates!
>
> Thanks,
> Sanne
>
>
> On 28 December 2016 at 01:04, Davide D'Alto <dav...@hibernate.org> wrote:
>> Hi,
>> I hope you all had great holidays.
>>
>> I've upgraded our Jenkin on CI to version 2.38.
>>
>> As far as i can tell everything seems all right, but if you experience
>> some unusual problems,
>> please, let me know.
>>
>>
>> Cheers,
>> Davide
>> ___
>> 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] CI Jenkins upgraded to version 2.38

[Davide D'Alto]

Hi,
I hope you all had great holidays.

I've upgraded our Jenkin on CI to version 2.38.

As far as i can tell everything seems all right, but if you experience
some unusual problems,
please, let me know.


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

[hibernate-dev] Jenkins upgrade on CI

[Davide D'Alto]

Hi,
I'm going to upgrade our Jenkins on CI  next week, the 27th of December.

This could  be a relatively safe procedure but because our version is
old and we are using several plugins I'm not sure it will go smoothly.

If you have some jobs that need to be executed that day, let me know.

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

[hibernate-dev] [OGM} 5.1.0.Beta2 release delayed because of Nexus

[Davide D'Alto]

Hi,
Jenkins deployed everything but Nexus doesn't want to release it.

Any suggestions?

I'll try again tomorrow

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

[hibernate-dev] Update JDK 9 on ci.hibernate.org: JDK 9 build 148

[Davide D'Alto]

Hi,
I just wanted to inform that I've updated the JDK 9 version on CI to build 148.

Let me know if there are problems.

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

Re: [hibernate-dev] [OGM] Inheritance mapping in Neo4j

[Davide D'Alto]

Yes, I think that if we keep the property and only add the label we
won't break anything in the mapping.


On Thu, Nov 17, 2016 at 2:15 PM, Guillaume Smet
<guillaume.s...@gmail.com> wrote:
> Hi,
>
> As I understand it, having 2 labels means that you could search either with
> n:Person or n:Player?
>
> Thus if we keep the DTYPE: Player in place in addition to both labels, we
> won't break anything, will we?
>
> --
> Guillaume
>
> On Thu, Nov 17, 2016 at 2:30 PM, Sanne Grinovero <sa...@hibernate.org>
> wrote:
>>
>> Hi, it makes sense but I don't think we can change the mapping now.
>>
>> Could you do it as a new option? Would you be able to adjust the
>> queries as needed?
>>
>> If you can make it a configuration property, default to the old style
>> mapping, and log a warning of using a deprecated mapping when the old
>> one is being used. This implies that people not choosing any mapping
>> style explicitly will see a warning (as the old one would still be the
>> default).
>>
>> Thanks,
>> Sanne
>>
>> On 16 November 2016 at 12:42, Davide D'Alto <dav...@hibernate.org> wrote:
>> > A user created the issue https://hibernate.atlassian.net/browse/OGM-1210
>> >
>> > The problem is that when we use the SingleTable strategy in Neo4j  we
>> > add a property DTYPE to the node to discriminate the entities instead
>> > of using labels.
>> >
>> > As an example, given an entity Player that extends Person we create:
>> >
>> > (n:Person {DTYPE: Player})
>> >
>> > instead of having a node with two labels:
>> >
>> > (n:Person:Player)
>> >
>> > I think the mapping with multiple labels is more natural than the one
>> > we currently have.
>> >
>> > I was wondering if we should fix this for the next release, the
>> > problem is that I would need additional information in one of our
>> > .spi.*Context and it will change the mapping.
>> >
>> > The next release should be 5.1.Beta2
>> >
>> > What do you think?
>> >
>> > Thanks,
>> > Davide
>> > ___
>> > 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] [OGM] Inheritance mapping in Neo4j

[Davide D'Alto]

A user created the issue https://hibernate.atlassian.net/browse/OGM-1210

The problem is that when we use the SingleTable strategy in Neo4j  we
add a property DTYPE to the node to discriminate the entities instead
of using labels.

As an example, given an entity Player that extends Person we create:

(n:Person {DTYPE: Player})

instead of having a node with two labels:

(n:Person:Player)

I think the mapping with multiple labels is more natural than the one
we currently have.

I was wondering if we should fix this for the next release, the
problem is that I would need additional information in one of our
.spi.*Context and it will change the mapping.

The next release should be 5.1.Beta2

What do you think?

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

Re: [hibernate-dev] Checkstyle checks in ORM

[Davide D'Alto]

What do you think about having different profiles?
One for new contributors (more relaxed)
and one for active developers.

Given that I'm not sure what kind of checkstyle rules we are talking about.

On Wed, Nov 9, 2016 at 2:15 PM, Steve Ebersole  wrote:
> While developing the Byte Buddy Enhancer, Rafael ran into what I thnk is a
> valid problem in the ORM build.  Namely the fact that we incorporate
> non-fatal Checktyle checks.  In local builds this leads to a situation
> where it is extremely difficult for new contributors to find out what
> exactly they violated.  Jenkins presents these better and makes it easier
> to see just "fatal" (high priority) violations, but the Checktype report
> itself does not.  Even worse the Checkstyle report does not even show the
> priority of individual violations at all.
>
> I suggest we remove all non-fatal Checkstyle rules to make it easier on
> contributors.
> ___
> 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] [OGM] Neo4j integration dependencies

[Davide D'Alto]

Splitting in 3 modules sounds good to me.

I was sure in past there was some opposition about having additional modules.

I might have imagined it

On Wed, Oct 19, 2016 at 10:59 AM, Sanne Grinovero <sa...@hibernate.org> wrote:
> On 19 October 2016 at 10:44, Yoann Rodiere <yo...@hibernate.org> wrote:
>> Is there any particular reason why we would not want to create three
>> artifacts, besides backward compatibility? It seems the obvious and ideal
>> solution, but I might be missing something.
>>
>> If there is common code, we can always create a fourth -neo4j-core artifact
>> that would have no interest to users but would simply ensure we don't
>> duplicate code, and would be delivered through transitive dependencies.
>>
>> About backward compatibility, I guess there are two options:
>>
>>- If the last released version of the artifact used to contain only the
>>embedded mode, we can use maven relocation
>>- Otherwise, we can advertise this artifact as deprecated, remove almost
>>everything in it and add the relevant new artifacts as dependencies.
>>
>> Or am I being too naive?
>
> Seems very reasonable. Maybe I'm naive too :)
>
> -- Sanne
>
>>
>> Yoann Rodière <yo...@hibernate.org>
>> Hibernate NoORM Team
>>
>> On 19 October 2016 at 11:17, Davide D'Alto <dav...@hibernate.org> wrote:
>>
>>> The integration with Neo4j in OGM makes it possible for a user to
>>> select the strategy that he wants to use to connect to an embedded or
>>> remote Neo4j instance.
>>> There are 3 possible options:
>>> 1) Embedded mode, Neo4j run in the same JVM
>>> 2) Remote via HTTP interface using RestEasy
>>> 3) Remote via the Bolt protocol using the neo4j-java-driver library
>>>
>>> Everything is now in one single artifact meaning that for each case we
>>> have more dependencies than needed, in particular for the remote
>>> cases.
>>>
>>> Possible solutions I can think of at the moment are:
>>>
>>> 1) Have different maven artifacts:
>>> - We could have 3 artifacts: EMBEDDED, HTTP and BOLT
>>> - or 2 artifacts: EMBEDDED and REMOTE: This won't completely solve
>>> the issue because w would still have
>>>   resteasy (for HTTP) and neo4j-java-driver (for BOLT) but it
>>> might be a good trade-off
>>>
>>> We will need to share some resource so this approach might require
>>> a Neo4j common library.
>>>
>>> 2) Make some dependencies optional (Need to test this, but it might work)
>>>
>>> 3) Use some maven plugin to generate different artifacts from the same
>>> module. I haven't used this approach before so I'm not sure if it is
>>> feasible.
>>>
>>> 4) ???
>>>
>>> Any opinion about this?
>>>
>>> Issue on JIRA: https://hibernate.atlassian.net/browse/OGM-1190
>>>
>>> Thanks,
>>> Davide
>>> ___
>>> 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] [OGM] Neo4j integration dependencies

[Davide D'Alto]

The integration with Neo4j in OGM makes it possible for a user to
select the strategy that he wants to use to connect to an embedded or
remote Neo4j instance.
There are 3 possible options:
1) Embedded mode, Neo4j run in the same JVM
2) Remote via HTTP interface using RestEasy
3) Remote via the Bolt protocol using the neo4j-java-driver library

Everything is now in one single artifact meaning that for each case we
have more dependencies than needed, in particular for the remote
cases.

Possible solutions I can think of at the moment are:

1) Have different maven artifacts:
- We could have 3 artifacts: EMBEDDED, HTTP and BOLT
- or 2 artifacts: EMBEDDED and REMOTE: This won't completely solve
the issue because w would still have
  resteasy (for HTTP) and neo4j-java-driver (for BOLT) but it
might be a good trade-off

We will need to share some resource so this approach might require
a Neo4j common library.

2) Make some dependencies optional (Need to test this, but it might work)

3) Use some maven plugin to generate different artifacts from the same
module. I haven't used this approach before so I'm not sure if it is
feasible.

4) ???

Any opinion about this?

Issue on JIRA: https://hibernate.atlassian.net/browse/OGM-1190

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

[hibernate-dev] Hibernate OGM double release!

[Davide D'Alto]

Good news!

We released Hibernate OGM 5.1 Alpha1 and 5.0.2 Final!

Hibernate OGM 5.0.2.Final now supports MongoDB 3.2 and it’s still
backward compatible with Hibernate OGM 5.0.1.Final.

Hibernate OGM 5.1.0.Alpha1 brings support for Neo4 in remote mode.

We also started to re-work the way Hibernate OGM groups operations
before running them; this reduce the number of calls and commands to
execute on the datastore, leading to better performance.

You can find more about these releases and how to get them in the blog post:
http://in.relation.to/2016/10/10/hibernate-ogm-5-1-alpha-and-5-0-2-released/

Thanks,
Davide

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