Re: [hibernate-dev] Changelog file in Hibernate ORM

[Emmanuel Bernard]

> On 28 May 2015, at 10:42, Hardy Ferentschik  wrote:
> 
> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
>> +1 from me.  Although, on the other hand, do we really need to keep 
>> maintaining that to begin with?  I guess I never thought simply having users 
>> go to the JIRA release notes was a big deal.  Just my $.02.
> 
> Same for me on both counts, the proposed handling of changelog.txt as well as 
> Brett's comment regarding the usefulness of this file altogether.

A more frequent than I thought usage of changelog vs JIRA is a mix of Ctrl+F + 
quick scan to know what has changed in a library or know what is affecting me. 
JIRA is not the most intuitive UI in the universe. With allt he bug statuses, 
the various intermediary releases to select etc, nothing beats changelog.txt.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM - next steps

[Emmanuel Bernard]

My favs are

* discriminator-based multi-tenancy
* extend JPA criteria API with fluent support (does that mean embracing 
something like http://www.querydsl.com ? Os is that something different?
* rework SQL generation & HQL parser



> On 28 May 2015, at 18:33, Steve Ebersole  wrote:
> 
> Anyone have any input here?  Or should I just start scheduling them how I
> want?
> 
> On Tue, May 19, 2015 at 8:47 PM, Steve Ebersole  wrote:
> 
>> Now that 5.0 is settling down I wanted to start planning where we go from
>> here in terms of feature development and schedule/releases.
>> 
>> Here is my high-level list of features/work:
>> * rework SQL generation & HQL parser
>> * change JDBC extraction to work by position, rather than alias (reworking
>> SQL generation is a prerequisite)
>> * rework annotation binding (Jandex, etc)
>> * extended orm.xml, deprecate hbm.xml
>> * discriminator-based multi-tenancy
>> * port Hibernate Criteria constructs to JPA criteria, begin deprecation of
>> Hibernate Criteria
>> * extend JPA criteria API with fluent support
>> * ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
>> * merging hibernate-entitymanager into hibernate-core
>> * continue to fill out bytecode enhancement capabilities
>> 
>> Some of these are more involved than others.  The task for re-writing SQL
>> generation is a HUGE undertaking, but also has many huge benefits.
>> Re-writing annotation binding is another huge undertaking, but again with
>> many benefits.
>> 
>> Any others we should add to the list here?
>> 
>> And then we can work on scheduling them.
>> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


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

Re: [hibernate-dev] Hibernate ORM - next steps

[Emmanuel Bernard]

Also (thinking outloud).

Maybe planning 5.1 5.2 5.x as a savant dosage of:

- a focused and useful new feature that users tend to like (discriminator-based 
multi-tenancy, fluent criteria API, …)
- a performance focused feature (position rather than alias usage in JDBC)
- a longer term work plan which might span several minors to be achieved (SQL 
generation & hQL parser, …)

One of each per 5.x might be interesting to explore.

> On 29 May 2015, at 09:58, Emmanuel Bernard  wrote:
> 
> My favs are
> 
> * discriminator-based multi-tenancy
> * extend JPA criteria API with fluent support (does that mean embracing 
> something like http://www.querydsl.com ? Os is that something different?
> * rework SQL generation & HQL parser
> 
> 
> 
>> On 28 May 2015, at 18:33, Steve Ebersole  wrote:
>> 
>> Anyone have any input here?  Or should I just start scheduling them how I
>> want?
>> 
>> On Tue, May 19, 2015 at 8:47 PM, Steve Ebersole  wrote:
>> 
>>> Now that 5.0 is settling down I wanted to start planning where we go from
>>> here in terms of feature development and schedule/releases.
>>> 
>>> Here is my high-level list of features/work:
>>> * rework SQL generation & HQL parser
>>> * change JDBC extraction to work by position, rather than alias (reworking
>>> SQL generation is a prerequisite)
>>> * rework annotation binding (Jandex, etc)
>>> * extended orm.xml, deprecate hbm.xml
>>> * discriminator-based multi-tenancy
>>> * port Hibernate Criteria constructs to JPA criteria, begin deprecation of
>>> Hibernate Criteria
>>> * extend JPA criteria API with fluent support
>>> * ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
>>> * merging hibernate-entitymanager into hibernate-core
>>> * continue to fill out bytecode enhancement capabilities
>>> 
>>> Some of these are more involved than others.  The task for re-writing SQL
>>> generation is a HUGE undertaking, but also has many huge benefits.
>>> Re-writing annotation binding is another huge undertaking, but again with
>>> many benefits.
>>> 
>>> Any others we should add to the list here?
>>> 
>>> And then we can work on scheduling them.
>>> 
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


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

Re: [hibernate-dev] Hibernate ORM - next steps

[Mihalcea Vlad]

From a performance perspective, I'm glad we'll be able to override the EAGER 
fetching on a query-basis. We could have an UNFETCH directive to do the 
opposite of the current FETCH one.

The bytecode enhancement dirty-checking is also a plus.
 Vlad
 


 On Friday, May 29, 2015 11:09 AM, Emmanuel Bernard 
 wrote:
   

 Also (thinking outloud).

Maybe planning 5.1 5.2 5.x as a savant dosage of:

- a focused and useful new feature that users tend to like (discriminator-based 
multi-tenancy, fluent criteria API, …)
- a performance focused feature (position rather than alias usage in JDBC)
- a longer term work plan which might span several minors to be achieved (SQL 
generation & hQL parser, …)

One of each per 5.x might be interesting to explore.

> On 29 May 2015, at 09:58, Emmanuel Bernard  wrote:
> 
> My favs are
> 
> * discriminator-based multi-tenancy
> * extend JPA criteria API with fluent support (does that mean embracing 
> something like http://www.querydsl.com ? Os is that something different?
> * rework SQL generation & HQL parser
> 
> 
> 
>> On 28 May 2015, at 18:33, Steve Ebersole  wrote:
>> 
>> Anyone have any input here?  Or should I just start scheduling them how I
>> want?
>> 
>> On Tue, May 19, 2015 at 8:47 PM, Steve Ebersole  wrote:
>> 
>>> Now that 5.0 is settling down I wanted to start planning where we go from
>>> here in terms of feature development and schedule/releases.
>>> 
>>> Here is my high-level list of features/work:
>>> * rework SQL generation & HQL parser
>>> * change JDBC extraction to work by position, rather than alias (reworking
>>> SQL generation is a prerequisite)
>>> * rework annotation binding (Jandex, etc)
>>> * extended orm.xml, deprecate hbm.xml
>>> * discriminator-based multi-tenancy
>>> * port Hibernate Criteria constructs to JPA criteria, begin deprecation of
>>> Hibernate Criteria
>>> * extend JPA criteria API with fluent support
>>> * ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
>>> * merging hibernate-entitymanager into hibernate-core
>>> * continue to fill out bytecode enhancement capabilities
>>> 
>>> Some of these are more involved than others.  The task for re-writing SQL
>>> generation is a HUGE undertaking, but also has many huge benefits.
>>> Re-writing annotation binding is another huge undertaking, but again with
>>> many benefits.
>>> 
>>> Any others we should add to the list here?
>>> 
>>> And then we can work on scheduling them.
>>> 
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


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

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

Re: [hibernate-dev] Hibernate ORM - next steps

[Hardy Ferentschik]

On Thu, May 28, 2015 at 11:33:22AM -0500, Steve Ebersole wrote:
> Anyone have any input here?  Or should I just start scheduling them how I
> want?

I think all goals sound good. I would say schedule as you seem fit, maybe 
with a focus of giving users something tangible asap (a bit of what Emmanuel 
says).

--Hardy


pgp4aFG4UMymQ.pgp
Description: PGP signature
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM - next steps

[Sanne Grinovero]

I agree as well :)

Just to add a minor twist:
 - the override to lazy from eager would be useful to Search; skipping
fields completely as an extra bonus (something I think ORM can't do at
all - for good reasons when it comes to end user API - but again
something Search would benefit from and not expose to users).
 - since I'm currently exploring the 2nd level cache keys and the
persistence context keys again, it's getting clear (again as we
discussed this before) to potentially use a different data structure
to hold the persistence context.

But neither is urgent, I'd prefer you to schedule things to minimize
overall effort (maximize overall throughput over latency of any of
these).

On "position rather than alias usage in JDBC": I was looking forward
for that as well. Wasn't it part of the 5.0 schedule? I thought it was
done.

Sanne


On 29 May 2015 at 11:22, Hardy Ferentschik  wrote:
> On Thu, May 28, 2015 at 11:33:22AM -0500, Steve Ebersole wrote:
>> Anyone have any input here?  Or should I just start scheduling them how I
>> want?
>
> I think all goals sound good. I would say schedule as you seem fit, maybe
> with a focus of giving users something tangible asap (a bit of what Emmanuel
> says).
>
> --Hardy
>
> ___
> 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] Changelog file in Hibernate ORM

