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

[Sanne Grinovero]

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 ?

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

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

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.

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