[hibernate-dev] No Hibernate Search version compatible with Hibernate ORM 5.2.0.Final

[Sanne Grinovero]

On 20 June 2016 at 12:03, Gunnar Morling <gunnar at hibernate.org> wrote:
> What changes are we talking here specifically? Have they been done
> intentionally or by accident?

The change with highest impact on Search is that the various Query API
interfaces have been moved.

The legacy contracts still exist in the original location, but are
deprecated and extend the new types; this might be all good for end
users - and necessary as some JPA and "native" APIs have been merged
-, but we actually extend these interfaces with the Fulltext versions,
and have custom implementations of each.. which implies we now have to
implement also the new methods of the new contracts.

It might be possible to introduce a base class in ORM for Search to
extend - like we did in the past for other components -  but even
doing so this same base class should also be backported to older ORM
versions which we want to support with the same Search build; this
means we could support newer bugfix releases of the older minor
branches, but the trick won't work with e.g. existing Wildfly unless
we get them to do a release with such a newly patched ORM.

BTW it's all non-trivial as other elements which need to be passed the
Query implementations - like Metadata related types - have also been
moved.

Then there are several smaller issues which could be easily solved,
but add up in complexity: eg some services have been moved in a
different SPI package, and Search used to lookup these services by
class type. We'd need to re-introduce the old service type as a
deprecated interface within the ORM sources, and patch ORM's
serviceregistry so that when asking X you actually get the newer
version Y of that same service (downcasted).

These minor things are doable but are a pointless exercise if the
bigger impact issues (the Query API) don't get addressed as well.

The doubt is that this is all not worth it: ideally I'd prefer to have
Hibernate Search stick on ORM 5.1 for a while longer, and upgrade to
ORM 5.2 when a WildFly 10.x release introduces ORM 5.2, or if we could
have those ORM 5.2 modules for any WildFly version.
At that point we'll require ORM 5.2, let's aim at not have people wait
too long for that - at least we'd be spending energy in forward-moving
progress rather than on maintenance which will be useless soon enough.

Thanks,
Sanne


>
> For the better or worse, ORM - so far - doesn't stick to SemVer rules, so I
> don't think we should revert anything which has been changed on purpose.
> Different story for accidental changes of course.
>
> In HSEARCH we are using a tool named "japicmp"
> (http://siom79.github.io/japicmp/) for creating a report with changed public
> API/SPIs. Running this prior to a release - comparing to the last stable
> version - helps to detect any unintentional changes and create a public
> report / migration notes for intentionally changed things.
>
>
> 2016-06-20 12:47 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 20 June 2016 at 08:33, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> > Are the incompatibilities here for good on ORM, or could they be
>> > reverted / softened in the 5.2 branch to allow for an easier path?
>>
>> I'm working on a set of PRs for both ORM and Search which reduce the
>> list of incompatibilities,
>> but while the amount of issues is getting lower I strongly suspect
>> that I won't be able to get it down to zero.
>>
>> Of course some more changes on ORM SPIs could be reverted but I don't
>> feel like that's something we could do in a micro..
>>
>> -- Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>