[Sanne Grinovero]

On 29 May 2015 at 08:15, Emmanuel Bernard  wrote:
>
>> On 28 May 2015, at 10:42, Hardy Ferentschik  wrote:
>>
>> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
>>> +1 from me.  Although, on the other hand, do we really need to keep 
>>> maintaining that to begin with?  I guess I never thought simply having 
>>> users go to the JIRA release notes was a big deal.  Just my $.02.
>>
>> Same for me on both counts, the proposed handling of changelog.txt as well 
>> as Brett's comment regarding the usefulness of this file altogether.
>
> A more frequent than I thought usage of changelog vs JIRA is a mix of Ctrl+F 
> + quick scan to know what has changed in a library or know what is affecting 
> me. JIRA is not the most intuitive UI in the universe. With allt he bug 
> statuses, the various intermediary releases to select etc, nothing beats 
> changelog.txt.

+1
- JIRA's UI is not too bad but let's remember that while we use it
since years, others might not feel comfortable with it
- many of those receiving our "dist" package might not have internet
access at all
- the dist packages is long term archived, like we include sources it
should contain a snapshot of all state. I like JIRA but who knows how
long it will be there?

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

Re: [hibernate-dev] Hibernate ORM - next steps

[Steve Ebersole]

Guys "position rather than alias usage in JDBC" is a small part of a
massive set of related changes in how we build SQL and consume the
results.  And actually it is the piece that has any compatibility impact
since it means any and all custom Types will need to be re-written.

On Fri, May 29, 2015 at 5:53 AM, Sanne Grinovero 
wrote:

> I agree as well :)
>
> Just to add a minor twist:
>  - the override to lazy from eager would be useful to Search; skipping
> fields completely as an extra bonus (something I think ORM can't do at
> all - for good reasons when it comes to end user API - but again
> something Search would benefit from and not expose to users).
>  - since I'm currently exploring the 2nd level cache keys and the
> persistence context keys again, it's getting clear (again as we
> discussed this before) to potentially use a different data structure
> to hold the persistence context.
>
> But neither is urgent, I'd prefer you to schedule things to minimize
> overall effort (maximize overall throughput over latency of any of
> these).
>
> On "position rather than alias usage in JDBC": I was looking forward
> for that as well. Wasn't it part of the 5.0 schedule? I thought it was
> done.
>
> Sanne
>
>
> On 29 May 2015 at 11:22, Hardy Ferentschik  wrote:
> > On Thu, May 28, 2015 at 11:33:22AM -0500, Steve Ebersole wrote:
> >> Anyone have any input here?  Or should I just start scheduling them how
> I
> >> want?
> >
> > I think all goals sound good. I would say schedule as you seem fit, maybe
> > with a focus of giving users something tangible asap (a bit of what
> Emmanuel
> > says).
> >
> > --Hardy
> >
> > ___
> > 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] Changelog file in Hibernate ORM

[Steve Ebersole]

I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You want to
keep a massive changelog.txt containing all history forever?

On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero 
wrote:

> On 29 May 2015 at 08:15, Emmanuel Bernard  wrote:
> >
> >> On 28 May 2015, at 10:42, Hardy Ferentschik 
> wrote:
> >>
> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> >>> +1 from me.  Although, on the other hand, do we really need to keep
> maintaining that to begin with?  I guess I never thought simply having
> users go to the JIRA release notes was a big deal.  Just my $.02.
> >>
> >> Same for me on both counts, the proposed handling of changelog.txt as
> well as Brett's comment regarding the usefulness of this file altogether.
> >
> > A more frequent than I thought usage of changelog vs JIRA is a mix of
> Ctrl+F + quick scan to know what has changed in a library or know what is
> affecting me. JIRA is not the most intuitive UI in the universe. With allt
> he bug statuses, the various intermediary releases to select etc, nothing
> beats changelog.txt.
>
> +1
> - JIRA's UI is not too bad but let's remember that while we use it
> since years, others might not feel comfortable with it
> - many of those receiving our "dist" package might not have internet
> access at all
> - the dist packages is long term archived, like we include sources it
> should contain a snapshot of all state. I like JIRA but who knows how
> long it will be there?
>
> ___
> 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] Changelog file in Hibernate ORM

