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

Sanne Grinovero sanne at hibernate.org
Fri Feb 17 07:07:01 EST 2017


I've sent a related proposal to the WildFly mailing list:
 - http://lists.jboss.org/pipermail/wildfly-dev/2017-February/005768.html

If they welcome it, that's great.
Otherwise I'll release this pack as-is, but for sure ownership is not
cast in stone.

Thanks,
Sanne

On 17 February 2017 at 11:10, Sanne Grinovero <sanne at hibernate.org> wrote:
> 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


More information about the hibernate-dev mailing list