[hibernate-dev] 6.0 Alpha1 prep

[Steve Ebersole]

Comments inline.

However, a general point - the argument about "seamless" support for people
upgrading is a bit misguided here I think.  The argument is that someone
can just change the version and everything will work as before.  But we
know that is not the case.  They will also have to change the groupId.  So
its already a requirement for users to go back and change their
dependencies in a non-trivial way...


On Wed, Dec 5, 2018 at 9:37 AM Sanne Grinovero <sanne at hibernate.org> wrote:

>
> >    - `hibernate-infinispan` - support for using Infinispan as a Hibernate
> >    L2C has been moved to the Infinispan project. Again, IMO this module
> should
> >    go away.  Thoughts?
>
> About this one, and the `hibernate-envers` you mentioned in previous
> email, it would be nice to help people a little more. Especially
> Envers's integration as it just happened.
>

We already deprecated hibernate-infinispan as of 5.2 or 5.3.  Cannot
remember atm if we did an actual relocation though.

But it is definitely a valid point about envers.  What we had planned was
to keep the hibernate-envers *artifact* as an "empty" jar and add a
relocation though I am not sure Maven likes pom with a relocation that also
has a jar...

However, I do think we should remove envers as (1) an karaf feature
(hibernate-osgi) and as a WF module (hibernate-orm-modules).


I wouldn't make it a release requirement though; I propose to not get
> distracted by such details at this stage - we can always add a
> truckload of such metadata later according to feedback - even beyond a
> 0.Final
>

Not a "requirement".  Let's say a VERY-nice-to-have.  The more of these
container integrations we can enable, the wider our potential pool of early
adopters...


> Similarly the WildFly modules I contributed just recently :-/ .. feel
> free to remove those, we'll see to re-introduce support as needed, and
> IF needed.
>
> I'd propose to ignore OSGi headers as well - not sure of the
> consequences though, so let's keep it IF it's not too much of a
> burden. We can re-introduce support and tests in a later feature
> release.
>

The OSGi headers (assuming you mean the headers added to the jar manifests)
are trivial and I am not sure why you think those would be a problem.  More
likely, you probably mean hibernate-osgi which to me fits into the
"container integration" discusasion above.