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

Fri Feb 17 06:10:39 EST 2017

On 17 February 2017 at 11:04, Gunnar Morling <gunnar at hibernate.org> wrote:
> 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.

They will not consume it. Remember the prime directive?

 - http://lists.jboss.org/pipermail/wildfly-dev/2017-January/005686.html

I'm assuming the previous direction stands, and I'd like to move
forward until we know better.

This initiative has been stuck for more than a year already, waiting
for such input or a better home.

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