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
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/
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)
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
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) hibe
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 fir
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
>
> * 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
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 re
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 tryin
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 m
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/scottma
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.
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 wo
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
> (di
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 "applicati
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 fr
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
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
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 real
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
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
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
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 e
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 Emmanue
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, Emmanue
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 w
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 h
> 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
29 matches
Mail list logo
