If we're going to respin, I'd like to propose we pick up the bug fix in https://issues.apache.org/jira/browse/LUCENE-10232. I certainly wouldn't respin just to get this fix, but if we're going to anyway, it would be nice to grab it.
Here's a PR to do so if the group thinks it makes sense: https://github.com/apache/lucene/pull/495 Cheers, -Greg On Mon, Nov 29, 2021 at 2:02 PM Adrien Grand <[email protected]> wrote: > > You could send a heads up to dev@ to make this more visible but I don't think > we need a vote. > > Thanks Uwe and Dawid for taking care of this. > > Le lun. 29 nov. 2021 à 22:25, Uwe Schindler <[email protected]> a écrit : >> >> Hi, >> >> Dawid and I changed the gradle build to change the module names to be >> according to above. With the new gradle task the automatically assigned >> module names from the gradle projects are now: >> >> > Task :showModuleNames >> lucene-benchmark-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.benchmark >> lucene-backward-codecs-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.backward_codecs >> lucene-classification-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.classification >> lucene-codecs-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.codecs >> lucene-core-10.0.0-SNAPSHOT.jar -> org.apache.lucene.core >> lucene-demo-10.0.0-SNAPSHOT.jar -> org.apache.lucene.demo >> lucene-expressions-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.expressions >> lucene-facet-10.0.0-SNAPSHOT.jar -> org.apache.lucene.facet >> lucene-grouping-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.grouping >> lucene-highlighter-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.highlighter >> lucene-join-10.0.0-SNAPSHOT.jar -> org.apache.lucene.join >> lucene-luke-10.0.0-SNAPSHOT.jar -> org.apache.lucene.luke >> lucene-memory-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.memory >> lucene-misc-10.0.0-SNAPSHOT.jar -> org.apache.lucene.misc >> lucene-monitor-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.monitor >> lucene-queries-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.queries >> lucene-queryparser-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.queryparser >> lucene-replicator-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.replicator >> lucene-sandbox-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.sandbox >> lucene-spatial-extras-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.spatial_extras >> lucene-spatial3d-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.spatial3d >> lucene-suggest-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.suggest >> lucene-test-framework-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.test_framework >> lucene-analysis-common-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.analysis.common >> lucene-analysis-icu-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.analysis.icu >> lucene-analysis-kuromoji-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.analysis.kuromoji >> lucene-analysis-morfologik-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.analysis.morfologik >> lucene-analysis-nori-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.analysis.nori >> lucene-analysis-opennlp-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.analysis.opennlp >> lucene-analysis-phonetic-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.analysis.phonetic >> lucene-analysis-smartcn-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.analysis.smartcn >> lucene-analysis-stempel-10.0.0-SNAPSHOT.jar -> >> org.apache.lucene.analysis.stempel >> >> The module names on the right can now be used in Java source code to refer >> in Java 11 to the module. Those are now "automatic module names" (because >> the lucene behind is not completely modularized). In later Lucene 9.x >> versions we will add full module support and only expose APIs for external >> consumption and hide all internal lucene packages. >> >> The 9.0 relese should make sure that the module names are at least >> "defined", so we can use them later in module-info.java, >> >> Should I send a vote thread about this to the mailing list separately? >> >> Uwe >> >> ----- >> Uwe Schindler >> Achterdiek 19, D-28357 Bremen >> https://www.thetaphi.de >> eMail: [email protected] >> >> > -----Original Message----- >> > From: Dawid Weiss <[email protected]> >> > Sent: Monday, November 29, 2021 7:36 PM >> > To: Lucene Dev <[email protected]> >> > Subject: Re: [VOTE] Release Lucene 9.0.0 RC3 >> > >> > Here is the change adding the 'org.apache.*' prefix, Uwe: >> > https://github.com/apache/lucene/pull/487 >> > >> > I verified that Luke starts in the rebuilt distribution and that >> > module names show org.apache.* prefixes. Dashes are not allowed in >> > modules so Lucene artifacts using them (spatial-extras, >> > test-framework, backward-codecs) use an underscore in place of the >> > dash. >> > >> > Dawid >> > >> > On Mon, Nov 29, 2021 at 7:23 PM Dawid Weiss <[email protected]> >> > wrote: >> > > >> > > Dear Uwe, >> > > >> > > > I did not notice this because it was somehow hidden. >> > > >> > > It was not hidden, Uwe. It was right there in the issue that >> > > introduced it, along with a comment that it was a deliberate decision >> > > (mine). >> > > >> > > > In every build.gradle file define the module name explicit using an ext >> > property for the "Automatic Module Name" JAR manifest, don't use regex >> > replace on the filesystem path of the gradle build. >> > > >> > > I disagree with you - convention over configuration. If you derive the >> > > module name from the project path, it's simpler and easier to use. And >> > > nothing will break -- if you change the layout of folders, you'd break >> > > compilation and you'd have to alter the naming convention in that >> > > (one!) place as well. The simpler it is, the better. I would even >> > > insist on renaming module folders to what the package structure >> > > already uses (underscore instead of the dash) so that it's consistent >> > > everywhere. >> > > >> > > > If you remove the "lucene/" directory from the gradle build, the module >> > name changes. This is not acceptable! >> > > >> > > If you do that, everything will break and you'd have to change a lot >> > > more than just module names... >> > > >> > > I'll provide a patch adding org.apache. prefix but I don't agree on >> > > scattering module names in each and every module - this is irrelevant >> > > and unnecessary duplication of what can be done in a simple way (and >> > > we already do it for JAR names, Maven artifacts, etc...). >> > > >> > > D. >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
