Mailing List Archive

1 2  View All
Re: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
I don't think it's a showstopper. This applies to any 9x branch -
perhaps starting from main. We can extract these instructions into a
separate document. On the other hand, it wouldn't be shown up there on
github front-page then... and times have changed - this is where most
folks would probably end up reading the instructions, not the source
bundle?

D.

On Mon, Nov 29, 2021 at 1:01 PM Gus Heck <gus.heck@gmail.com> wrote:
>
> Seems to me the details for how to turn a src tarball into something that can be compiled should go in a BUILDING.txt file?
>
> On Mon, Nov 29, 2021 at 3:00 AM Dawid Weiss <dawid.weiss@gmail.com> wrote:
>>
>> SUCCESS! [0:17:23.949074]
>>
>> +1.
>>
>> D.
>>
>> On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand <jpountz@gmail.com> wrote:
>> >
>> > Please vote for release candidate 3 for Lucene 9.0.0.
>> >
>> > The artifacts can be downloaded from:
>> > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-1ddce848cf3d5067efcafc6569d5f8203e56af0b
>> >
>> > You can run the smoke tester directly with this command:
>> >
>> > python3 -u dev-tools/scripts/smokeTestRelease.py \
>> > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-1ddce848cf3d5067efcafc6569d5f8203e56af0b
>> >
>> > The vote will be open until 2021-11-30 9:00 UTC.
>> >
>> > [ ] +1 approve
>> > [ ] +0 no opinion
>> > [ ] -1 disapprove (and reason why)
>> >
>> > Here is my +1.
>> >
>> > --
>> > Adrien
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
Hi,

The same applies for the historical time. It was never possible to do a full release with only the source tarball.

The only thing that does not work is: assembleSourceRelease, because it requires "git archive" to build the src.tgz. But why should anybody do this? You have a src.tgz already why create another one from itsself?

You can create a binary release without problems (at least that worked yesterday), it will just not have a git hash in the metadata of JAR files (and so on). But the version number is always "SNAPSHOT" unless you define your own (we do this to prevent "unauthorized artifacts created accidentally). If somebody wants to release a custom Lucene with patches, one can pass -Dversion.suffix="Ubuntu20.04-foobar" to make a customized release.

Uwe

-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: uwe@thetaphi.de

> -----Original Message-----
> From: Dawid Weiss <dawid.weiss@gmail.com>
> Sent: Monday, November 29, 2021 1:33 PM
> To: Lucene Dev <dev@lucene.apache.org>
> Subject: Re: [VOTE] Release Lucene 9.0.0 RC3
>
> I don't think it's a showstopper. This applies to any 9x branch -
> perhaps starting from main. We can extract these instructions into a
> separate document. On the other hand, it wouldn't be shown up there on
> github front-page then... and times have changed - this is where most
> folks would probably end up reading the instructions, not the source
> bundle?
>
> D.
>
> On Mon, Nov 29, 2021 at 1:01 PM Gus Heck <gus.heck@gmail.com> wrote:
> >
> > Seems to me the details for how to turn a src tarball into something that can
> be compiled should go in a BUILDING.txt file?
> >
> > On Mon, Nov 29, 2021 at 3:00 AM Dawid Weiss <dawid.weiss@gmail.com>
> wrote:
> >>
> >> SUCCESS! [0:17:23.949074]
> >>
> >> +1.
> >>
> >> D.
> >>
> >> On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand <jpountz@gmail.com> wrote:
> >> >
> >> > Please vote for release candidate 3 for Lucene 9.0.0.
> >> >
> >> > The artifacts can be downloaded from:
> >> > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-
> 1ddce848cf3d5067efcafc6569d5f8203e56af0b
> >> >
> >> > You can run the smoke tester directly with this command:
> >> >
> >> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> >> > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-
> 1ddce848cf3d5067efcafc6569d5f8203e56af0b
> >> >
> >> > The vote will be open until 2021-11-30 9:00 UTC.
> >> >
> >> > [ ] +1 approve
> >> > [ ] +0 no opinion
> >> > [ ] -1 disapprove (and reason why)
> >> >
> >> > Here is my +1.
> >> >
> >> > --
> >> > Adrien
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
Not suggesting it's a show stopper, just that this would be an easily found
and consumed way to document the information revealed in this discussion.

On Mon, Nov 29, 2021 at 8:13 AM Uwe Schindler <uwe@thetaphi.de> wrote:

> Hi,
>
> The same applies for the historical time. It was never possible to do a
> full release with only the source tarball.
>
> The only thing that does not work is: assembleSourceRelease, because it
> requires "git archive" to build the src.tgz. But why should anybody do
> this? You have a src.tgz already why create another one from itsself?
>
> You can create a binary release without problems (at least that worked
> yesterday), it will just not have a git hash in the metadata of JAR files
> (and so on). But the version number is always "SNAPSHOT" unless you define
> your own (we do this to prevent "unauthorized artifacts created
> accidentally). If somebody wants to release a custom Lucene with patches,
> one can pass -Dversion.suffix="Ubuntu20.04-foobar" to make a customized
> release.
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Dawid Weiss <dawid.weiss@gmail.com>
> > Sent: Monday, November 29, 2021 1:33 PM
> > To: Lucene Dev <dev@lucene.apache.org>
> > Subject: Re: [VOTE] Release Lucene 9.0.0 RC3
> >
> > I don't think it's a showstopper. This applies to any 9x branch -
> > perhaps starting from main. We can extract these instructions into a
> > separate document. On the other hand, it wouldn't be shown up there on
> > github front-page then... and times have changed - this is where most
> > folks would probably end up reading the instructions, not the source
> > bundle?
> >
> > D.
> >
> > On Mon, Nov 29, 2021 at 1:01 PM Gus Heck <gus.heck@gmail.com> wrote:
> > >
> > > Seems to me the details for how to turn a src tarball into something
> that can
> > be compiled should go in a BUILDING.txt file?
> > >
> > > On Mon, Nov 29, 2021 at 3:00 AM Dawid Weiss <dawid.weiss@gmail.com>
> > wrote:
> > >>
> > >> SUCCESS! [0:17:23.949074]
> > >>
> > >> +1.
> > >>
> > >> D.
> > >>
> > >> On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand <jpountz@gmail.com>
> wrote:
> > >> >
> > >> > Please vote for release candidate 3 for Lucene 9.0.0.
> > >> >
> > >> > The artifacts can be downloaded from:
> > >> > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-
> > 1ddce848cf3d5067efcafc6569d5f8203e56af0b
> > >> >
> > >> > You can run the smoke tester directly with this command:
> > >> >
> > >> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > >> > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-
> > 1ddce848cf3d5067efcafc6569d5f8203e56af0b
> > >> >
> > >> > The vote will be open until 2021-11-30 9:00 UTC.
> > >> >
> > >> > [ ] +1 approve
> > >> > [ ] +0 no opinion
> > >> > [ ] -1 disapprove (and reason why)
> > >> >
> > >> > Here is my +1.
> > >> >
> > >> > --
> > >> > Adrien
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> > For additional commands, e-mail: dev-help@lucene.apache.org
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>
> > >
> > >
> > > --
> > > http://www.needhamsoftware.com (work)
> > > http://www.the111shift.com (play)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
The basic build steps are included in the readme, Gus -
https://github.com/apache/lucene/#building-with-gradle

Is your comment about moving it to a separate file or about the
instructions to build the package in general? If it's the latter then
I think it's fine?

Dawid

On Mon, Nov 29, 2021 at 2:16 PM Gus Heck <gus.heck@gmail.com> wrote:
>
> Not suggesting it's a show stopper, just that this would be an easily found and consumed way to document the information revealed in this discussion.
>
> On Mon, Nov 29, 2021 at 8:13 AM Uwe Schindler <uwe@thetaphi.de> wrote:
>>
>> Hi,
>>
>> The same applies for the historical time. It was never possible to do a full release with only the source tarball.
>>
>> The only thing that does not work is: assembleSourceRelease, because it requires "git archive" to build the src.tgz. But why should anybody do this? You have a src.tgz already why create another one from itsself?
>>
>> You can create a binary release without problems (at least that worked yesterday), it will just not have a git hash in the metadata of JAR files (and so on). But the version number is always "SNAPSHOT" unless you define your own (we do this to prevent "unauthorized artifacts created accidentally). If somebody wants to release a custom Lucene with patches, one can pass -Dversion.suffix="Ubuntu20.04-foobar" to make a customized release.
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>> > -----Original Message-----
>> > From: Dawid Weiss <dawid.weiss@gmail.com>
>> > Sent: Monday, November 29, 2021 1:33 PM
>> > To: Lucene Dev <dev@lucene.apache.org>
>> > Subject: Re: [VOTE] Release Lucene 9.0.0 RC3
>> >
>> > I don't think it's a showstopper. This applies to any 9x branch -
>> > perhaps starting from main. We can extract these instructions into a
>> > separate document. On the other hand, it wouldn't be shown up there on
>> > github front-page then... and times have changed - this is where most
>> > folks would probably end up reading the instructions, not the source
>> > bundle?
>> >
>> > D.
>> >
>> > On Mon, Nov 29, 2021 at 1:01 PM Gus Heck <gus.heck@gmail.com> wrote:
>> > >
>> > > Seems to me the details for how to turn a src tarball into something that can
>> > be compiled should go in a BUILDING.txt file?
>> > >
>> > > On Mon, Nov 29, 2021 at 3:00 AM Dawid Weiss <dawid.weiss@gmail.com>
>> > wrote:
>> > >>
>> > >> SUCCESS! [0:17:23.949074]
>> > >>
>> > >> +1.
>> > >>
>> > >> D.
>> > >>
>> > >> On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand <jpountz@gmail.com> wrote:
>> > >> >
>> > >> > Please vote for release candidate 3 for Lucene 9.0.0.
>> > >> >
>> > >> > The artifacts can be downloaded from:
>> > >> > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-
>> > 1ddce848cf3d5067efcafc6569d5f8203e56af0b
>> > >> >
>> > >> > You can run the smoke tester directly with this command:
>> > >> >
>> > >> > python3 -u dev-tools/scripts/smokeTestRelease.py \
>> > >> > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-
>> > 1ddce848cf3d5067efcafc6569d5f8203e56af0b
>> > >> >
>> > >> > The vote will be open until 2021-11-30 9:00 UTC.
>> > >> >
>> > >> > [ ] +1 approve
>> > >> > [ ] +0 no opinion
>> > >> > [ ] -1 disapprove (and reason why)
>> > >> >
>> > >> > Here is my +1.
>> > >> >
>> > >> > --
>> > >> > Adrien
>> > >> >
>> > >> > ---------------------------------------------------------------------
>> > >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > >> > For additional commands, e-mail: dev-help@lucene.apache.org
>> > >> >
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > >> For additional commands, e-mail: dev-help@lucene.apache.org
>> > >>
>> > >
>> > >
>> > > --
>> > > http://www.needhamsoftware.com (work)
>> > > http://www.the111shift.com (play)
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
Re-reading I think I misunderstood. I thought somewhere it was said that
git repo was needed to build which I would consider important, but I guess
that was just re-building the src tarball itself that required it.

If the existing src tarball is sufficient to produce a working server based
solely on instructions in the README.md I have no further concerns.

On Mon, Nov 29, 2021 at 11:03 AM Dawid Weiss <dawid.weiss@gmail.com> wrote:

> The basic build steps are included in the readme, Gus -
> https://github.com/apache/lucene/#building-with-gradle
>
> Is your comment about moving it to a separate file or about the
> instructions to build the package in general? If it's the latter then
> I think it's fine?
>
> Dawid
>
> On Mon, Nov 29, 2021 at 2:16 PM Gus Heck <gus.heck@gmail.com> wrote:
> >
> > Not suggesting it's a show stopper, just that this would be an easily
> found and consumed way to document the information revealed in this
> discussion.
> >
> > On Mon, Nov 29, 2021 at 8:13 AM Uwe Schindler <uwe@thetaphi.de> wrote:
> >>
> >> Hi,
> >>
> >> The same applies for the historical time. It was never possible to do a
> full release with only the source tarball.
> >>
> >> The only thing that does not work is: assembleSourceRelease, because it
> requires "git archive" to build the src.tgz. But why should anybody do
> this? You have a src.tgz already why create another one from itsself?
> >>
> >> You can create a binary release without problems (at least that worked
> yesterday), it will just not have a git hash in the metadata of JAR files
> (and so on). But the version number is always "SNAPSHOT" unless you define
> your own (we do this to prevent "unauthorized artifacts created
> accidentally). If somebody wants to release a custom Lucene with patches,
> one can pass -Dversion.suffix="Ubuntu20.04-foobar" to make a customized
> release.
> >>
> >> Uwe
> >>
> >> -----
> >> Uwe Schindler
> >> Achterdiek 19, D-28357 Bremen
> >> https://www.thetaphi.de
> >> eMail: uwe@thetaphi.de
> >>
> >> > -----Original Message-----
> >> > From: Dawid Weiss <dawid.weiss@gmail.com>
> >> > Sent: Monday, November 29, 2021 1:33 PM
> >> > To: Lucene Dev <dev@lucene.apache.org>
> >> > Subject: Re: [VOTE] Release Lucene 9.0.0 RC3
> >> >
> >> > I don't think it's a showstopper. This applies to any 9x branch -
> >> > perhaps starting from main. We can extract these instructions into a
> >> > separate document. On the other hand, it wouldn't be shown up there on
> >> > github front-page then... and times have changed - this is where most
> >> > folks would probably end up reading the instructions, not the source
> >> > bundle?
> >> >
> >> > D.
> >> >
> >> > On Mon, Nov 29, 2021 at 1:01 PM Gus Heck <gus.heck@gmail.com> wrote:
> >> > >
> >> > > Seems to me the details for how to turn a src tarball into
> something that can
> >> > be compiled should go in a BUILDING.txt file?
> >> > >
> >> > > On Mon, Nov 29, 2021 at 3:00 AM Dawid Weiss <dawid.weiss@gmail.com>
> >> > wrote:
> >> > >>
> >> > >> SUCCESS! [0:17:23.949074]
> >> > >>
> >> > >> +1.
> >> > >>
> >> > >> D.
> >> > >>
> >> > >> On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand <jpountz@gmail.com>
> wrote:
> >> > >> >
> >> > >> > Please vote for release candidate 3 for Lucene 9.0.0.
> >> > >> >
> >> > >> > The artifacts can be downloaded from:
> >> > >> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-
> >> > 1ddce848cf3d5067efcafc6569d5f8203e56af0b
> >> > >> >
> >> > >> > You can run the smoke tester directly with this command:
> >> > >> >
> >> > >> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> >> > >> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-
> >> > 1ddce848cf3d5067efcafc6569d5f8203e56af0b
> >> > >> >
> >> > >> > The vote will be open until 2021-11-30 9:00 UTC.
> >> > >> >
> >> > >> > [ ] +1 approve
> >> > >> > [ ] +0 no opinion
> >> > >> > [ ] -1 disapprove (and reason why)
> >> > >> >
> >> > >> > Here is my +1.
> >> > >> >
> >> > >> > --
> >> > >> > Adrien
> >> > >> >
> >> > >> >
> ---------------------------------------------------------------------
> >> > >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >> > >> >
> >> > >>
> >> > >>
> ---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> >> > >>
> >> > >
> >> > >
> >> > > --
> >> > > http://www.needhamsoftware.com (work)
> >> > > http://www.the111shift.com (play)
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
RE: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
Hi,

there's one thing which was done without a public announcement (at least not public like "here on mailing list". In one of the commits regarding to Luke, there was made the decision to assign a Java 9 Jigsaw module name to all JAR files. I did not notice this because it was somehow hidden.

There were already lengthy discussions on Maven and OpenJDK mailing list on "how to name a module". If you define a module name though "automatic-module-name" in the JAR manifest or by an explicit module-info.java (see https://issues.apache.org/jira/browse/LUCENE-10255, which is draft) the module name must be well thought. Christian Stein (Member of the OpenJDK group and also Junit committer, also well involved in development of Apache Maven) wrote some blog post about how a module name should look like, so any code downstream can import it into their own modules. The names must be valid Java identifiers: https://sormuras.github.io/blog/2019-08-04-maven-coordinates-and-java-module-names.html

It concludes this very well:
- The Java module name should have the Maven Group ID as prefix, followed by "." and then a local module descriptor. E.g., "org.apache.lucene.core"
- The prefix of exported package names inside each module *should* be prefixed by the module name (we can't do this foe Lucene, but we should at least share the same prefix: "org.apache.lucene").
- The version name inside the module should follow module system syntax (so at least "9.0.0", no prefix/suffix => parseable by ModuleDescriptor.Version)

Unfortunately I only noticed this too late (because of Luke Dawid and Tomoko added automatic module names), so I would like to revoke my +1 vote for the release. I'd really like to make a decision with the whole committers about the official module names as written to JAR files, because they affect how Java 11 users will have to import the Lucene modules in their builds (if they use the Java Module System). The Module names should either be a metadata property for each Gradle module (like the Maven coordinate in each build.gradle) or we should add module-info.java now (which is impossible, will come later). At least it should NOT be some regex replace on the Gradle project path.

Current module name of lucene-core.jar is "lucene.core", which does not conform to any standard like we do for package names. Don't come with "In the JDK you java modules named "java.base": This is a different story. You also have a package name "java.lang". Same for modules named "jdk." (with package names "jdk.") This is because that's the root of Java and the "java" and "jdk" names are reserved in the spec. But any third party module should be following the above rules and use reverse domain names (like suggested in older versions of the Java Language Spec, nowadays it just says "globally unique"). "lucene" is not globally unique. And our packages in the source code are also named "org.apache.lucene".

Here is a statistic of module names used on Maven by different artifacts: https://github.com/sormuras/modules/blob/main/doc/Top1000-2020.txt.md

For my arguments see the discussion here (comments following this one): <https://issues.apache.org/jira/browse/LUCENE-10255?focusedCommentId=17450327&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17450327>

In short:
-1 to release before we have valid and explicitely declared module names (or remove the Automatic Module Manifest at all until we have a decission)

My proposal is to do the following before release:

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. Use fully qualified names according the Apache wide rule for Maven artifacts and Java packages. The current gradle code would cause a backwards break for Java module system users (e.g., Elasticsearch as far as I have figured out from following their discussions about converting to module system): If you remove the "lucene/" directory from the gradle build, the module name changes. This is not acceptable!

Later for 9.x replace the automatic module name by a real module-info.java (see above PR).

Sorry,
Uwe

-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: uwe@thetaphi.de

> -----Original Message-----
> From: Adrien Grand <jpountz@gmail.com>
> Sent: Friday, November 26, 2021 3:31 PM
> To: Lucene Dev <dev@lucene.apache.org>
> Subject: [VOTE] Release Lucene 9.0.0 RC3
>
> Please vote for release candidate 3 for Lucene 9.0.0.
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-
> 1ddce848cf3d5067efcafc6569d5f8203e56af0b
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-
> 1ddce848cf3d5067efcafc6569d5f8203e56af0b
>
> The vote will be open until 2021-11-30 9:00 UTC.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here is my +1.
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
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 <dawid.weiss@gmail.com> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
> > 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.

At some point we have to hardcode them into the module-info.java.

But OK, it is fine, if we do it like that:
https://github.com/apache/lucene/blob/main/gradle/maven/publications-maven.gradle#L59-L60

I don't think we need the "archivesBaseName", because this repeats "lucene" prefix, but the project name and project group should be appended with "." and al dashes replaced by "_".

Uwe


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
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: uwe@thetaphi.de

> -----Original Message-----
> From: Dawid Weiss <dawid.weiss@gmail.com>
> Sent: Monday, November 29, 2021 7:36 PM
> To: Lucene Dev <dev@lucene.apache.org>
> 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 <dawid.weiss@gmail.com>
> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
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 <uwe@thetaphi.de> 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: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Dawid Weiss <dawid.weiss@gmail.com>
> > Sent: Monday, November 29, 2021 7:36 PM
> > To: Lucene Dev <dev@lucene.apache.org>
> > 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 <dawid.weiss@gmail.com>
> > 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: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
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 <jpountz@gmail.com> 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 <uwe@thetaphi.de> 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: uwe@thetaphi.de
>>
>> > -----Original Message-----
>> > From: Dawid Weiss <dawid.weiss@gmail.com>
>> > Sent: Monday, November 29, 2021 7:36 PM
>> > To: Lucene Dev <dev@lucene.apache.org>
>> > 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 <dawid.weiss@gmail.com>
>> > 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: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
I'm good with getting safe bug fixes in as we respin, +1 to backport this
fix to 9.0.

On Tue, Nov 30, 2021 at 10:25 PM Greg Miller <gsmiller@gmail.com> wrote:

> 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 <jpountz@gmail.com> 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 <uwe@thetaphi.de> 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: uwe@thetaphi.de
> >>
> >> > -----Original Message-----
> >> > From: Dawid Weiss <dawid.weiss@gmail.com>
> >> > Sent: Monday, November 29, 2021 7:36 PM
> >> > To: Lucene Dev <dev@lucene.apache.org>
> >> > 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 <dawid.weiss@gmail.com>
> >> > 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: dev-unsubscribe@lucene.apache.org
> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

--
Adrien
Re: [VOTE] Release Lucene 9.0.0 RC3 [ In reply to ]
OK, thanks Adrien. I went ahead and backported to 9.0.

Cheers,
-Greg

On Tue, Nov 30, 2021 at 1:33 PM Adrien Grand <jpountz@gmail.com> wrote:
>
> I'm good with getting safe bug fixes in as we respin, +1 to backport this fix to 9.0.
>
> On Tue, Nov 30, 2021 at 10:25 PM Greg Miller <gsmiller@gmail.com> wrote:
>>
>> 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 <jpountz@gmail.com> 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 <uwe@thetaphi.de> 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: uwe@thetaphi.de
>> >>
>> >> > -----Original Message-----
>> >> > From: Dawid Weiss <dawid.weiss@gmail.com>
>> >> > Sent: Monday, November 29, 2021 7:36 PM
>> >> > To: Lucene Dev <dev@lucene.apache.org>
>> >> > 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 <dawid.weiss@gmail.com>
>> >> > 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: dev-unsubscribe@lucene.apache.org
>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> --
> Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

1 2  View All