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/a271d43d15b6af508ea693b3... Thanks, Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 17 February 2017 at 09:42, Gunnar Morling <gunnar(a)hibernate.org&gt; 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.

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.

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(a)hibernate.org&gt;: >> 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/a271d43d15b6af508ea693b3... >> >> Thanks, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 17 February 2017 at 10:16, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > 2017-02-17 11:04 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: >> On 17 February 2017 at 09:42, Gunnar Morling <gunnar(a)hibernate.org&gt; 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/4a823d1f2ec1244c6fb2f38a0632...

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(a)hibernate.org&gt;: >>>> 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/a271d43d15b6af508ea693b3... >>>> >>>> Thanks, >>>> Sanne >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 17 February 2017 at 11:04, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > 2017-02-17 11:30 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: >> On 17 February 2017 at 10:16, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: >>> 2017-02-17 11:04 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: >>>> On 17 February 2017 at 09:42, Gunnar Morling <gunnar(a)hibernate.org&gt; 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/4a823d1f2ec1244c6fb2f38a0632... > > 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(a)hibernate.org&gt;: >>>>>> 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/a271d43d15b6af508ea693b3... >>>>>> >>>>>> Thanks, >>>>>> Sanne >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev