HEADS UP: Java 9 Module System (JMS) module names for Lucene artifacts

2021-11-29 Thread Uwe Schindler
Hi,

I stopped the Lucene 9.0 release because of some inconsistencies with Java
Module System (JMS) module names. We will respin, but in preparation to full
module system support (in later Lucene 9.x versions), I changed the so
called "automatic module name" of all JAR artifacts so they are consistent
with naming conventions by the ASF and suggested by module developers at
OpenJDK and Maven people.

Long story:

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 and should be formatted
like package names:
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 for 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)

Here is a statistic of module names used on Maven by different artifacts,
have a look at examples like Log4J, Apache TIKA and others:
https://github.com/sormuras/modules/blob/main/doc/Top1000-2020.txt.md

For my detailed arguments see the discussion here (comments following this
one):


My proposal is to do the following before release, now implemented in
https://github.com/apache/lucene/pull/487:

> 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

These names can be used in your own 

Re: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Adrien Grand
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  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: u...@thetaphi.de
>
> > -Original Message-
> > From: Dawid Weiss 
> > Sent: Monday, November 29, 2021 7:36 PM
> > To: Lucene Dev 
> > 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 
> > 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 

RE: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Uwe Schindler
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: u...@thetaphi.de

> -Original Message-
> From: Dawid Weiss 
> Sent: Monday, November 29, 2021 7:36 PM
> To: Lucene Dev 
> 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 
> 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 

Re: Closing GitHub PRs

2021-11-29 Thread Mike Drob
I understand the frustrations around closing somebody’s PR as stale, but I
also think that there is value in informing the contributors I this is
never getting solved/fixed/looked at, if this is still important please go
over there instead.

On Mon, Nov 29, 2021 at 1:55 PM Robert Muir  wrote:

> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>  wrote:
> >
> > Could we maybe instead bulk-add a comment explaining the split and how
> to take the PR forwards if someone (in the future) has itch/time?
> >
> > I know we humans love to clean things up, but I think leaving such
> "unclean" things open serves an important purpose.  They all had importance
> to at least one person at one point in time, and likely many of them are
> still relevant if they piqued someones curiosity to dig back into them.
> Closing them makes them harder to find for the future developer.
> >
> > I'm sure some of them are already resolved/duplicates too.  If only we
> could divine which are which.
> >
> >
>
> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> I see it in other trackers. Is there a rush to close these for some
> reason?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


Re: Closing GitHub PRs

2021-11-29 Thread Robert Muir
On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
 wrote:
>
> Could we maybe instead bulk-add a comment explaining the split and how to 
> take the PR forwards if someone (in the future) has itch/time?
>
> I know we humans love to clean things up, but I think leaving such "unclean" 
> things open serves an important purpose.  They all had importance to at least 
> one person at one point in time, and likely many of them are still relevant 
> if they piqued someones curiosity to dig back into them.  Closing them makes 
> them harder to find for the future developer.
>
> I'm sure some of them are already resolved/duplicates too.  If only we could 
> divine which are which.
>
>

+1, I'd rather not auto-close PRs. I'm always frustrated by this when
I see it in other trackers. Is there a rush to close these for some
reason?

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



Re: Closing GitHub PRs

2021-11-29 Thread Michael McCandless
Could we maybe instead bulk-add a comment explaining the split and how to
take the PR forwards if someone (in the future) has itch/time?

I know we humans love to clean things up, but I think leaving such
"unclean" things open serves an important purpose.  They all had importance
to at least one person at one point in time, and likely many of them are
still relevant if they piqued someones curiosity to dig back into them.
Closing them makes them harder to find for the future developer.

I'm sure some of them are already resolved/duplicates too.  If only we
could divine which are which.

Mike McCandless

http://blog.mikemccandless.com


On Mon, Nov 29, 2021 at 2:45 PM Mike Drob  wrote:

> We currently have almost 300 open PRs against the "master" branch in the
> old lucene-solr repo.
>
>
> https://github.com/apache/lucene-solr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster
>
> I think we should close all of them (possibly with a comment pointing
> people to the main branch in the lucene or solr repos).
>
> I do not know if there is an automated way to do this, or a way to do this
> without spamming everybody's email lists. If there is consensus on this
> clean up work then I'll take some time to investigate how to get this done
> and/or chat with ASF Infra about it.
>
> Thanks,
> Mike
>


Closing GitHub PRs

2021-11-29 Thread Mike Drob
We currently have almost 300 open PRs against the "master" branch in the
old lucene-solr repo.

https://github.com/apache/lucene-solr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster

I think we should close all of them (possibly with a comment pointing
people to the main branch in the lucene or solr repos).

I do not know if there is an automated way to do this, or a way to do this
without spamming everybody's email lists. If there is consensus on this
clean up work then I'll take some time to investigate how to get this done
and/or chat with ASF Infra about it.

