[hibernate-dev] [HSEARCH] Hibernate search core module proposal

[Sanne Grinovero]

2011/6/1 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> On 23 mai 2011, at 17:00, Sanne Grinovero wrote:
>
>>> Hi Davide,
>>>
>>>
>>>> today I've downloaded the hibernate-search sources and my eclipse has
>>>> a problem importing the maven projects because the parent folder has
>>>> the same name as one of the sub-folders:
>>>
>>> what was the problem? I personally never had any problems importing the
>>> Hibernate Search
>>> project. Admittedly I am using Idea, but I know Sanne is using Eclipse and
>>> he never mentioned
>>> any problems.
>>>
>>>> I was a bit surprised because others Hibernate and JBoss projects I
>>>> saw so far seem to use the "-core" suffix for the main module.
>>>> Shouldn't hibernate-search follow the same convention?
>>>
>>> So you suggest hibernate-search-core as module and artifact name? I guess
>>> that's a fair
>>> request. I think the reason for the main module being called
>>> "hibernate-search" is that
>>> for a long time we only had one single relevant module (the testing ones
>>> don't count imo).
>>> With hibernate-search-analyzers and especially hibernate-search-infinispan
>>> around it might
>>> be at the time to change the module name.
>>>
>>> The only drawback is that people are by now used for the main artifact
>>> being called hibernate-search.
>>> Switching to hibernate-search-core will create even more confusion in the
>>> maven repositories.
>>>
>>> Not sure what the others think. The importing of the current project
>>> though should not be
>>> affected either way.
>>
>> yes importing the project in eclipse has this slight flaw currently. I
>> never bothered that much, as it seems more an eclipse flaw and I don't
>> import it again every day.
>> But indeed Davide makes a point in that it seems common across many
>> JBoss projects to have a "project-name-core" named main module.
>> Infinispan names it just "core".
>>
>> It would be fine for me to rename it, assuming it doesn't create a
>> mess when backporting patches?
>
> Well we know back porting will be an issue but I expect the amount of backporting to be somewhat minimal between Hibernate Search 3.x and 4.
> I think we can consider a Hibernate Search Core module if we end up moving the Hibernate Search code dedicated to Hibvernate Core into a separate module. What do you guys think?
>
> We could decide to keep hibernate-search as an artifact that is a simple aggregator to hibernate-search-core and hibernate-search-hibernate-core (SIC) (or should it be hibernate-search-orm?)

I dislike "orm" as it's too generic, we don't want to imply to support any orm.

We already mention hibernate in the group id properly identifying the
team working on it, so if the kernel of H.Search doesn't need H.Core
as it will drop the hibernate-core depencency, we could call the core
module "search", and keep "hibernate-search" as the integration module
providing the current eventlistener functionality. Everyone using
"Hibernate Search" will still depend on the "hibernate-search"
artifact anyway so we're not loosing any branding.

As an example: Infinispan Query would not depend on "hibernate-search"
but on "org.hibernate.search:search", being this only the search
engine, produced by the Hibernate Search project.

So, proposal:
  groupId:
     org.hibernate.search

  assembly artifactId:
     search-assembly
  kernel artifactId:
     search
  parent:
     search-parent
  hibernate integration:
     hibernate-search
  infinispan integration
     infinispan-search (is currently hibernate-search-infinispan)

> Lastly, we could consider moving to org.hibernate.search as a groupId for 4.

+1

Cheers,
Sanne