I don't think someone is actually going to use more than a single DI
framework and even if they do, they will probably bridge one way or
another between the DI frameworks to be able to access beans from one in
the other.
So I don't think we should do "compositions" since it's not a big deal
to
https://hibernate.atlassian.net/browse/HHH-11259 and friends are mainly
about back porting the work I did on 6.0 for the ManagedBeanRegistry
abstraction over dependency injection containers. We will ship support for
CDI as well as non-managed beans (things we directly instantiate). Of
course we'd
On Wed, Dec 13, 2017 at 7:05 AM Sanne Grinovero wrote:
> Not really. Think of it as Deprecation: it will trigger some warnings
> for end users, especially those who didn't get the "news" of moving to
> the new API, and keep things working for a little longer for those
> people not willing (able?)
Just to be sure, including an EPL-licensed item is fine as far as WildFly
is concerned? Other than that, +1 for that change.
2017-12-13 14:04 GMT+01:00 Sanne Grinovero :
> On 13 December 2017 at 13:54, Steve Ebersole wrote:
> > Considering the spec contracts are defined by the EG under the JCP,
On 13 December 2017 at 03:38, Steve Ebersole wrote:
> I think that's a great idea. Was just an oversight on my part.
Cool, that's HHH-12163 then.
>
> On Tue, Dec 12, 2017 at 7:19 PM Sanne Grinovero wrote:
>>
>> Hi all,
>>
>> there's a feature request about including the (currently missing) bit
On 13 December 2017 at 13:54, Steve Ebersole wrote:
> Considering the spec contracts are defined by the EG under the JCP, I'm not
> sure where we ever stood legally with publishing this under any other
> license. Either way, I am not concerned about the license aspect - I think
> it is a reasonab
Considering the spec contracts are defined by the EG under the JCP, I'm not
sure where we ever stood legally with publishing this under any other
license. Either way, I am not concerned about the license aspect - I think
it is a reasonable expectation that if I am using a jar produced by a spec
th
Seems like the right thing to do. I'm just concerned about the license. Is
it identical?
Some people might be upset to get a new dependency pulled "automatically"
if it has a stricter license...
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 13 December 2017 at 13:10, Sanne Grinovero
Looks like the general agreement is that we will no longer need
- https://github.com/hibernate/hibernate-jpa-api
As we're switching to the standard API distribution, finally available:
javax.persistence:javax.persistence-api:2.2
Still I expect there's going to be some confusion about this, e.g.