Thanks,
Mike


RE: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Uwe Schindler
> > 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



Re: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Dawid Weiss
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  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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



Re: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Dawid Weiss
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



RE: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Uwe Schindler
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): 


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: u...@thetaphi.de

> -Original Message-
> From: Adrien Grand 
> Sent: Friday, November 26, 2021 3:31 PM
> To: Lucene Dev 
> 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 

[RESULT][VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Adrien Grand
This vote has failed, see https://issues.apache.org/jira/browse/LUCENE-10234
.

On Mon, Nov 29, 2021 at 5:43 PM Gus Heck  wrote:

> 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 
> 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  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  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: u...@thetaphi.de
>> >>
>> >> > -Original Message-
>> >> > From: Dawid Weiss 
>> >> > Sent: Monday, November 29, 2021 1:33 PM
>> >> > To: Lucene Dev 
>> >> > 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  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 > >
>> >> > wrote:
>> >> > >>
>> >> > >> SUCCESS! [0:17:23.949074]
>> >> > >>
>> >> > >> +1.
>> >> > >>
>> >> > >> D.
>> >> > >>
>> >> > >> On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand 
>> 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-unsubscr...@lucene.apache.org
>> >> > >> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >> > >> >
>> >> > >>
>> >> > >>
>> -
>> >> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> > >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >> > >>
>> >> > >
>> >> > >
>> >> > > --
>> >> > > http://www.needhamsoftware.com (work)
>> >> > > http://www.the111shift.com (play)
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>> >>
>> >> 

Re: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Gus Heck
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  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  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  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: u...@thetaphi.de
> >>
> >> > -Original Message-
> >> > From: Dawid Weiss 
> >> > Sent: Monday, November 29, 2021 1:33 PM
> >> > To: Lucene Dev 
> >> > 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  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 
> >> > wrote:
> >> > >>
> >> > >> SUCCESS! [0:17:23.949074]
> >> > >>
> >> > >> +1.
> >> > >>
> >> > >> D.
> >> > >>
> >> > >> On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand 
> 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-unsubscr...@lucene.apache.org
> >> > >> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >> > >> >
> >> > >>
> >> > >>
> -
> >> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> > >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >> > >>
> >> > >
> >> > >
> >> > > --
> >> > > http://www.needhamsoftware.com (work)
> >> > > http://www.the111shift.com (play)
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
>
> 

Re: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Dawid Weiss
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  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  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: u...@thetaphi.de
>>
>> > -Original Message-
>> > From: Dawid Weiss 
>> > Sent: Monday, November 29, 2021 1:33 PM
>> > To: Lucene Dev 
>> > 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  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 
>> > wrote:
>> > >>
>> > >> SUCCESS! [0:17:23.949074]
>> > >>
>> > >> +1.
>> > >>
>> > >> D.
>> > >>
>> > >> On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand  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-unsubscr...@lucene.apache.org
>> > >> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> > >> >
>> > >>
>> > >> -
>> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> > >>
>> > >
>> > >
>> > > --
>> > > http://www.needhamsoftware.com (work)
>> > > http://www.the111shift.com (play)
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

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



Re: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Gus Heck
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  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: u...@thetaphi.de
>
> > -Original Message-
> > From: Dawid Weiss 
> > Sent: Monday, November 29, 2021 1:33 PM
> > To: Lucene Dev 
> > 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  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 
> > wrote:
> > >>
> > >> SUCCESS! [0:17:23.949074]
> > >>
> > >> +1.
> > >>
> > >> D.
> > >>
> > >> On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand 
> 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-unsubscr...@lucene.apache.org
> > >> > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >> >
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > >> For additional commands, e-mail: dev-h...@lucene.apache.org
> > >>
> > >
> > >
> > > --
> > > http://www.needhamsoftware.com (work)
> > > http://www.the111shift.com (play)
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)


RE: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Uwe Schindler
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: u...@thetaphi.de

> -Original Message-
> From: Dawid Weiss 
> Sent: Monday, November 29, 2021 1:33 PM
> To: Lucene Dev 
> 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  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 
> wrote:
> >>
> >> SUCCESS! [0:17:23.949074]
> >>
> >> +1.
> >>
> >> D.
> >>
> >> On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand  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-unsubscr...@lucene.apache.org
> >> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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



Re: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Dawid Weiss
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  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  wrote:
>>
>> SUCCESS! [0:17:23.949074]
>>
>> +1.
>>
>> D.
>>
>> On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand  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-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

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



Re: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Gus Heck
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  wrote:

> SUCCESS! [0:17:23.949074]
>
> +1.
>
> D.
>
> On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand  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-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)


Re: [VOTE] Release Lucene 9.0.0 RC3

2021-11-29 Thread Dawid Weiss
SUCCESS! [0:17:23.949074]

+1.

D.

On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand  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-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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