[Sanne Grinovero]

I'm +1 especially to keep the changelog.txt file both maintained and included.

About pruning older content: I'd keep the past few years at least, for
sake of who's finally upgrading.
Maybe since version 3.0 onwards? Or just keep it all :)

On 29 May 2015 at 12:05, Steve Ebersole  wrote:
> I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You want to
> keep a massive changelog.txt containing all history forever?
>
> On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero 
> wrote:
>>
>> On 29 May 2015 at 08:15, Emmanuel Bernard  wrote:
>> >
>> >> On 28 May 2015, at 10:42, Hardy Ferentschik 
>> >> wrote:
>> >>
>> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
>> >>> +1 from me.  Although, on the other hand, do we really need to keep
>> >>> maintaining that to begin with?  I guess I never thought simply having 
>> >>> users
>> >>> go to the JIRA release notes was a big deal.  Just my $.02.
>> >>
>> >> Same for me on both counts, the proposed handling of changelog.txt as
>> >> well as Brett's comment regarding the usefulness of this file altogether.
>> >
>> > A more frequent than I thought usage of changelog vs JIRA is a mix of
>> > Ctrl+F + quick scan to know what has changed in a library or know what is
>> > affecting me. JIRA is not the most intuitive UI in the universe. With allt
>> > he bug statuses, the various intermediary releases to select etc, nothing
>> > beats changelog.txt.
>>
>> +1
>> - JIRA's UI is not too bad but let's remember that while we use it
>> since years, others might not feel comfortable with it
>> - many of those receiving our "dist" package might not have internet
>> access at all
>> - the dist packages is long term archived, like we include sources it
>> should contain a snapshot of all state. I like JIRA but who knows how
>> long it will be there?
>>
>> ___
>> 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] Changelog file in Hibernate ORM

[Steve Ebersole]

So it makes sense to you that the changelog for 5.0 includes entries for
pre 1.0?

On Fri, May 29, 2015 at 6:09 AM, Sanne Grinovero 
wrote:

> I'm +1 especially to keep the changelog.txt file both maintained and
> included.
>
> About pruning older content: I'd keep the past few years at least, for
> sake of who's finally upgrading.
> Maybe since version 3.0 onwards? Or just keep it all :)
>
> On 29 May 2015 at 12:05, Steve Ebersole  wrote:
> > I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You want
> to
> > keep a massive changelog.txt containing all history forever?
> >
> > On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero 
> > wrote:
> >>
> >> On 29 May 2015 at 08:15, Emmanuel Bernard 
> wrote:
> >> >
> >> >> On 28 May 2015, at 10:42, Hardy Ferentschik 
> >> >> wrote:
> >> >>
> >> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> >> >>> +1 from me.  Although, on the other hand, do we really need to keep
> >> >>> maintaining that to begin with?  I guess I never thought simply
> having users
> >> >>> go to the JIRA release notes was a big deal.  Just my $.02.
> >> >>
> >> >> Same for me on both counts, the proposed handling of changelog.txt as
> >> >> well as Brett's comment regarding the usefulness of this file
> altogether.
> >> >
> >> > A more frequent than I thought usage of changelog vs JIRA is a mix of
> >> > Ctrl+F + quick scan to know what has changed in a library or know
> what is
> >> > affecting me. JIRA is not the most intuitive UI in the universe. With
> allt
> >> > he bug statuses, the various intermediary releases to select etc,
> nothing
> >> > beats changelog.txt.
> >>
> >> +1
> >> - JIRA's UI is not too bad but let's remember that while we use it
> >> since years, others might not feel comfortable with it
> >> - many of those receiving our "dist" package might not have internet
> >> access at all
> >> - the dist packages is long term archived, like we include sources it
> >> should contain a snapshot of all state. I like JIRA but who knows how
> >> long it will be there?
> >>
> >> ___
> >> 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] Changelog file in Hibernate ORM

[Sanne Grinovero]

I wouldn't stay awake at night because of that :) maybe only if the
file gets huge?
It's useful for people migrating, but since I doubt someone would
migrate from pre-1.0 (at least without expecting to rewrite it all),
that's why I suggested to keep from 3.0 onwards.

On 29 May 2015 at 12:16, Steve Ebersole  wrote:
> So it makes sense to you that the changelog for 5.0 includes entries for pre
> 1.0?
>
> On Fri, May 29, 2015 at 6:09 AM, Sanne Grinovero 
> wrote:
>>
>> I'm +1 especially to keep the changelog.txt file both maintained and
>> included.
>>
>> About pruning older content: I'd keep the past few years at least, for
>> sake of who's finally upgrading.
>> Maybe since version 3.0 onwards? Or just keep it all :)
>>
>> On 29 May 2015 at 12:05, Steve Ebersole  wrote:
>> > I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You want
>> > to
>> > keep a massive changelog.txt containing all history forever?
>> >
>> > On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero 
>> > wrote:
>> >>
>> >> On 29 May 2015 at 08:15, Emmanuel Bernard 
>> >> wrote:
>> >> >
>> >> >> On 28 May 2015, at 10:42, Hardy Ferentschik 
>> >> >> wrote:
>> >> >>
>> >> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
>> >> >>> +1 from me.  Although, on the other hand, do we really need to keep
>> >> >>> maintaining that to begin with?  I guess I never thought simply
>> >> >>> having users
>> >> >>> go to the JIRA release notes was a big deal.  Just my $.02.
>> >> >>
>> >> >> Same for me on both counts, the proposed handling of changelog.txt
>> >> >> as
>> >> >> well as Brett's comment regarding the usefulness of this file
>> >> >> altogether.
>> >> >
>> >> > A more frequent than I thought usage of changelog vs JIRA is a mix of
>> >> > Ctrl+F + quick scan to know what has changed in a library or know
>> >> > what is
>> >> > affecting me. JIRA is not the most intuitive UI in the universe. With
>> >> > allt
>> >> > he bug statuses, the various intermediary releases to select etc,
>> >> > nothing
>> >> > beats changelog.txt.
>> >>
>> >> +1
>> >> - JIRA's UI is not too bad but let's remember that while we use it
>> >> since years, others might not feel comfortable with it
>> >> - many of those receiving our "dist" package might not have internet
>> >> access at all
>> >> - the dist packages is long term archived, like we include sources it
>> >> should contain a snapshot of all state. I like JIRA but who knows how
>> >> long it will be there?
>> >>
>> >> ___
>> >> 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] Changelog file in Hibernate ORM

[andrea boriero]

I would mantain all 5.x in the same changelog file and may be the previous
one.

