[hibernate-dev] New project, new group-id: org.hibernate.lucene-modules

Gunnar Morling gunnar at hibernate.org
Fri Feb 17 06:04:44 EST 2017


2017-02-17 11:30 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> On 17 February 2017 at 10:16, Gunnar Morling <gunnar at hibernate.org> wrote:
>> 2017-02-17 11:04 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>> On 17 February 2017 at 09:42, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>> Hi,
>>>>
>>>> That's a great initiative.
>>>
>>> Thanks! Credit to Gustavo - he created the project idea - I actually
>>> failed to follow
>>> up for a long time.
>>>
>>> I wasn't fully convinced, especially as we were waiting for directions
>>> on the area,
>>> but convinced now that we should at least split it out even if we don't know
>>> the recommended modules format and WildFly strategies going forward.
>>>
>>>> Have you considered to make this a more
>>>> general effort, esp. should this rather be a repo / group id under the
>>>> WildFly reign instead of Hibernate?
>>>
>>> Yes, the "org.hibernate" organization prefix is a deliberate choice.
>>>
>>> The main reason is that we're the ones maintaining and - hopefully - releasing
>>> this module set.
>>> Proper organization namespacing is important within the Maven modules world.
>>
>> I don't see why we couldn't maintain it when using something under
>> "org.wildfly". Yes, it'll require a bit more work upfront to agree on
>> it. But ideally, WF could even pick up the modules from that project
>> for its own distribution, so it seems like a good fit.
>
> Let's assume we do that. You'd also want me to move this repository to
> github.com/wildfly ?

Yes, that'd be idea.

>
> I'm concerned we're making this maintenance much more "out of reach" for us,
> just to polish an identifier.

It's more than that, it'd also allow WF to consume these modules
instead of maintaining them twice.

>
> For example, the pom metadata I created suggests using this mailing
> list for any comment,
> and while I read the WildFly ML periodically, I don't read it as often:
>  - https://github.com/Sanne/lucene-modules/blob/4a823d1f2ec1244c6fb2f38a063253df75cb9187/pom.xml#L34-L54

Sorry, but I wouldn't base the decision on which mailing list to read.

>
> Mind you, it's not the goal of this project to be popular.
> It just has to work for our purposes: if having the wrong identifier
> will lose it some % of users I will still sleep at night just fine.
> Possibly being useful to other people is nice, but is secondary.

Ok, it sounded general purpose to me in the beginning. The usage by WF remains.

Would be interesting to hear what others think.

>
>>
>>>
>>> N.B. the modules id still is "org.apache.lucene": only the Maven group id
>>> is prefixed by the Hibernate id. My intent is really to "sign" the provenance
>>> only, while the package purpose is general.
>>>
>>>>
>>>> As you say, the modules may be interesting to people not using
>>>> Hibernate Search, so a group id not tied to Hibernate would be less
>>>> confusing: org. wildfly.modules.lucene.
>>>
>>> In an ideal world, I would contribute this to the Lucene project:
>>> what people need is such a moduleset for each single Lucene release,
>>> so you might as well have the Lucene release process provide one.
>>
>> I don't think it belongs into Lucene. At least I wouldn't like the
>> idea of maintaining support for downstream integrators like this, were
>> I a Lucene developer :)
>>
>>>
>>> But I think it's premature for that; not least because:
>>>  - I doubt this format is  yet popular enough to be a compelling
>>> feature for the Lucene team
>>>  - we need them to be "retro-active", i.e. to re-package existing
>>> Lucene versions
>>>  - should we use the patch format instead? A feature pack? A fraction? etc..
>>>
>>> Many such details need to be ironed out, then I'd be happy to propose
>>> it to the Lucene
>>> project for inclusion, but this might take some year yet and we need
>>> this right now.
>>>
>>> -- Sanne
>>>
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>>
>>>> 2017-02-16 20:17 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>>>> Hi all,
>>>>>
>>>>> I'm proposing the use of the `org.hibernate.lucene-modules` group id
>>>>> for the stuff which we'll be releasing from this repository:
>>>>>  - https://github.com/hibernate/lucene-modules
>>>>>
>>>>> Context: Hibernate Search has been packaging Apache Lucene as a
>>>>> WildFly module, essentially including the Lucene modules as part of
>>>>> the Hibernate Search modules.
>>>>>
>>>>> We want to separate these modules, for various reasons; the main
>>>>> driver being the build of Infinispan is much simpler if they can
>>>>> source the Lucene modules "out of band" from the Search release
>>>>> version. Sometimes we need some more flexibility, and it's getting
>>>>> close to mission impossible to workaround the tight coupling.
>>>>>
>>>>> This might also help other projects use Lucene when not necessarily
>>>>> interested in Hibernate Search, or in using the Lucene versions which
>>>>> Search would allow (a subset of the Lucene releases).
>>>>>
>>>>> Finally, since we release these modules with name "org.apache.lucene",
>>>>> it might just make sense for them to be independent and just contain
>>>>> Apache Lucene.
>>>>>
>>>>> If you're interested more details, have a look at PR number 1:
>>>>>  - https://github.com/hibernate/lucene-modules/pull/1/files
>>>>>
>>>>> In Hibernate Search this would imply:
>>>>>  - https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8
>>>>>
>>>>> Thanks,
>>>>> Sanne
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


More information about the hibernate-dev mailing list