[wildfly-dev] Enabling Hibernate Search to all Hibernate/JPA users

[Sanne Grinovero]

On 1 August 2014 14:29, Scott Marlow <smarlow at redhat.com> wrote:
> On 08/01/2014 06:58 AM, Sanne Grinovero wrote:
>>
>> Currently users wishing for Search super-powers in their Hibernate
>> applications need to enable the module explicitly.
>>
>> This seems to be rather annoying, and we have questions like this one:
>>   - https://community.jboss.org/thread/243346
>
>
> I responded to this particular question, which was how to enable a module to
> be available from all deployments.  That really has nothing to do with
> Hibernate Search.

Thanks!
But still that post is yet-another sign as I commonly see on Hibernate
forums of people struggling to enable it: people migrating from other
systems are used to see Search automatically enable itself without
need of further hassle.

Also people tend to not perceive it as an independent thing from the
main Hibernate ORM, so when it doesn't work the modules system is the
last thing they think to check.


>> I see no reasons to not enable it by default, following the same
>> activation rules of other Hibernate dependencies: it's very
>> conservative about not auto-enabling itself when not needed.
>
>
> Are you asking if its possible to have Hibernate Search deployment code that
> detects use of Hibernate Search (perhaps after noticing use of some
> Hibernate Search annotation) and adds a deployment dependency on some
> Hibernate search module as a result?

For user experience it shouldn't be different than Hibernate Envers.

Implementation wise it's probably going to be slightly different, for
example we have an independent versioning from ORM.

I have no strong opinion on how we should do it, a simple solution
would be to merge it with Hibernate ORM, like you did for Envers: it's
a single jar, and having slot "main" the version mismatch doesn't
matter.
Alternatively the JPA deployer could add it to the user classpath like
it does with the one for Hibernate ORM, but keeping the modules
separate.
I see detection as a nice to have: since it's functionally redundant
with the detection performed by the code in Hibernate, we can tackle
that at a second time.

>>
>> May I open such a feature request? Happy to try the patching myself.
>
>
> Not sure.  I wonder if it would be better to have a separate Hibernate
> Search profile for WildFly that includes deployment code to automatically
> add application dependencies on Hibernate Search.

A profile for a single jar?
We only need the one in the (existing) module
"org.hibernate.search.orm": very similar to Envers, it was simply a
mistake to not expose it by default from the beginning.

>
> For this to work, I think that Infinispan's dependency on Hibernate Search
> would need to not cause clustering/2lc failures when the Hibernate Search
> module profile is not installed.

True, but that has been taken care of ;-) it's already nicely split in
different JBoss Modules, and Infinispan depends on a different module
"org.hibernate.search.engine", shared among the various projects
depending on the engine.

>
> I think this would be nice as it would lay the groundwork for Search to be
> separate (depending on how you feel about that). :)

I agree, but it's a different aspect to get the dependency modularity
right, and making sure the users don't get confused.
I think the modules are correct already, now I'd like to make it easy to use.

Sanne