On 29 May 2015 at 12:32, Sanne Grinovero  wrote:

> I wouldn't stay awake at night because of that :) maybe only if the
> file gets huge?
> It's useful for people migrating, but since I doubt someone would
> migrate from pre-1.0 (at least without expecting to rewrite it all),
> that's why I suggested to keep from 3.0 onwards.
>
> On 29 May 2015 at 12:16, Steve Ebersole  wrote:
> > So it makes sense to you that the changelog for 5.0 includes entries for
> pre
> > 1.0?
> >
> > On Fri, May 29, 2015 at 6:09 AM, Sanne Grinovero 
> > wrote:
> >>
> >> I'm +1 especially to keep the changelog.txt file both maintained and
> >> included.
> >>
> >> About pruning older content: I'd keep the past few years at least, for
> >> sake of who's finally upgrading.
> >> Maybe since version 3.0 onwards? Or just keep it all :)
> >>
> >> On 29 May 2015 at 12:05, Steve Ebersole  wrote:
> >> > I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You
> want
> >> > to
> >> > keep a massive changelog.txt containing all history forever?
> >> >
> >> > On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero  >
> >> > wrote:
> >> >>
> >> >> On 29 May 2015 at 08:15, Emmanuel Bernard 
> >> >> wrote:
> >> >> >
> >> >> >> On 28 May 2015, at 10:42, Hardy Ferentschik 
> >> >> >> wrote:
> >> >> >>
> >> >> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> >> >> >>> +1 from me.  Although, on the other hand, do we really need to
> keep
> >> >> >>> maintaining that to begin with?  I guess I never thought simply
> >> >> >>> having users
> >> >> >>> go to the JIRA release notes was a big deal.  Just my $.02.
> >> >> >>
> >> >> >> Same for me on both counts, the proposed handling of changelog.txt
> >> >> >> as
> >> >> >> well as Brett's comment regarding the usefulness of this file
> >> >> >> altogether.
> >> >> >
> >> >> > A more frequent than I thought usage of changelog vs JIRA is a mix
> of
> >> >> > Ctrl+F + quick scan to know what has changed in a library or know
> >> >> > what is
> >> >> > affecting me. JIRA is not the most intuitive UI in the universe.
> With
> >> >> > allt
> >> >> > he bug statuses, the various intermediary releases to select etc,
> >> >> > nothing
> >> >> > beats changelog.txt.
> >> >>
> >> >> +1
> >> >> - JIRA's UI is not too bad but let's remember that while we use it
> >> >> since years, others might not feel comfortable with it
> >> >> - many of those receiving our "dist" package might not have internet
> >> >> access at all
> >> >> - the dist packages is long term archived, like we include sources it
> >> >> should contain a snapshot of all state. I like JIRA but who knows how
> >> >> long it will be there?
> >> >>
> >> >> ___
> >> >> 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] HSearch + Tika bridge using Wildfly modules

[Sanne Grinovero]

Hi Brett,
we don't include all existing analysers and extensions within the
WildFly modules. In particular the Apache Tika libraries have a huge
amount of dependencies, you should choose the ones you need depending
on what kind of media you intend to parse.

Include any extension in your "application", we use the Hibernate ORM
classloader to lookup for extensions so these should be discoverable
if they are visible to the same classloader having your entities and
other extensions.

Sanne

On 29 May 2015 at 15:28, Brett Meyer  wrote:
> Hey Sanne!  Artificer has ' services="export" />' defined in its jboss-deployment-structure dependencies. 
>  But, when we try to use it, the following happens.
>
> Caused by: java.lang.ClassNotFoundException: org.apache.tika.parser.Parser 
> from [Module "org.hibernate.search.engine:main" from local module loader 
> @6cf76647 (finder: local module finder @665bf734 (roots: 
> /home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules,/home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules/system/layers/base))]
>
> One of our entities uses the built-in TikaBridge.  I figured the search.orm 
> module would bring the necessary Tika jars in with it.  Is there something 
> else we need to add?

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

Re: [hibernate-dev] Hibernate ORM - next steps

[Steve Ebersole]

That is actually exactly the model I started with 4.x and what I plan on
continuing into 5.x

On Fri, May 29, 2015, 3:07 AM Emmanuel Bernard 
wrote:

