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 <sa...@hibernate.org> wrote: > 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
