[hibernate-dev] Hibernate Search being integrated in WildFly

[Hardy Ferentschik]

On 14 Jan 2014, at 12:25, Sanne Grinovero <sanne at hibernate.org> wrote:

>> +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.

ok

>> 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..

Reminds me of JBoss Logging. How are users supposed to understand all this,
if even between developers the only form of information is by word of mouth.

>>> - 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.

+1

>> 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).

Don’t you think that a lot of users might hold of an upgrade, because they want a final
or at least CR release? If we want people to use 4.5 we might need to give them
a final sooner than later. I don’t see the mentioned issues addressed in the near
future. Guillaume for example won’t be able to look at the mass indexer until some
time February. Is it in this case not better to do a 4.5.0.Final and then add the 
mentioned features in a 4.5.x release?

>>> 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.

“Should”!? LOL. 
Is this via jboss-deployment-strucure? I guess we would at least somehow change the module
names on our side to avoid conflicts with the wildfly provided ones. TBH, I am not a big fan of this.
If I were a user, I’d rather update the existing modules, instead of adding new ones and needing to
add magic xml files.

—Hardy