On 17 February 2017 at 11:04, Gunnar Morling <gun...@hibernate.org> wrote: > 2017-02-17 11:30 GMT+01:00 Sanne Grinovero <sa...@hibernate.org>: >> On 17 February 2017 at 10:16, Gunnar Morling <gun...@hibernate.org> wrote: >>> 2017-02-17 11:04 GMT+01:00 Sanne Grinovero <sa...@hibernate.org>: >>>> On 17 February 2017 at 09:42, Gunnar Morling <gun...@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 <sa...@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@lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
