[hibernate-dev] Hibernate Search being integrated in WildFly

[Sanne Grinovero]

On 14 January 2014 11:23, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
> On 14 Jan 2014, at 00:06, Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> as you might already know by following the WildFly developer's mailing
>> list, most of the Hibernate Search jars and dependencies (Lucene) are
>> now included in the application server as modules.
>
> Right. Still not sure whether this is such a great idea, but I guess it is too late.

Not sure either, but worst case we have our own release, so there
probably are no negative aspects (?).
More on this below.

>> Just a couple of small adjustments are needed to make it possible for
>> Hibernate users to also take advantage of it, so I'd think we should
>> make these adjustments to make it more useful?
>>
>> This is what I'm thinking:
>> - The hibernate-search-orm jar is missing (an essential jar for our purposes)
>>   -> add a module
>
> +1 Does this really need a separate module?

It's probably not strictly needed, but I think it's preferable so that
people can use a different version of it.
Also, it's our tested configuration.

>> - No additional analyzers are included
>>   -> see how optional modules work, so that - while we won't ship all
>> those dependencies - it's still easy to add when you need one
>
> Is there some info about “optional” modules? I find information about modules
> in general hard to find.

I wasn't aware of it either, I just learned about it in the face to
face meeting.
Need to try it out though..

>
>> - Jipijapa should help?
>>   -> should we make Hibernate Search available to deployments
>> whenever Hibernate ORM is made available?
>
> Per default? So if there are no indexed entities nothing happens and if there are
> Search gets automatically enabled? Is this what you are saying?

Yes. Should be great for usability.

>
>> - Get it to a reasonable version: it's including 4.5.0.Alpha2 now
>>   -> we need to release a Beta soon, any volunteer? I'm stuck on an
>> island with extremely slow connectivity.
>
> I can do a release. Just wondering whether it should be a CR already?
> The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we already upgraded now
> to 4.3.0.Final (just not released yet). So it would really be time to get 4.5.0.Final out.
> We could cut a CR release and if nothing comes up promote it to 4.5 final in a couple of weeks.

We also have the Infinispan indexmanager on the roadmap. All work was
done a year ago already, and the Infinispan issues which prevented me
to merge it at the time are fixed, so I should only need to rebase it.

I would love to merge it, but let's set a deadline for it.. if I can't
make it we release without it again :-(

Also I'm worried about HSEARCH-1260 and Guillaume's report. It would
be nice to get rid of those issues by applying the cleanup I've
suggested on that thread.

I fundamentally agree that if we don't address these quickly, we
should aim at a quick Final, still let's not rush it too much as
WildFly doesn't stricly need a Final from us (or at least I wasn't
asked for one).

>
>> - Contribute some integration tests to WildFly: there aren't any
>> today verifying the included modules
>
> +1
>
>> What shall we do about our modules distribution? I think it would be
>> nice to continue maintaining that, so that we can make frequent
>> releases and that would allow users to use a different version than
>> what they would get in WildFly - if they want to.
>
> Not sure.  The module won’t be a pure drop-in anymore. Now the module needs
> to make sure that existing module(s) get properly “reconfigured”. What I mean is that
> we might have to do more than extracting a tar ball. We might need to remove/change
> existing files as well. Is it not easier to provide instructions on how to update the exiting modules?

Changing existing modules is highly discouraged and creates problems
to potentially deploying other frameworks who depend on it: there
should be a way to override the version that a specific deployment
wants to use.
This way, we can make it a "pure drop-in", without changing any existing files.

> Unfortunately, this comes at a non optimal point in time. Not only will it take time from the
> Lucene 4 migration (aka Search 5), but if Search 4.x gets included now we probably will get very
> quickly people asking on how to use Search 5 with Wildfly. If nothing else a lot of dependencies
> change at this point. It won’t be a simple replace of a single jar

+1, that's why I think we should keep _also_ releasing our own modules.

> Will/Can CapeDwarf and clustering also switch to Search 5 once we start making releases?

We're going to make it very interesting for them, so I'm sure they'll
find a solution :-)
Very likely, next version of WildFly will use 5, but now that it's
approaching a Final version, it's probably not too bad that we provide
a stable version.

 -- Sanne

>
> —Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev