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