> Also (thinking outloud).
>
> Maybe planning 5.1 5.2 5.x as a savant dosage of:
>
> - a focused and useful new feature that users tend to like
> (discriminator-based multi-tenancy, fluent criteria API, …)
> - a performance focused feature (position rather than alias usage in JDBC)
> - a longer term work plan which might span several minors to be achieved
> (SQL generation & hQL parser, …)
>
> One of each per 5.x might be interesting to explore.
>
> > On 29 May 2015, at 09:58, Emmanuel Bernard 
> wrote:
> >
> > My favs are
> >
> > * discriminator-based multi-tenancy
> > * extend JPA criteria API with fluent support (does that mean embracing
> something like http://www.querydsl.com ? Os is that something different?
> > * rework SQL generation & HQL parser
> >
> >
> >
> >> On 28 May 2015, at 18:33, Steve Ebersole  wrote:
> >>
> >> Anyone have any input here?  Or should I just start scheduling them how
> I
> >> want?
> >>
> >> On Tue, May 19, 2015 at 8:47 PM, Steve Ebersole 
> wrote:
> >>
> >>> Now that 5.0 is settling down I wanted to start planning where we go
> from
> >>> here in terms of feature development and schedule/releases.
> >>>
> >>> Here is my high-level list of features/work:
> >>> * rework SQL generation & HQL parser
> >>> * change JDBC extraction to work by position, rather than alias
> (reworking
> >>> SQL generation is a prerequisite)
> >>> * rework annotation binding (Jandex, etc)
> >>> * extended orm.xml, deprecate hbm.xml
> >>> * discriminator-based multi-tenancy
> >>> * port Hibernate Criteria constructs to JPA criteria, begin
> deprecation of
> >>> Hibernate Criteria
> >>> * extend JPA criteria API with fluent support
> >>> * ability to override EAGER fetching with LAZY (fetch profiles, HQL,
> etc)
> >>> * merging hibernate-entitymanager into hibernate-core
> >>> * continue to fill out bytecode enhancement capabilities
> >>>
> >>> Some of these are more involved than others.  The task for re-writing
> SQL
> >>> generation is a HUGE undertaking, but also has many huge benefits.
> >>> Re-writing annotation binding is another huge undertaking, but again
> with
> >>> many benefits.
> >>>
> >>> Any others we should add to the list here?
> >>>
> >>> And then we can work on scheduling them.
> >>>
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM - next steps

[John O'Hara]

On 20/05/15 02:47, Steve Ebersole wrote:
> Now that 5.0 is settling down I wanted to start planning where we go from
> here in terms of feature development and schedule/releases.
>
> Here is my high-level list of features/work:
> * rework SQL generation & HQL parser
> * change JDBC extraction to work by position, rather than alias (reworking
> SQL generation is a prerequisite)
+1
I had been tasked to start investigating the two features above, as we 
have seen them to impact performance in the past. If you would like an 
additional pair of hands on either/both of these, please let me know

> * rework annotation binding (Jandex, etc)
> * extended orm.xml, deprecate hbm.xml
> * discriminator-based multi-tenancy
> * port Hibernate Criteria constructs to JPA criteria, begin deprecation of
> Hibernate Criteria
> * extend JPA criteria API with fluent support
> * ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
> * merging hibernate-entitymanager into hibernate-core
> * continue to fill out bytecode enhancement capabilities
>
> Some of these are more involved than others.  The task for re-writing SQL
> generation is a HUGE undertaking, but also has many huge benefits.
> Re-writing annotation binding is another huge undertaking, but again with
> many benefits.
>
> Any others we should add to the list here?
>
> And then we can work on scheduling them.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
John O'Hara
joh...@redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, 
Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: 
Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael 
O'Neill (Ireland).

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

[hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

I ran part of the WildFly basic integration tests against the 
https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch, 
which includes the following Hibernate versions:

ORM 5.0.0.CR1
HCA 4.0.5.Final
HS 5.2.0.Final

I am seeing the below errors.

1. The Hibernate Search test 
(org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase) 
is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L

2. In the 
org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
 
we are seeing a "java.lang.ClassNotFoundException: 
org.infinispan.commons.util.CloseableIteratorSet from [Module 
"org.hibernate.infinispan:main"http://pastie.org/10213943

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

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

Also am using Infinispan 7.2.1.Final but noticed that Infinispan 
7.2.2.Final is now in WildFly 10, so I'll sync my branch with WF master 
to upgrade Infinispan.

On 05/29/2015 12:50 PM, Scott Marlow wrote:
> I ran part of the WildFly basic integration tests against the
> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch,
> which includes the following Hibernate versions:
>
> ORM 5.0.0.CR1
> HCA 4.0.5.Final
> HS 5.2.0.Final
>
> I am seeing the below errors.
>
> 1. The Hibernate Search test
> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
> is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L
>
> 2. In the
> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
> we are seeing a "java.lang.ClassNotFoundException:
> org.infinispan.commons.util.CloseableIteratorSet from [Module
> "org.hibernate.infinispan:main"http://pastie.org/10213943
>
> Scott
> ___
> 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] WildFly 10 + Hibernate ORM 5 integration status update...

[Sanne Grinovero]

Thanks Scott!

1. this error is expected: HS 5.2 is not compatible with ORM 5.
We'll need a compatible WildFly version to release a compatible
version, or alternatively know how to get the tests to run w/o the
jipijapa patch as I was trying ;-)

A backup plan is we stop producing Hibernate Search modules for
WildFly as part of our release, and split it up as a secondary task
like Hardy suggested today on IRC.

2. this is not expected, especially as I think the Infinispan version
already in WF is aligned with the one in ORM5?
Steve, do you remember about classloader strategy changes between
latest ORM 4.3 and 5.0.0.CR1?

Sanne


On 29 May 2015 at 17:50, Scott Marlow  wrote:
> I ran part of the WildFly basic integration tests against the
> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch,
> which includes the following Hibernate versions:
>
> ORM 5.0.0.CR1
> HCA 4.0.5.Final
> HS 5.2.0.Final
>
> I am seeing the below errors.
>
> 1. The Hibernate Search test
> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
> is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L
>
> 2. In the
> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
> we are seeing a "java.lang.ClassNotFoundException:
> org.infinispan.commons.util.CloseableIteratorSet from [Module
> "org.hibernate.infinispan:main"http://pastie.org/10213943
>
> Scott
> ___
> 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] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

On 05/29/2015 01:05 PM, Sanne Grinovero wrote:
> Thanks Scott!
>
> 1. this error is expected: HS 5.2 is not compatible with ORM 5.
> We'll need a compatible WildFly version to release a compatible
> version, or alternatively know how to get the tests to run w/o the
> jipijapa patch as I was trying ;-)

In the interest of getting ORM 5 into WildFly 10 before HS is upgraded, 
we could disable 
org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase and 
create a blocking jira for WF10 assigned to you, so you can either 
enable the HibernateSearchJPATestCase test or remove Search from WildFly 
10 as you mention below (as a possible option).  Please let me know how 
you want me to proceed.

>
> A backup plan is we stop producing Hibernate Search modules for
> WildFly as part of our release, and split it up as a secondary task
> like Hardy suggested today on IRC.

>
> 2. this is not expected, especially as I think the Infinispan version
> already in WF is aligned with the one in ORM5?
> Steve, do you remember about classloader strategy changes between
> latest ORM 4.3 and 5.0.0.CR1?
>
> Sanne
>
>
> On 29 May 2015 at 17:50, Scott Marlow  wrote:
>> I ran part of the WildFly basic integration tests against the
>> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch,
>> which includes the following Hibernate versions:
>>
>> ORM 5.0.0.CR1
>> HCA 4.0.5.Final
>> HS 5.2.0.Final
>>
>> I am seeing the below errors.
>>
>> 1. The Hibernate Search test
>> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
>> is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L
>>
>> 2. In the
>> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
>> we are seeing a "java.lang.ClassNotFoundException:
>> org.infinispan.commons.util.CloseableIteratorSet from [Module
>> "org.hibernate.infinispan:main"http://pastie.org/10213943
>>
>> Scott
>> ___
>> 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] Changelog file in Hibernate ORM

[Gail Badner]

I would prefer retaining all bugs fixes that feed into EAP. 

The first Hibernate version used by EAP was roughly 3.2.4.sp1 (there were a few 
extra commits included in the version that got into EAP).

Are you planning to truncate the change logs for 3.2 or 3.3? If so, it would be 
helpful to me retain the bug fixes in those changelogs going back to at least 
3.2.4.sp1

FWIW, I'm fine with the changelog containing everything. I don't particularly 
care how large they get.

- Original Message -
> From: "andrea boriero" 
> To: "Sanne Grinovero" 
> Cc: "Hibernate Dev" 
> Sent: Friday, May 29, 2015 4:48:08 AM
> Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> 
> I would mantain all 5.x in the same changelog file and may be the previous
> one.
> 
> On 29 May 2015 at 12:32, Sanne Grinovero  wrote:
> 
> > I wouldn't stay awake at night because of that :) maybe only if the
> > file gets huge?
> > It's useful for people migrating, but since I doubt someone would
> > migrate from pre-1.0 (at least without expecting to rewrite it all),
> > that's why I suggested to keep from 3.0 onwards.
> >
> > On 29 May 2015 at 12:16, Steve Ebersole  wrote:
> > > So it makes sense to you that the changelog for 5.0 includes entries for
> > pre
> > > 1.0?
> > >
> > > On Fri, May 29, 2015 at 6:09 AM, Sanne Grinovero 
> > > wrote:
> > >>
> > >> I'm +1 especially to keep the changelog.txt file both maintained and
> > >> included.
> > >>
> > >> About pruning older content: I'd keep the past few years at least, for
> > >> sake of who's finally upgrading.
> > >> Maybe since version 3.0 onwards? Or just keep it all :)
> > >>
> > >> On 29 May 2015 at 12:05, Steve Ebersole  wrote:
> > >> > I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You
> > want
> > >> > to
> > >> > keep a massive changelog.txt containing all history forever?
> > >> >
> > >> > On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero  > >
> > >> > wrote:
> > >> >>
> > >> >> On 29 May 2015 at 08:15, Emmanuel Bernard 
> > >> >> wrote:
> > >> >> >
> > >> >> >> On 28 May 2015, at 10:42, Hardy Ferentschik 
> > >> >> >> wrote:
> > >> >> >>
> > >> >> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> > >> >> >>> +1 from me.  Although, on the other hand, do we really need to
> > keep
> > >> >> >>> maintaining that to begin with?  I guess I never thought simply
> > >> >> >>> having users
> > >> >> >>> go to the JIRA release notes was a big deal.  Just my $.02.
> > >> >> >>
> > >> >> >> Same for me on both counts, the proposed handling of changelog.txt
> > >> >> >> as
> > >> >> >> well as Brett's comment regarding the usefulness of this file
> > >> >> >> altogether.
> > >> >> >
> > >> >> > A more frequent than I thought usage of changelog vs JIRA is a mix
> > of
> > >> >> > Ctrl+F + quick scan to know what has changed in a library or know
> > >> >> > what is
> > >> >> > affecting me. JIRA is not the most intuitive UI in the universe.
> > With
> > >> >> > allt
> > >> >> > he bug statuses, the various intermediary releases to select etc,
> > >> >> > nothing
> > >> >> > beats changelog.txt.
> > >> >>
> > >> >> +1
> > >> >> - JIRA's UI is not too bad but let's remember that while we use it
> > >> >> since years, others might not feel comfortable with it
> > >> >> - many of those receiving our "dist" package might not have internet
> > >> >> access at all
> > >> >> - the dist packages is long term archived, like we include sources it
> > >> >> should contain a snapshot of all state. I like JIRA but who knows how
> > >> >> long it will be there?
> > >> >>
> > >> >> ___
> > >> >> 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] Hibernate ORM - next steps

