Hello,
I take advantage of the topic to say that there is an `integrationtests`
module in Infinispan too using feature packs, which are usings in turn the
feature packs of the Hibernate Search 5.
I have to ask the ISPN guys on Zulip about that, maybe they have already
planned to remove such module
We have a PR for this now, if someone would like to have a look:
- https://github.com/hibernate/hibernate-orm/pull/3347
One thing to note, is that it also removes all Arquillian based tests:
we had some which were testing more than just the basics of our
feature pack; although most had been disab
On Thu, 16 Apr 2020 at 15:42, Steve Ebersole wrote:
>
> Bit off track, but since you mentioned load, etc... Take a look at the
> IdentifierLoadAccess, etc variants for loading. E.g.
>
> interface IdentifierLoadAccess {
> T getReference(Object id);
> T load(Object id);
> Optional load
> Any specific reason you say that Yoann?
No, I was just thinking that moving to Jarakarta JPA and Jakarta CDI had a
high chance of breaking OSGi tests, unless the Jakarta artifacts properly
support OSGi.
But it was just a hunch; if it works, I don't have anything against keeping
it.
Yoann Rodi
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.jbo
Bit off track, but since you mentioned load, etc... Take a look at
the IdentifierLoadAccess, etc variants for loading. E.g.
interface IdentifierLoadAccess {
T getReference(Object id);
T load(Object id);
Optional loadOptional(Object id);
}
Granted I'm partial, but I think that's prett
I do not plan on dropping hibernate-osgi. Its there; it works. Any
specific reason you say that Yoann?
Brett is the only one to do anything with that "tutorial". Though as time
went on its focus was more a way to find problems when the paxexam tests
failed - they almost always give useless feed
I would agree with you all about the general sentiment against the use
of Optional, but there's one use case in which I think it might make
sense (although bear with me as I've never really used it much yet) :
there's several methods on the standard Session and EntityManager in
Hibernate ORM to fe
Agreed, I'll remove it. Thanks Steve and Yoann!
I'll remove them from 5.5 soon, you can then merge the removal in 6.0
or do it differently if that's easier.
This is the JIRA:
- https://hibernate.atlassian.net/browse/HHH-13952
Regarding OSGi (which Yoann raised): I agree we shouldn't spend
sign
Considering the changes in WildFly, I also think we should just drop
hibernate-orm-modules.
For 6.0 I will definitely do this. I also think removing it is good for
5.5.
Not sure it is even worth the hassle for earlier releases however.
On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero wrote:
>
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
11 matches
Mail list logo
