Hibernate Search dependency needed since 0.11.1.

[asauvez]

In version 0.9.8, one could use querydsl without having Hibernate Search. In version 0.11.1, there is now a @org.hibernate.search.annotations.Field on fr.openwide.core.jpa.business.generic.model.GenericEntity.getId(), so you have to depends on Hibernate Search to use GenericEntity.

A workaround would be to have a SearchableGenericEntity subclass (or interface?) that override getId() to add the @field annontation.

Adrien

[gsmet]

No, the workaround would be to use Hibernate Search :).

[yrodiere]

Thanks for your feedback, and sorry for the delay: it seems I hadn't enabled notifications on GitHub.

To be fair, Hibernate Search has always been a dependency of owsi-core-component-jpa. If you did use it previously without making Hibernate Search one of your project's dependencies, you probably had to exclude dependencies, and it seems unlikely that our project would support arbitrary dependency exclusion.

Moreover, this annotation hasn't been added as a new feature, but in order to support the same features as we used to: the id previously was an "implicit" field in Hibernate Search, and is not anymore.

Back to the point, introducing a SearchableGenericEntity would not be satisfying since we have multiple subclasses of GenericEntity in OWSI-Core itself, and we definitely wouldn't want to provide two flavors of each subclass.
Using an interface might work (though I'm not sure Hibernate Search supports it), but would force our existing projects based on OWSI-Core to implement this interface on each and every entity.

All in all, I tend to agree with @gsmet: it's much easier for you to include Hibernate Search in your dependencies (even though you don't use it) than for projects using Hibernate Search to adapt to that kind of change. IIRC, there is no runtime effect to just having Hibernate Search in your class path: it needs to be explicitly enabled, and obviously you did not when you used OWSI-Core 0.9.

We could consider splitting OWSI-Core's modules differently in the future (in order to avoid that kind of issues), but that will have to wait for a major version (very major, I'd say).