[Steve Ebersole]

>
> * extend JPA criteria API with fluent support (does that mean embracing
> something like http://www.querydsl.com ? Os is that something different?


I was not the one who brought up "fluency".  TBH, I do not remember who
brought it up nor what it was about.

In regards to Criteria I had wanted to extend it to expose Hibernate-only
concepts and port things we support in our native Criteria API.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM - next steps

[Steve Ebersole]

I think Andy wanted to take a look at developing just the support to
references values by position rather than by alias without waiting on the
bigger task.  I don't think that is possible; at the least it is A LOT of
work much of which might change later when we do work on the bigger task.

I know personally, time/resources aside, the biggest reason I have not
worked a lot on the bigger task (other than my initial work on the new
query parser) is because I had hoped a solution would present itself to the
Antlr 4 quandary.  But it hasn't and likely wont and I think Gunnar and
Sanne and I are all in agreement that it probably just makes sense to base
this work on Antlr 3.

On Fri, May 29, 2015 at 11:31 AM, John O'Hara  wrote:

> On 20/05/15 02:47, Steve Ebersole wrote:
> > Now that 5.0 is settling down I wanted to start planning where we go from
> > here in terms of feature development and schedule/releases.
> >
> > Here is my high-level list of features/work:
> > * rework SQL generation & HQL parser
> > * change JDBC extraction to work by position, rather than alias
> (reworking
> > SQL generation is a prerequisite)
> +1
> I had been tasked to start investigating the two features above, as we
> have seen them to impact performance in the past. If you would like an
> additional pair of hands on either/both of these, please let me know
>
> > * rework annotation binding (Jandex, etc)
> > * extended orm.xml, deprecate hbm.xml
> > * discriminator-based multi-tenancy
> > * port Hibernate Criteria constructs to JPA criteria, begin deprecation
> of
> > Hibernate Criteria
> > * extend JPA criteria API with fluent support
> > * ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
> > * merging hibernate-entitymanager into hibernate-core
> > * continue to fill out bytecode enhancement capabilities
> >
> > Some of these are more involved than others.  The task for re-writing SQL
> > generation is a HUGE undertaking, but also has many huge benefits.
> > Re-writing annotation binding is another huge undertaking, but again with
> > many benefits.
> >
> > Any others we should add to the list here?
> >
> > And then we can work on scheduling them.
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> John O'Hara
> joh...@redhat.com
>
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
> (USA) and Michael O'Neill (Ireland).
>
> ___
> 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] Changelog file in Hibernate ORM

[Steve Ebersole]

I am only planning to truncate this moving forward.  In fact it is already
done in master, aside from adding notes about where the 5.0 changes
dovetail with 4.3 changes.

On Fri, May 29, 2015 at 12:43 PM, Gail Badner  wrote:

