I think it is fine to have it in hibernate "branding"
you could go for something like org.hibernate.wildfly:lucene-modules.
This doesn't really belong in org.wildfly:lucence-modules.
if anything it could be part of wildfly-extras and as such in
But given that hibernate is well established project, no reason not to have
it under its umbrella.
On Mon, Mar 6, 2017 at 4:40 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
I'm going to assume that there's no interest in giving these modules a
"WildFly branding" and/or home, so I'll use the proposed
org.hibernate.lucene-modules group id, and keep them on the Hibernate
Last chance to propose alternatives this week ;)
Thanks for any feedback!
On 17 February 2017 at 12:00, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> # Context
> historically the Hibernate Search project released modules for
> WildFly, so that people could use the latest version of it w/o having
> to wait for WildFly to upgrade it and release.
> This zip we distribute would also include updated modules for Apache
> We have now separated the Lucene modules into their own repository, so
> that other projects (e.g. Infinispan) can use the same modules.
> In case you want to have a look, the POC is hosted at:
> - https://github.com/hibernate/lucene-modules
> We planned to deploy this zip file as a Maven artifact under
> coordinates "org.hibernate.lucene-modules:lucene-modules:lucene-modules"
> # I have three questions:
> ## Would it be useful to make this a "Feature Pack" ?
> Ideally we would like future versions of WildFly to use the same
> structure (and same content) of these modules, when it will come to
> upgrade the Lucene version within WildFly.
> That's because we will have already tested these in (at least) the
> Hibernate and Infinispan projects, while replicating the same
> structure within the WildFly build would not guarantee the same
> output, and would not be covered by the same amount and quality of
> integration tests.
> ## Would you prefer this to be hosted as github.com/wildfly
> We'd be happy to transfer ownership and still maintain it: having this
> under "Hibernate" probably sends the wrong message.
> It contains no Hibernate code and we'd like to encourage other people
> possibly using Lucene on WildFly to use the same modules, again for
> consistency reasons.
> ## Should we use a WildFly flavoured organization id?
> For the same reasons as in the previous question, yet I ask this
> separately as I guess we could still keep it on github/hibernate if
> you prefer, yet distribute it as "org.wildfly:lucene-modules" or
> something else you might want to suggest.
wildfly-dev mailing list