[hibernate-dev] Modularization of Search

[Sanne Grinovero]

2010/3/16 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> On 16 mars 2010, at 20:05, Hardy Ferentschik wrote:
>
>> On Tue, 16 Mar 2010 15:38:40 -0300, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>
>>> What's the list of all potential modules? Then let's see if we want to minimize some or create bundles
>>>
>>> hibernate-search-core
>>
>> Here I had in mind to use just hibernate-search so that the main artifact keeps its name.
>>
>>> hibernate-search-hibernate
>>
>> Not sure what you envision to go in there. I did not have this on the list and I am not quite sure
>> what would be in there.
>
> All the Hibernate specific APIs (FullTextQuery, FullTextSession)
>
>>
>>> hibernate-search-jpa
>>
>> This is the one I want to avoid, since we really don't have any specific JPA code. The only use we have
>> of JPA at the moment is that we use @Id as document id in case @DocumentId is not specified. This use
>> is, however, via reflection and we never actually load any javax.persistence classes. In the testsuite
>> we are making of course heavy use of JPA to build our tests. I might have an idea on how to deal with
>> this. I don't think we need this module.
>
> All the JPA specific APIs (FullTextQuery, FullTextSession)
>
> That being said, I'm ok with merging some modules (the previous two are good candidates)
>
>>
>>> hibernate-search-jms
>>> hibernate-search-jgroups
>>> hibernate-search-infinispan
>>
>> I guess it makes sense to start creating modules for the different clustering solutions. I think
>> this three modules will also make it more transparent what you need if you want to use clustering
>>
>>> hibernate-search-util
>>
>> I guess we could create this module, but I would like to avoid it. I guess I would then rather split
>> out the test into a hibernate-search-testsuite
>
> Four options here:
>  - do this -util module
>  - do a -testsuite module
>  - do the test artifact (Sanne's current commit)
>  - do not split the 3 util classes out
>
> So far I think the last two solutions are the less annoying
>

I don't feel comfortable in having the testing in a different module
than what it's supposed to test, will be hard to prevent circular
dependencies even if it was relating to some utilities.
We don't have that much testing utilities, and as Emmanuel said before
there's the chance of somebody committing without noticing a test
failing in another module.

>>
>>> hibernate-search-testutil
>>
>> Ok

I'm still confused about the differences between a
hibernate-search-testutil and the "-util" module mentioned on the
previous point. ?

>>
>>> hibernate-search-perftest
>>
>> I guess we could do this as well.
>>
>>
>>> anything else?
>>
>> What did we decide on the solr analyzer framework?
>
> I want to make it a mandatory dependency. I made a mistake in putting it optional in the first place.

+1 IMHO it wasn't a mistake at the time, but as lucene+solr are
converging more and more it looks like the way to go

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