> I would prefer retaining all bugs fixes that feed into EAP.
>
> The first Hibernate version used by EAP was roughly 3.2.4.sp1 (there were
> a few extra commits included in the version that got into EAP).
>
> Are you planning to truncate the change logs for 3.2 or 3.3? If so, it
> would be helpful to me retain the bug fixes in those changelogs going back
> to at least 3.2.4.sp1
>
> FWIW, I'm fine with the changelog containing everything. I don't
> particularly care how large they get.
>
> - Original Message -
> > From: "andrea boriero" 
> > To: "Sanne Grinovero" 
> > Cc: "Hibernate Dev" 
> > Sent: Friday, May 29, 2015 4:48:08 AM
> > Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> >
> > I would mantain all 5.x in the same changelog file and may be the
> previous
> > one.
> >
> > On 29 May 2015 at 12:32, Sanne Grinovero  wrote:
> >
> > > I wouldn't stay awake at night because of that :) maybe only if the
> > > file gets huge?
> > > It's useful for people migrating, but since I doubt someone would
> > > migrate from pre-1.0 (at least without expecting to rewrite it all),
> > > that's why I suggested to keep from 3.0 onwards.
> > >
> > > On 29 May 2015 at 12:16, Steve Ebersole  wrote:
> > > > So it makes sense to you that the changelog for 5.0 includes entries
> for
> > > pre
> > > > 1.0?
> > > >
> > > > On Fri, May 29, 2015 at 6:09 AM, Sanne Grinovero <
> sa...@hibernate.org>
> > > > wrote:
> > > >>
> > > >> I'm +1 especially to keep the changelog.txt file both maintained and
> > > >> included.
> > > >>
> > > >> About pruning older content: I'd keep the past few years at least,
> for
> > > >> sake of who's finally upgrading.
> > > >> Maybe since version 3.0 onwards? Or just keep it all :)
> > > >>
> > > >> On 29 May 2015 at 12:05, Steve Ebersole 
> wrote:
> > > >> > I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You
> > > want
> > > >> > to
> > > >> > keep a massive changelog.txt containing all history forever?
> > > >> >
> > > >> > On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero <
> sa...@hibernate.org
> > > >
> > > >> > wrote:
> > > >> >>
> > > >> >> On 29 May 2015 at 08:15, Emmanuel Bernard <
> emman...@hibernate.org>
> > > >> >> wrote:
> > > >> >> >
> > > >> >> >> On 28 May 2015, at 10:42, Hardy Ferentschik <
> ha...@hibernate.org>
> > > >> >> >> wrote:
> > > >> >> >>
> > > >> >> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> > > >> >> >>> +1 from me.  Although, on the other hand, do we really need
> to
> > > keep
> > > >> >> >>> maintaining that to begin with?  I guess I never thought
> simply
> > > >> >> >>> having users
> > > >> >> >>> go to the JIRA release notes was a big deal.  Just my $.02.
> > > >> >> >>
> > > >> >> >> Same for me on both counts, the proposed handling of
> changelog.txt
> > > >> >> >> as
> > > >> >> >> well as Brett's comment regarding the usefulness of this file
> > > >> >> >> altogether.
> > > >> >> >
> > > >> >> > A more frequent than I thought usage of changelog vs JIRA is a
> mix
> > > of
> > > >> >> > Ctrl+F + quick scan to know what has changed in a library or
> know
> > > >> >> > what is
> > > >> >> > affecting me. JIRA is not the most intuitive UI in the
> universe.
> > > With
> > > >> >> > allt
> > > >> >> > he bug statuses, the various intermediary releases to select
> etc,
> > > >> >> > nothing
> > > >> >> > beats changelog.txt.
> > > >> >>
> > > >> >> +1
> > > >> >> - JIRA's UI is not too bad but let's remember that while we use
> it
> > > >> >> since years, others might not feel comfortable with it
> > > >> >> - many of those receiving our "dist" package might not have
> internet
> > > >> >> access at all
> > > >> >> - the dist packages is long term archived, like we include
> sources it
> > > >> >> should contain a snapshot of all state. I like JIRA but who
> knows how
> > > >> >> long it will be there?
> > > >> >>
> > > >> >> ___
> > > >> >> 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 l

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Steve Ebersole]

Scott, first please use a SNAPSHOT build as you'll need it for the HCANN
fix I did, or you could just pull in the newest HCANN (5.0.0.Final)

As for the ClassNotFoundException, I really do not get this one.  So,
essentially:

1) hibernate-infinispan is able to access infinispan-core classes
2) hibernate-infinispan makes use of
this org/infinispan/commons/util/CloseableIteratorSet class as returned
from classes contained in infinispan-core.  I am not sure which jar
holds org/infinispan/commons/util/CloseableIteratorSet.
Anyone?
3) hibernate-infinispan is not able to access
org/infinispan/commons/util/CloseableIteratorSet

On Fri, May 29, 2015 at 11:57 AM, Scott Marlow  wrote:

> Also am using Infinispan 7.2.1.Final but noticed that Infinispan
> 7.2.2.Final is now in WildFly 10, so I'll sync my branch with WF master
> to upgrade Infinispan.
>
> On 05/29/2015 12:50 PM, Scott Marlow wrote:
> > I ran part of the WildFly basic integration tests against the
> > https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch,
> > which includes the following Hibernate versions:
> >
> > ORM 5.0.0.CR1
> > HCA 4.0.5.Final
> > HS 5.2.0.Final
> >
> > I am seeing the below errors.
> >
> > 1. The Hibernate Search test
> >
> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
> > is failing with an AbstractServiceMethodError
> http://pastebin.com/CzEgVp0L
> >
> > 2. In the
> >
> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
> > we are seeing a "java.lang.ClassNotFoundException:
> > org.infinispan.commons.util.CloseableIteratorSet from [Module
> > "org.hibernate.infinispan:main"http://pastie.org/10213943
> >
> > Scott
> > ___
> > 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] WildFly 10 + Hibernate ORM 5 integration status update...

[Steve Ebersole]

On Fri, May 29, 2015 at 12:05 PM, Sanne Grinovero 
wrote:

> 2. this is not expected, especially as I think the Infinispan version
> already in WF is aligned with the one in ORM5?
> Steve, do you remember about classloader strategy changes between
> latest ORM 4.3 and 5.0.0.CR1?


The only one that stands out to me is that 5.0 does absolutely zero
fiddling with the TCCL, whereas 4.3 did.  But 4.3 did that only during
bootstrap, here bootstrap is well over and done.  TBH this sounds much more
like a bad classpath definition on the part of WF/Jipijapa (see my earlier
reply)
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

On 05/29/2015 02:03 PM, Steve Ebersole wrote:
> Scott, first please use a SNAPSHOT build as you'll need it for the HCANN
> fix I did, or you could just pull in the newest HCANN (5.0.0.Final)

Will do.

>
> As for the ClassNotFoundException, I really do not get this one.  So,
> essentially:
>
> 1) hibernate-infinispan is able to access infinispan-core classes
> 2) hibernate-infinispan makes use of
> this org/infinispan/commons/util/CloseableIteratorSet class as returned
> from classes contained in infinispan-core.  I am not sure which jar
> holds org/infinispan/commons/util/CloseableIteratorSet.  Anyone?

infinispan-commons-7.2.1.Final.jar contains 
org.infinispan.commons.util.CloseableIteratorSet


> 3) hibernate-infinispan is not able to access
> org/infinispan/commons/util/CloseableIteratorSet
>
> On Fri, May 29, 2015 at 11:57 AM, Scott Marlow  > wrote:
>
> Also am using Infinispan 7.2.1.Final but noticed that Infinispan
> 7.2.2.Final is now in WildFly 10, so I'll sync my branch with WF master
> to upgrade Infinispan.
>
> On 05/29/2015 12:50 PM, Scott Marlow wrote:
>  > I ran part of the WildFly basic integration tests against the
>  > https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5
> branch,
>  > which includes the following Hibernate versions:
>  >
>  > ORM 5.0.0.CR1
>  > HCA 4.0.5.Final
>  > HS 5.2.0.Final
>  >
>  > I am seeing the below errors.
>  >
>  > 1. The Hibernate Search test
>  >
> 
> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
>  > is failing with an AbstractServiceMethodError
> http://pastebin.com/CzEgVp0L
>  >
>  > 2. In the
>  >
> 
> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
>  > we are seeing a "java.lang.ClassNotFoundException:
>  > org.infinispan.commons.util.CloseableIteratorSet from [Module
>  > "org.hibernate.infinispan:main"http://pastie.org/10213943
>  >
>  > Scott
>  > ___
>  > 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] WildFly 10 + Hibernate ORM 5 integration status update...

[Steve Ebersole]

So:
1) hibernate-infinispan seems to be able to see infinispan-core (which is
what defines as a dependency)
2) hibernate-infinispan seems to not be able to see infinispan-commons
(which I would have to assume infinispan-core defines as a dependency)

This sure seems like a problem in the WF module/classpath set up...


On Fri, May 29, 2015 at 1:21 PM Scott Marlow  wrote:

>
>
> On 05/29/2015 02:03 PM, Steve Ebersole wrote:
> > Scott, first please use a SNAPSHOT build as you'll need it for the HCANN
> > fix I did, or you could just pull in the newest HCANN (5.0.0.Final)
>
> Will do.
>
> >
> > As for the ClassNotFoundException, I really do not get this one.  So,
> > essentially:
> >
> > 1) hibernate-infinispan is able to access infinispan-core classes
> > 2) hibernate-infinispan makes use of
> > this org/infinispan/commons/util/CloseableIteratorSet class as returned
> > from classes contained in infinispan-core.  I am not sure which jar
> > holds org/infinispan/commons/util/CloseableIteratorSet.  Anyone?
>
> infinispan-commons-7.2.1.Final.jar contains
> org.infinispan.commons.util.CloseableIteratorSet
>
>
> > 3) hibernate-infinispan is not able to access
> > org/infinispan/commons/util/CloseableIteratorSet
> >
> > On Fri, May 29, 2015 at 11:57 AM, Scott Marlow  > > wrote:
> >
> > Also am using Infinispan 7.2.1.Final but noticed that Infinispan
> > 7.2.2.Final is now in WildFly 10, so I'll sync my branch with WF
> master
> > to upgrade Infinispan.
> >
> > On 05/29/2015 12:50 PM, Scott Marlow wrote:
> >  > I ran part of the WildFly basic integration tests against the
> >  > https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5
> > branch,
> >  > which includes the following Hibernate versions:
> >  >
> >  > ORM 5.0.0.CR1
> >  > HCA 4.0.5.Final
> >  > HS 5.2.0.Final
> >  >
> >  > I am seeing the below errors.
> >  >
> >  > 1. The Hibernate Search test
> >  >
> >
>  (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
> >  > is failing with an AbstractServiceMethodError
> > http://pastebin.com/CzEgVp0L
> >  >
> >  > 2. In the
> >  >
> >
>  
> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
> >  > we are seeing a "java.lang.ClassNotFoundException:
> >  > org.infinispan.commons.util.CloseableIteratorSet from [Module
> >  > "org.hibernate.infinispan:main"http://pastie.org/10213943
> >  >
> >  > Scott
> >  > ___
> >  > hibernate-dev mailing list
> >  > hibernate-dev@lists.jboss.org  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] HSearch + Tika bridge using Wildfly modules

[Brett Meyer]

Sanne, I might still be missing something.  Artificer's war does not include 
any Hibernate ORM, Hibernate Search, or Tika jars.  For Wildfly 8.2, the war's 
jboss-deployment-structure.xml includes:

 (includes tika-parsers-1.6.jar)

(Also using the org.hibernate module, but that's implicitly added by Wildfly.)

I understand what you're saying about the ORM classloader, but the above still 
didn't work.  I'm admittedly a little fuzzy on WF module classloading, but I'm 
wondering if that's not actually making its way into the ORM classloader, even 
though my war is the persistence unit.

However:

What *does* work is adding '' 
directly in org.hibernate.search.engine's module.xml.

Apologies if 1.) I'm missing something and/or 2.) that's expected.  I can 
certainly tweak org.hibernate.search.engine's module.xml with our installer, 
but that's obviously less than desirable.  Any idea what we might be missing 
that would allow us to get that to work from the app itself?

Thanks for the help!

- Original Message -
> From: "Sanne Grinovero" 
> To: "Brett Meyer" 
> Cc: "Hibernate.org" 
> Sent: Friday, May 29, 2015 11:00:12 AM
> Subject: Re: HSearch + Tika bridge using Wildfly modules
> 
> Hi Brett,
> we don't include all existing analysers and extensions within the
> WildFly modules. In particular the Apache Tika libraries have a huge
> amount of dependencies, you should choose the ones you need depending
> on what kind of media you intend to parse.
> 
> Include any extension in your "application", we use the Hibernate ORM
> classloader to lookup for extensions so these should be discoverable
> if they are visible to the same classloader having your entities and
> other extensions.
> 
> Sanne
> 
> On 29 May 2015 at 15:28, Brett Meyer  wrote:
> > Hey Sanne!  Artificer has ' > services="export" />' defined in its jboss-deployment-structure
> > dependencies.  But, when we try to use it, the following happens.
> >
> > Caused by: java.lang.ClassNotFoundException: org.apache.tika.parser.Parser
> > from [Module "org.hibernate.search.engine:main" from local module loader
> > @6cf76647 (finder: local module finder @665bf734 (roots:
> > /home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules,/home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules/system/layers/base))]
> >
> > One of our entities uses the built-in TikaBridge.  I figured the search.orm
> > module would bring the necessary Tika jars in with it.  Is there something
> > else we need to add?
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev