Mailing List Archive

Simplify the release artifacts
Hi.

These are the thoughts that occurred to me while rewriting the
packaging in the build system. I think they're worth the discussion
because they could limit the size of the published artifacts as well
as their perceptive quality.

1. Who is going to use the lib/*.jar files we distribute in binary
releases? I don't think they are useful for anything. The dependency
information for modules is stored in maven POMs (and can be easily
written to text files, if it's really something people are dying to
preserve).

I don't think redistributing those JARs makes any sense other than to
make Luke work... What I would suggest is to remove third-party JARs
entirely from the binary distribution and have a separate binary
artifact with a fully functional top-level Luke application.
Alternatively, move those third-party JARs to the top-level
/thirdparty folder and Luke can access them from there.

2. Some of the *.txt files both at the top-level and inside subfolders
contain obsolete information. We should at least re-read these. My
personal opinion is that some of the README.txt files inside modules
have little practical use - their content should go inside the javadoc
(package level, perhaps) and this should be the only source of
documentation.

3. I would remove the "zip" binary distribution. I'm on Windows myself
so tgz is a tad more difficult to work with but Lucene is a library.
If somebody downloads a binary distribution they should know how to
unpack a tgz file (cygwin, total commander, whatever else).

Thoughts?

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Simplify the release artifacts [ In reply to ]
+1 overall, comments inline.

On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss <dawid.weiss@gmail.com> wrote:
>
> Hi.
>
> These are the thoughts that occurred to me while rewriting the
> packaging in the build system. I think they're worth the discussion
> because they could limit the size of the published artifacts as well
> as their perceptive quality.
>
> 1. Who is going to use the lib/*.jar files we distribute in binary
> releases? I don't think they are useful for anything. The dependency
> information for modules is stored in maven POMs (and can be easily
> written to text files, if it's really something people are dying to
> preserve).

+1

>
> I don't think redistributing those JARs makes any sense other than to
> make Luke work... What I would suggest is to remove third-party JARs
> entirely from the binary distribution and have a separate binary
> artifact with a fully functional top-level Luke application.
> Alternatively, move those third-party JARs to the top-level
> /thirdparty folder and Luke can access them from there.

+1, I think there is already an issue open to give luke its own
"release artifact"

>
> 2. Some of the *.txt files both at the top-level and inside subfolders
> contain obsolete information. We should at least re-read these. My
> personal opinion is that some of the README.txt files inside modules
> have little practical use - their content should go inside the javadoc
> (package level, perhaps) and this should be the only source of
> documentation.

+1, either nuke it, or fold it into javadoc, or at the very least
rename to README.md

>
> 3. I would remove the "zip" binary distribution. I'm on Windows myself
> so tgz is a tad more difficult to work with but Lucene is a library.
> If somebody downloads a binary distribution they should know how to
> unpack a tgz file (cygwin, total commander, whatever else).

+1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Simplify the release artifacts [ In reply to ]
For what it's worth, I did a little survey on how other
library/sdk/framework projects distribute their artifacts other than
Maven repositories.

- Log4j distributes tgz and zip artifacts via the "Download" page.
https://logging.apache.org/log4j/2.x/download.html

- JavaFX distributes only zip artifacts via the "Download" page
https://gluonhq.com/products/javafx/

- Jersey has a "Download" page but it is actually a facade to Maven Central.
https://eclipse-ee4j.github.io/jersey/download.html

- JUnit5 has no "download" page
https://junit.org/junit5/

- Spring has no "download" page (as far as I know)
https://spring.io/projects/spring-framework

- Jackson has no "download" page (github repo also serves as their
documentation).
https://github.com/FasterXML/jackson-core

They are only small examples, but it seems to me that recent or
recently renewed projects would tend to have no explicit "download"
page at all. (?)
I'm not sure there are any ASF rules or policies about that.

Tomoko

2021?10?11?(?) 21:59 Robert Muir <rcmuir@gmail.com>:
>
> +1 overall, comments inline.
>
> On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss <dawid.weiss@gmail.com> wrote:
> >
> > Hi.
> >
> > These are the thoughts that occurred to me while rewriting the
> > packaging in the build system. I think they're worth the discussion
> > because they could limit the size of the published artifacts as well
> > as their perceptive quality.
> >
> > 1. Who is going to use the lib/*.jar files we distribute in binary
> > releases? I don't think they are useful for anything. The dependency
> > information for modules is stored in maven POMs (and can be easily
> > written to text files, if it's really something people are dying to
> > preserve).
>
> +1
>
> >
> > I don't think redistributing those JARs makes any sense other than to
> > make Luke work... What I would suggest is to remove third-party JARs
> > entirely from the binary distribution and have a separate binary
> > artifact with a fully functional top-level Luke application.
> > Alternatively, move those third-party JARs to the top-level
> > /thirdparty folder and Luke can access them from there.
>
> +1, I think there is already an issue open to give luke its own
> "release artifact"
>
> >
> > 2. Some of the *.txt files both at the top-level and inside subfolders
> > contain obsolete information. We should at least re-read these. My
> > personal opinion is that some of the README.txt files inside modules
> > have little practical use - their content should go inside the javadoc
> > (package level, perhaps) and this should be the only source of
> > documentation.
>
> +1, either nuke it, or fold it into javadoc, or at the very least
> rename to README.md
>
> >
> > 3. I would remove the "zip" binary distribution. I'm on Windows myself
> > so tgz is a tad more difficult to work with but Lucene is a library.
> > If somebody downloads a binary distribution they should know how to
> > unpack a tgz file (cygwin, total commander, whatever else).
>
> +1
>
> ---------------------------------------------------------------------
> 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: Simplify the release artifacts [ In reply to ]
+1 to all suggestions.

ASF has a release policy (https://www.apache.org/legal/release-policy.html#release-distribution) and artifacts must be uploaded to the mirrors.
There is also a release distribution policy (https://infra.apache.org/release-distribution.html#download-links) that says

"The website documentation for any Apache product must provide public download links where interested parties may obtain current official source releases and accompanying cryptographic files."

So I see no reason to stop publishing binary convenience releases in the apache mirrors, although few will use that channel.

Jan

> 12. okt. 2021 kl. 01:55 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>
> For what it's worth, I did a little survey on how other
> library/sdk/framework projects distribute their artifacts other than
> Maven repositories.
>
> - Log4j distributes tgz and zip artifacts via the "Download" page.
> https://logging.apache.org/log4j/2.x/download.html
>
> - JavaFX distributes only zip artifacts via the "Download" page
> https://gluonhq.com/products/javafx/
>
> - Jersey has a "Download" page but it is actually a facade to Maven Central.
> https://eclipse-ee4j.github.io/jersey/download.html
>
> - JUnit5 has no "download" page
> https://junit.org/junit5/
>
> - Spring has no "download" page (as far as I know)
> https://spring.io/projects/spring-framework
>
> - Jackson has no "download" page (github repo also serves as their
> documentation).
> https://github.com/FasterXML/jackson-core
>
> They are only small examples, but it seems to me that recent or
> recently renewed projects would tend to have no explicit "download"
> page at all. (?)
> I'm not sure there are any ASF rules or policies about that.
>
> Tomoko
>
> 2021?10?11?(?) 21:59 Robert Muir <rcmuir@gmail.com>:
>>
>> +1 overall, comments inline.
>>
>> On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss <dawid.weiss@gmail.com> wrote:
>>>
>>> Hi.
>>>
>>> These are the thoughts that occurred to me while rewriting the
>>> packaging in the build system. I think they're worth the discussion
>>> because they could limit the size of the published artifacts as well
>>> as their perceptive quality.
>>>
>>> 1. Who is going to use the lib/*.jar files we distribute in binary
>>> releases? I don't think they are useful for anything. The dependency
>>> information for modules is stored in maven POMs (and can be easily
>>> written to text files, if it's really something people are dying to
>>> preserve).
>>
>> +1
>>
>>>
>>> I don't think redistributing those JARs makes any sense other than to
>>> make Luke work... What I would suggest is to remove third-party JARs
>>> entirely from the binary distribution and have a separate binary
>>> artifact with a fully functional top-level Luke application.
>>> Alternatively, move those third-party JARs to the top-level
>>> /thirdparty folder and Luke can access them from there.
>>
>> +1, I think there is already an issue open to give luke its own
>> "release artifact"
>>
>>>
>>> 2. Some of the *.txt files both at the top-level and inside subfolders
>>> contain obsolete information. We should at least re-read these. My
>>> personal opinion is that some of the README.txt files inside modules
>>> have little practical use - their content should go inside the javadoc
>>> (package level, perhaps) and this should be the only source of
>>> documentation.
>>
>> +1, either nuke it, or fold it into javadoc, or at the very least
>> rename to README.md
>>
>>>
>>> 3. I would remove the "zip" binary distribution. I'm on Windows myself
>>> so tgz is a tad more difficult to work with but Lucene is a library.
>>> If somebody downloads a binary distribution they should know how to
>>> unpack a tgz file (cygwin, total commander, whatever else).
>>
>> +1
>>
>> ---------------------------------------------------------------------
>> 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: Simplify the release artifacts [ In reply to ]
Well there's definitely a good reason to stop publishing convenience
binaries: they aren't required.

Lucene is a library.

I think it makes sense to publish convenience binaries for the luke
App, that's it.

Otherwise, we should publish just source code, that's all that is required.
Library users want to use build systems like gradle and maven, so we
should put the classfiles there too.

But there's zero requirement to make zips and tgzs of .class files and
3rd party libs up on the website. zero. and if no one is using them,
we should stop doing it.

Instead i'd rather focus on testing of what counts (e.g. do those jar
files going to maven have included javadocs so it works well in the
IDE?). These aspects are more important for a library.

On Mon, Oct 11, 2021 at 8:21 PM Jan Høydahl <jan.asf@cominvent.com> wrote:
>
> +1 to all suggestions.
>
> ASF has a release policy (https://www.apache.org/legal/release-policy.html#release-distribution) and artifacts must be uploaded to the mirrors.
> There is also a release distribution policy (https://infra.apache.org/release-distribution.html#download-links) that says
>
> "The website documentation for any Apache product must provide public download links where interested parties may obtain current official source releases and accompanying cryptographic files."
>
> So I see no reason to stop publishing binary convenience releases in the apache mirrors, although few will use that channel.
>
> Jan
>
> 12. okt. 2021 kl. 01:55 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>
> For what it's worth, I did a little survey on how other
> library/sdk/framework projects distribute their artifacts other than
> Maven repositories.
>
> - Log4j distributes tgz and zip artifacts via the "Download" page.
> https://logging.apache.org/log4j/2.x/download.html
>
> - JavaFX distributes only zip artifacts via the "Download" page
> https://gluonhq.com/products/javafx/
>
> - Jersey has a "Download" page but it is actually a facade to Maven Central.
> https://eclipse-ee4j.github.io/jersey/download.html
>
> - JUnit5 has no "download" page
> https://junit.org/junit5/
>
> - Spring has no "download" page (as far as I know)
> https://spring.io/projects/spring-framework
>
> - Jackson has no "download" page (github repo also serves as their
> documentation).
> https://github.com/FasterXML/jackson-core
>
> They are only small examples, but it seems to me that recent or
> recently renewed projects would tend to have no explicit "download"
> page at all. (?)
> I'm not sure there are any ASF rules or policies about that.
>
> Tomoko
>
> 2021?10?11?(?) 21:59 Robert Muir <rcmuir@gmail.com>:
>
>
> +1 overall, comments inline.
>
> On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss <dawid.weiss@gmail.com> wrote:
>
>
> Hi.
>
> These are the thoughts that occurred to me while rewriting the
> packaging in the build system. I think they're worth the discussion
> because they could limit the size of the published artifacts as well
> as their perceptive quality.
>
> 1. Who is going to use the lib/*.jar files we distribute in binary
> releases? I don't think they are useful for anything. The dependency
> information for modules is stored in maven POMs (and can be easily
> written to text files, if it's really something people are dying to
> preserve).
>
>
> +1
>
>
> I don't think redistributing those JARs makes any sense other than to
> make Luke work... What I would suggest is to remove third-party JARs
> entirely from the binary distribution and have a separate binary
> artifact with a fully functional top-level Luke application.
> Alternatively, move those third-party JARs to the top-level
> /thirdparty folder and Luke can access them from there.
>
>
> +1, I think there is already an issue open to give luke its own
> "release artifact"
>
>
> 2. Some of the *.txt files both at the top-level and inside subfolders
> contain obsolete information. We should at least re-read these. My
> personal opinion is that some of the README.txt files inside modules
> have little practical use - their content should go inside the javadoc
> (package level, perhaps) and this should be the only source of
> documentation.
>
>
> +1, either nuke it, or fold it into javadoc, or at the very least
> rename to README.md
>
>
> 3. I would remove the "zip" binary distribution. I'm on Windows myself
> so tgz is a tad more difficult to work with but Lucene is a library.
> If somebody downloads a binary distribution they should know how to
> unpack a tgz file (cygwin, total commander, whatever else).
>
>
> +1
>
> ---------------------------------------------------------------------
> 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: Simplify the release artifacts [ In reply to ]
Thank you for the discussion. I think it'll be easier to take this
forward if presented with a concrete example of what a "binary"
release can look like, what Luke distribution is, etc.

Let's start by completing the updates to how artifacts are assembled
and making the smoke tester work with these - this should be a low
hanging fruit opening
the possibility of a release. I would love to simplify the binary
artifacts but it can come as a logical next step once we have the
release infrastructure working
on the current main.

Dawid

On Tue, Oct 12, 2021 at 2:27 AM Robert Muir <rcmuir@gmail.com> wrote:
>
> Well there's definitely a good reason to stop publishing convenience
> binaries: they aren't required.
>
> Lucene is a library.
>
> I think it makes sense to publish convenience binaries for the luke
> App, that's it.
>
> Otherwise, we should publish just source code, that's all that is required.
> Library users want to use build systems like gradle and maven, so we
> should put the classfiles there too.
>
> But there's zero requirement to make zips and tgzs of .class files and
> 3rd party libs up on the website. zero. and if no one is using them,
> we should stop doing it.
>
> Instead i'd rather focus on testing of what counts (e.g. do those jar
> files going to maven have included javadocs so it works well in the
> IDE?). These aspects are more important for a library.
>
> On Mon, Oct 11, 2021 at 8:21 PM Jan Høydahl <jan.asf@cominvent.com> wrote:
> >
> > +1 to all suggestions.
> >
> > ASF has a release policy (https://www.apache.org/legal/release-policy.html#release-distribution) and artifacts must be uploaded to the mirrors.
> > There is also a release distribution policy (https://infra.apache.org/release-distribution.html#download-links) that says
> >
> > "The website documentation for any Apache product must provide public download links where interested parties may obtain current official source releases and accompanying cryptographic files."
> >
> > So I see no reason to stop publishing binary convenience releases in the apache mirrors, although few will use that channel.
> >
> > Jan
> >
> > 12. okt. 2021 kl. 01:55 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
> >
> > For what it's worth, I did a little survey on how other
> > library/sdk/framework projects distribute their artifacts other than
> > Maven repositories.
> >
> > - Log4j distributes tgz and zip artifacts via the "Download" page.
> > https://logging.apache.org/log4j/2.x/download.html
> >
> > - JavaFX distributes only zip artifacts via the "Download" page
> > https://gluonhq.com/products/javafx/
> >
> > - Jersey has a "Download" page but it is actually a facade to Maven Central.
> > https://eclipse-ee4j.github.io/jersey/download.html
> >
> > - JUnit5 has no "download" page
> > https://junit.org/junit5/
> >
> > - Spring has no "download" page (as far as I know)
> > https://spring.io/projects/spring-framework
> >
> > - Jackson has no "download" page (github repo also serves as their
> > documentation).
> > https://github.com/FasterXML/jackson-core
> >
> > They are only small examples, but it seems to me that recent or
> > recently renewed projects would tend to have no explicit "download"
> > page at all. (?)
> > I'm not sure there are any ASF rules or policies about that.
> >
> > Tomoko
> >
> > 2021?10?11?(?) 21:59 Robert Muir <rcmuir@gmail.com>:
> >
> >
> > +1 overall, comments inline.
> >
> > On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss <dawid.weiss@gmail.com> wrote:
> >
> >
> > Hi.
> >
> > These are the thoughts that occurred to me while rewriting the
> > packaging in the build system. I think they're worth the discussion
> > because they could limit the size of the published artifacts as well
> > as their perceptive quality.
> >
> > 1. Who is going to use the lib/*.jar files we distribute in binary
> > releases? I don't think they are useful for anything. The dependency
> > information for modules is stored in maven POMs (and can be easily
> > written to text files, if it's really something people are dying to
> > preserve).
> >
> >
> > +1
> >
> >
> > I don't think redistributing those JARs makes any sense other than to
> > make Luke work... What I would suggest is to remove third-party JARs
> > entirely from the binary distribution and have a separate binary
> > artifact with a fully functional top-level Luke application.
> > Alternatively, move those third-party JARs to the top-level
> > /thirdparty folder and Luke can access them from there.
> >
> >
> > +1, I think there is already an issue open to give luke its own
> > "release artifact"
> >
> >
> > 2. Some of the *.txt files both at the top-level and inside subfolders
> > contain obsolete information. We should at least re-read these. My
> > personal opinion is that some of the README.txt files inside modules
> > have little practical use - their content should go inside the javadoc
> > (package level, perhaps) and this should be the only source of
> > documentation.
> >
> >
> > +1, either nuke it, or fold it into javadoc, or at the very least
> > rename to README.md
> >
> >
> > 3. I would remove the "zip" binary distribution. I'm on Windows myself
> > so tgz is a tad more difficult to work with but Lucene is a library.
> > If somebody downloads a binary distribution they should know how to
> > unpack a tgz file (cygwin, total commander, whatever else).
> >
> >
> > +1
> >
> > ---------------------------------------------------------------------
> > 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Simplify the release artifacts [ In reply to ]
If a dedicated issue for the stand-alone luke distribution is needed,
I think this is the one: LUCENE-9978. I have not worked on this yet,
since I thought it would be better to wait until the upcoming release
is completed.
I'm ready to start working on this, but it could/should be delegated
to another issue with a much broader perspective.

Thanks,
Tomoko

2021?10?12?(?) 16:19 Dawid Weiss <dawid.weiss@gmail.com>:

>
> Thank you for the discussion. I think it'll be easier to take this
> forward if presented with a concrete example of what a "binary"
> release can look like, what Luke distribution is, etc.
>
> Let's start by completing the updates to how artifacts are assembled
> and making the smoke tester work with these - this should be a low
> hanging fruit opening
> the possibility of a release. I would love to simplify the binary
> artifacts but it can come as a logical next step once we have the
> release infrastructure working
> on the current main.
>
> Dawid
>
> On Tue, Oct 12, 2021 at 2:27 AM Robert Muir <rcmuir@gmail.com> wrote:
> >
> > Well there's definitely a good reason to stop publishing convenience
> > binaries: they aren't required.
> >
> > Lucene is a library.
> >
> > I think it makes sense to publish convenience binaries for the luke
> > App, that's it.
> >
> > Otherwise, we should publish just source code, that's all that is required.
> > Library users want to use build systems like gradle and maven, so we
> > should put the classfiles there too.
> >
> > But there's zero requirement to make zips and tgzs of .class files and
> > 3rd party libs up on the website. zero. and if no one is using them,
> > we should stop doing it.
> >
> > Instead i'd rather focus on testing of what counts (e.g. do those jar
> > files going to maven have included javadocs so it works well in the
> > IDE?). These aspects are more important for a library.
> >
> > On Mon, Oct 11, 2021 at 8:21 PM Jan Høydahl <jan.asf@cominvent.com> wrote:
> > >
> > > +1 to all suggestions.
> > >
> > > ASF has a release policy (https://www.apache.org/legal/release-policy.html#release-distribution) and artifacts must be uploaded to the mirrors.
> > > There is also a release distribution policy (https://infra.apache.org/release-distribution.html#download-links) that says
> > >
> > > "The website documentation for any Apache product must provide public download links where interested parties may obtain current official source releases and accompanying cryptographic files."
> > >
> > > So I see no reason to stop publishing binary convenience releases in the apache mirrors, although few will use that channel.
> > >
> > > Jan
> > >
> > > 12. okt. 2021 kl. 01:55 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
> > >
> > > For what it's worth, I did a little survey on how other
> > > library/sdk/framework projects distribute their artifacts other than
> > > Maven repositories.
> > >
> > > - Log4j distributes tgz and zip artifacts via the "Download" page.
> > > https://logging.apache.org/log4j/2.x/download.html
> > >
> > > - JavaFX distributes only zip artifacts via the "Download" page
> > > https://gluonhq.com/products/javafx/
> > >
> > > - Jersey has a "Download" page but it is actually a facade to Maven Central.
> > > https://eclipse-ee4j.github.io/jersey/download.html
> > >
> > > - JUnit5 has no "download" page
> > > https://junit.org/junit5/
> > >
> > > - Spring has no "download" page (as far as I know)
> > > https://spring.io/projects/spring-framework
> > >
> > > - Jackson has no "download" page (github repo also serves as their
> > > documentation).
> > > https://github.com/FasterXML/jackson-core
> > >
> > > They are only small examples, but it seems to me that recent or
> > > recently renewed projects would tend to have no explicit "download"
> > > page at all. (?)
> > > I'm not sure there are any ASF rules or policies about that.
> > >
> > > Tomoko
> > >
> > > 2021?10?11?(?) 21:59 Robert Muir <rcmuir@gmail.com>:
> > >
> > >
> > > +1 overall, comments inline.
> > >
> > > On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss <dawid.weiss@gmail.com> wrote:
> > >
> > >
> > > Hi.
> > >
> > > These are the thoughts that occurred to me while rewriting the
> > > packaging in the build system. I think they're worth the discussion
> > > because they could limit the size of the published artifacts as well
> > > as their perceptive quality.
> > >
> > > 1. Who is going to use the lib/*.jar files we distribute in binary
> > > releases? I don't think they are useful for anything. The dependency
> > > information for modules is stored in maven POMs (and can be easily
> > > written to text files, if it's really something people are dying to
> > > preserve).
> > >
> > >
> > > +1
> > >
> > >
> > > I don't think redistributing those JARs makes any sense other than to
> > > make Luke work... What I would suggest is to remove third-party JARs
> > > entirely from the binary distribution and have a separate binary
> > > artifact with a fully functional top-level Luke application.
> > > Alternatively, move those third-party JARs to the top-level
> > > /thirdparty folder and Luke can access them from there.
> > >
> > >
> > > +1, I think there is already an issue open to give luke its own
> > > "release artifact"
> > >
> > >
> > > 2. Some of the *.txt files both at the top-level and inside subfolders
> > > contain obsolete information. We should at least re-read these. My
> > > personal opinion is that some of the README.txt files inside modules
> > > have little practical use - their content should go inside the javadoc
> > > (package level, perhaps) and this should be the only source of
> > > documentation.
> > >
> > >
> > > +1, either nuke it, or fold it into javadoc, or at the very least
> > > rename to README.md
> > >
> > >
> > > 3. I would remove the "zip" binary distribution. I'm on Windows myself
> > > so tgz is a tad more difficult to work with but Lucene is a library.
> > > If somebody downloads a binary distribution they should know how to
> > > unpack a tgz file (cygwin, total commander, whatever else).
> > >
> > >
> > > +1
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
> ---------------------------------------------------------------------
> 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: Simplify the release artifacts [ In reply to ]
I remember the issue and linked to it, Tomoko. Luke distribution
should be done as part of the binary artifacts refactoring - these are
connected issues, I think.

Dawid

On Tue, Oct 12, 2021 at 10:07 AM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> If a dedicated issue for the stand-alone luke distribution is needed,
> I think this is the one: LUCENE-9978. I have not worked on this yet,
> since I thought it would be better to wait until the upcoming release
> is completed.
> I'm ready to start working on this, but it could/should be delegated
> to another issue with a much broader perspective.
>
> Thanks,
> Tomoko
>
> 2021?10?12?(?) 16:19 Dawid Weiss <dawid.weiss@gmail.com>:
>
> >
> > Thank you for the discussion. I think it'll be easier to take this
> > forward if presented with a concrete example of what a "binary"
> > release can look like, what Luke distribution is, etc.
> >
> > Let's start by completing the updates to how artifacts are assembled
> > and making the smoke tester work with these - this should be a low
> > hanging fruit opening
> > the possibility of a release. I would love to simplify the binary
> > artifacts but it can come as a logical next step once we have the
> > release infrastructure working
> > on the current main.
> >
> > Dawid
> >
> > On Tue, Oct 12, 2021 at 2:27 AM Robert Muir <rcmuir@gmail.com> wrote:
> > >
> > > Well there's definitely a good reason to stop publishing convenience
> > > binaries: they aren't required.
> > >
> > > Lucene is a library.
> > >
> > > I think it makes sense to publish convenience binaries for the luke
> > > App, that's it.
> > >
> > > Otherwise, we should publish just source code, that's all that is required.
> > > Library users want to use build systems like gradle and maven, so we
> > > should put the classfiles there too.
> > >
> > > But there's zero requirement to make zips and tgzs of .class files and
> > > 3rd party libs up on the website. zero. and if no one is using them,
> > > we should stop doing it.
> > >
> > > Instead i'd rather focus on testing of what counts (e.g. do those jar
> > > files going to maven have included javadocs so it works well in the
> > > IDE?). These aspects are more important for a library.
> > >
> > > On Mon, Oct 11, 2021 at 8:21 PM Jan Høydahl <jan.asf@cominvent.com> wrote:
> > > >
> > > > +1 to all suggestions.
> > > >
> > > > ASF has a release policy (https://www.apache.org/legal/release-policy.html#release-distribution) and artifacts must be uploaded to the mirrors.
> > > > There is also a release distribution policy (https://infra.apache.org/release-distribution.html#download-links) that says
> > > >
> > > > "The website documentation for any Apache product must provide public download links where interested parties may obtain current official source releases and accompanying cryptographic files."
> > > >
> > > > So I see no reason to stop publishing binary convenience releases in the apache mirrors, although few will use that channel.
> > > >
> > > > Jan
> > > >
> > > > 12. okt. 2021 kl. 01:55 skrev Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
> > > >
> > > > For what it's worth, I did a little survey on how other
> > > > library/sdk/framework projects distribute their artifacts other than
> > > > Maven repositories.
> > > >
> > > > - Log4j distributes tgz and zip artifacts via the "Download" page.
> > > > https://logging.apache.org/log4j/2.x/download.html
> > > >
> > > > - JavaFX distributes only zip artifacts via the "Download" page
> > > > https://gluonhq.com/products/javafx/
> > > >
> > > > - Jersey has a "Download" page but it is actually a facade to Maven Central.
> > > > https://eclipse-ee4j.github.io/jersey/download.html
> > > >
> > > > - JUnit5 has no "download" page
> > > > https://junit.org/junit5/
> > > >
> > > > - Spring has no "download" page (as far as I know)
> > > > https://spring.io/projects/spring-framework
> > > >
> > > > - Jackson has no "download" page (github repo also serves as their
> > > > documentation).
> > > > https://github.com/FasterXML/jackson-core
> > > >
> > > > They are only small examples, but it seems to me that recent or
> > > > recently renewed projects would tend to have no explicit "download"
> > > > page at all. (?)
> > > > I'm not sure there are any ASF rules or policies about that.
> > > >
> > > > Tomoko
> > > >
> > > > 2021?10?11?(?) 21:59 Robert Muir <rcmuir@gmail.com>:
> > > >
> > > >
> > > > +1 overall, comments inline.
> > > >
> > > > On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss <dawid.weiss@gmail.com> wrote:
> > > >
> > > >
> > > > Hi.
> > > >
> > > > These are the thoughts that occurred to me while rewriting the
> > > > packaging in the build system. I think they're worth the discussion
> > > > because they could limit the size of the published artifacts as well
> > > > as their perceptive quality.
> > > >
> > > > 1. Who is going to use the lib/*.jar files we distribute in binary
> > > > releases? I don't think they are useful for anything. The dependency
> > > > information for modules is stored in maven POMs (and can be easily
> > > > written to text files, if it's really something people are dying to
> > > > preserve).
> > > >
> > > >
> > > > +1
> > > >
> > > >
> > > > I don't think redistributing those JARs makes any sense other than to
> > > > make Luke work... What I would suggest is to remove third-party JARs
> > > > entirely from the binary distribution and have a separate binary
> > > > artifact with a fully functional top-level Luke application.
> > > > Alternatively, move those third-party JARs to the top-level
> > > > /thirdparty folder and Luke can access them from there.
> > > >
> > > >
> > > > +1, I think there is already an issue open to give luke its own
> > > > "release artifact"
> > > >
> > > >
> > > > 2. Some of the *.txt files both at the top-level and inside subfolders
> > > > contain obsolete information. We should at least re-read these. My
> > > > personal opinion is that some of the README.txt files inside modules
> > > > have little practical use - their content should go inside the javadoc
> > > > (package level, perhaps) and this should be the only source of
> > > > documentation.
> > > >
> > > >
> > > > +1, either nuke it, or fold it into javadoc, or at the very least
> > > > rename to README.md
> > > >
> > > >
> > > > 3. I would remove the "zip" binary distribution. I'm on Windows myself
> > > > so tgz is a tad more difficult to work with but Lucene is a library.
> > > > If somebody downloads a binary distribution they should know how to
> > > > unpack a tgz file (cygwin, total commander, whatever else).
> > > >
> > > >
> > > > +1
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> >
> > ---------------------------------------------------------------------
> > 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: Simplify the release artifacts [ In reply to ]
Hi,

I full agree with most of the things here. Now that Solr is no longer part of Lucene, I also see no reason to have all dependencies and JAR artifacts in a TAR file!

On the other hand, binary artifacts makes reviewing the artifacts easier during a release. I am one of the persons that not only instructs policeman Jenkins to run the smoketester, I also download the artifacts and review JAR files (META-INF, completeness) and Javadocs. If we no longer have a binary release, we must also publish the javadocs of the release on the nightlies server for quick review! Maybe we can push the javadocs/documentation to apache servers before release (into a different directory name on the ASF webserver subversion server, when the release is done just "svn mv").

Without a binary release it's also harder to do a quick test with the JAR files, because they are not yet on Maven Central, so for testing one would need to make a maven project with a remote repository pointing to the staging are. There are workarounds for that, maybe we should make a script in the smoketester utilities that quickly sets up a maven project with the staging repository so you can drop in your "tryout code" and do a quick check.

So I am not fully happy to completely throw away binary artifacts.
Uwe

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

> -----Original Message-----
> From: Robert Muir <rcmuir@gmail.com>
> Sent: Tuesday, October 12, 2021 2:27 AM
> To: dev@lucene.apache.org
> Subject: Re: Simplify the release artifacts
>
> Well there's definitely a good reason to stop publishing convenience
> binaries: they aren't required.
>
> Lucene is a library.
>
> I think it makes sense to publish convenience binaries for the luke
> App, that's it.
>
> Otherwise, we should publish just source code, that's all that is required.
> Library users want to use build systems like gradle and maven, so we
> should put the classfiles there too.
>
> But there's zero requirement to make zips and tgzs of .class files and
> 3rd party libs up on the website. zero. and if no one is using them,
> we should stop doing it.
>
> Instead i'd rather focus on testing of what counts (e.g. do those jar
> files going to maven have included javadocs so it works well in the
> IDE?). These aspects are more important for a library.
>
> On Mon, Oct 11, 2021 at 8:21 PM Jan Høydahl <jan.asf@cominvent.com>
> wrote:
> >
> > +1 to all suggestions.
> >
> > ASF has a release policy (https://www.apache.org/legal/release-
> policy.html#release-distribution) and artifacts must be uploaded to the mirrors.
> > There is also a release distribution policy (https://infra.apache.org/release-
> distribution.html#download-links) that says
> >
> > "The website documentation for any Apache product must provide public
> download links where interested parties may obtain current official source
> releases and accompanying cryptographic files."
> >
> > So I see no reason to stop publishing binary convenience releases in the
> apache mirrors, although few will use that channel.
> >
> > Jan
> >
> > 12. okt. 2021 kl. 01:55 skrev Tomoko Uchida
> <tomoko.uchida.1111@gmail.com>:
> >
> > For what it's worth, I did a little survey on how other
> > library/sdk/framework projects distribute their artifacts other than
> > Maven repositories.
> >
> > - Log4j distributes tgz and zip artifacts via the "Download" page.
> > https://logging.apache.org/log4j/2.x/download.html
> >
> > - JavaFX distributes only zip artifacts via the "Download" page
> > https://gluonhq.com/products/javafx/
> >
> > - Jersey has a "Download" page but it is actually a facade to Maven Central.
> > https://eclipse-ee4j.github.io/jersey/download.html
> >
> > - JUnit5 has no "download" page
> > https://junit.org/junit5/
> >
> > - Spring has no "download" page (as far as I know)
> > https://spring.io/projects/spring-framework
> >
> > - Jackson has no "download" page (github repo also serves as their
> > documentation).
> > https://github.com/FasterXML/jackson-core
> >
> > They are only small examples, but it seems to me that recent or
> > recently renewed projects would tend to have no explicit "download"
> > page at all. (?)
> > I'm not sure there are any ASF rules or policies about that.
> >
> > Tomoko
> >
> > 2021?10?11?(?) 21:59 Robert Muir <rcmuir@gmail.com>:
> >
> >
> > +1 overall, comments inline.
> >
> > On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss <dawid.weiss@gmail.com>
> wrote:
> >
> >
> > Hi.
> >
> > These are the thoughts that occurred to me while rewriting the
> > packaging in the build system. I think they're worth the discussion
> > because they could limit the size of the published artifacts as well
> > as their perceptive quality.
> >
> > 1. Who is going to use the lib/*.jar files we distribute in binary
> > releases? I don't think they are useful for anything. The dependency
> > information for modules is stored in maven POMs (and can be easily
> > written to text files, if it's really something people are dying to
> > preserve).
> >
> >
> > +1
> >
> >
> > I don't think redistributing those JARs makes any sense other than to
> > make Luke work... What I would suggest is to remove third-party JARs
> > entirely from the binary distribution and have a separate binary
> > artifact with a fully functional top-level Luke application.
> > Alternatively, move those third-party JARs to the top-level
> > /thirdparty folder and Luke can access them from there.
> >
> >
> > +1, I think there is already an issue open to give luke its own
> > "release artifact"
> >
> >
> > 2. Some of the *.txt files both at the top-level and inside subfolders
> > contain obsolete information. We should at least re-read these. My
> > personal opinion is that some of the README.txt files inside modules
> > have little practical use - their content should go inside the javadoc
> > (package level, perhaps) and this should be the only source of
> > documentation.
> >
> >
> > +1, either nuke it, or fold it into javadoc, or at the very least
> > rename to README.md
> >
> >
> > 3. I would remove the "zip" binary distribution. I'm on Windows myself
> > so tgz is a tad more difficult to work with but Lucene is a library.
> > If somebody downloads a binary distribution they should know how to
> > unpack a tgz file (cygwin, total commander, whatever else).
> >
> >
> > +1
> >
> > ---------------------------------------------------------------------
> > 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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Simplify the release artifacts [ In reply to ]
I'm fine with just Lucene binaries, signed JARs and checksums +
pre-rendered documentation for convenience purposes.

> Without a binary release it's also harder to do a quick test with the JAR files, because they are not yet on Maven Central,

You can install the artifacts locally (~/.m2 - gradlew mavenToLocal)
or just assemble them in a release build folder (the pending patch). I
think this should be enough for experiments?

D.

On Tue, Oct 12, 2021 at 10:42 AM Uwe Schindler <uwe@thetaphi.de> wrote:
>
> Hi,
>
> I full agree with most of the things here. Now that Solr is no longer part of Lucene, I also see no reason to have all dependencies and JAR artifacts in a TAR file!
>
> On the other hand, binary artifacts makes reviewing the artifacts easier during a release. I am one of the persons that not only instructs policeman Jenkins to run the smoketester, I also download the artifacts and review JAR files (META-INF, completeness) and Javadocs. If we no longer have a binary release, we must also publish the javadocs of the release on the nightlies server for quick review! Maybe we can push the javadocs/documentation to apache servers before release (into a different directory name on the ASF webserver subversion server, when the release is done just "svn mv").
>
> Without a binary release it's also harder to do a quick test with the JAR files, because they are not yet on Maven Central, so for testing one would need to make a maven project with a remote repository pointing to the staging are. There are workarounds for that, maybe we should make a script in the smoketester utilities that quickly sets up a maven project with the staging repository so you can drop in your "tryout code" and do a quick check.
>
> So I am not fully happy to completely throw away binary artifacts.
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Robert Muir <rcmuir@gmail.com>
> > Sent: Tuesday, October 12, 2021 2:27 AM
> > To: dev@lucene.apache.org
> > Subject: Re: Simplify the release artifacts
> >
> > Well there's definitely a good reason to stop publishing convenience
> > binaries: they aren't required.
> >
> > Lucene is a library.
> >
> > I think it makes sense to publish convenience binaries for the luke
> > App, that's it.
> >
> > Otherwise, we should publish just source code, that's all that is required.
> > Library users want to use build systems like gradle and maven, so we
> > should put the classfiles there too.
> >
> > But there's zero requirement to make zips and tgzs of .class files and
> > 3rd party libs up on the website. zero. and if no one is using them,
> > we should stop doing it.
> >
> > Instead i'd rather focus on testing of what counts (e.g. do those jar
> > files going to maven have included javadocs so it works well in the
> > IDE?). These aspects are more important for a library.
> >
> > On Mon, Oct 11, 2021 at 8:21 PM Jan Høydahl <jan.asf@cominvent.com>
> > wrote:
> > >
> > > +1 to all suggestions.
> > >
> > > ASF has a release policy (https://www.apache.org/legal/release-
> > policy.html#release-distribution) and artifacts must be uploaded to the mirrors.
> > > There is also a release distribution policy (https://infra.apache.org/release-
> > distribution.html#download-links) that says
> > >
> > > "The website documentation for any Apache product must provide public
> > download links where interested parties may obtain current official source
> > releases and accompanying cryptographic files."
> > >
> > > So I see no reason to stop publishing binary convenience releases in the
> > apache mirrors, although few will use that channel.
> > >
> > > Jan
> > >
> > > 12. okt. 2021 kl. 01:55 skrev Tomoko Uchida
> > <tomoko.uchida.1111@gmail.com>:
> > >
> > > For what it's worth, I did a little survey on how other
> > > library/sdk/framework projects distribute their artifacts other than
> > > Maven repositories.
> > >
> > > - Log4j distributes tgz and zip artifacts via the "Download" page.
> > > https://logging.apache.org/log4j/2.x/download.html
> > >
> > > - JavaFX distributes only zip artifacts via the "Download" page
> > > https://gluonhq.com/products/javafx/
> > >
> > > - Jersey has a "Download" page but it is actually a facade to Maven Central.
> > > https://eclipse-ee4j.github.io/jersey/download.html
> > >
> > > - JUnit5 has no "download" page
> > > https://junit.org/junit5/
> > >
> > > - Spring has no "download" page (as far as I know)
> > > https://spring.io/projects/spring-framework
> > >
> > > - Jackson has no "download" page (github repo also serves as their
> > > documentation).
> > > https://github.com/FasterXML/jackson-core
> > >
> > > They are only small examples, but it seems to me that recent or
> > > recently renewed projects would tend to have no explicit "download"
> > > page at all. (?)
> > > I'm not sure there are any ASF rules or policies about that.
> > >
> > > Tomoko
> > >
> > > 2021?10?11?(?) 21:59 Robert Muir <rcmuir@gmail.com>:
> > >
> > >
> > > +1 overall, comments inline.
> > >
> > > On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss <dawid.weiss@gmail.com>
> > wrote:
> > >
> > >
> > > Hi.
> > >
> > > These are the thoughts that occurred to me while rewriting the
> > > packaging in the build system. I think they're worth the discussion
> > > because they could limit the size of the published artifacts as well
> > > as their perceptive quality.
> > >
> > > 1. Who is going to use the lib/*.jar files we distribute in binary
> > > releases? I don't think they are useful for anything. The dependency
> > > information for modules is stored in maven POMs (and can be easily
> > > written to text files, if it's really something people are dying to
> > > preserve).
> > >
> > >
> > > +1
> > >
> > >
> > > I don't think redistributing those JARs makes any sense other than to
> > > make Luke work... What I would suggest is to remove third-party JARs
> > > entirely from the binary distribution and have a separate binary
> > > artifact with a fully functional top-level Luke application.
> > > Alternatively, move those third-party JARs to the top-level
> > > /thirdparty folder and Luke can access them from there.
> > >
> > >
> > > +1, I think there is already an issue open to give luke its own
> > > "release artifact"
> > >
> > >
> > > 2. Some of the *.txt files both at the top-level and inside subfolders
> > > contain obsolete information. We should at least re-read these. My
> > > personal opinion is that some of the README.txt files inside modules
> > > have little practical use - their content should go inside the javadoc
> > > (package level, perhaps) and this should be the only source of
> > > documentation.
> > >
> > >
> > > +1, either nuke it, or fold it into javadoc, or at the very least
> > > rename to README.md
> > >
> > >
> > > 3. I would remove the "zip" binary distribution. I'm on Windows myself
> > > so tgz is a tad more difficult to work with but Lucene is a library.
> > > If somebody downloads a binary distribution they should know how to
> > > unpack a tgz file (cygwin, total commander, whatever else).
> > >
> > >
> > > +1
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
>
> ---------------------------------------------------------------------
> 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: Simplify the release artifacts [ In reply to ]
Hi,

> I'm fine with just Lucene binaries, signed JARs and checksums +
> pre-rendered documentation for convenience purposes.

Sure, thanks.

> > Without a binary release it's also harder to do a quick test with the JAR files,
> because they are not yet on Maven Central,
>
> You can install the artifacts locally (~/.m2 - gradlew mavenToLocal)
> or just assemble them in a release build folder (the pending patch). I
> think this should be enough for experiments?

That's what I mentioned in my mail, just a bit different (using remote repo): The artifacts are also on the dist.apache.or server in subdirectory ".../VERSION/lucene/maven" and "solr/maven" (at least currently for 8.x). Those repos can be used also as remote repository. But as the URL is a bit complex you need a lot of copypaste to setup a local project. And with current 8.x process it is even more complicated because Solr and Lucene have separate meven trees, so you need to add 2 repositories. I often do this to check my Solr Plugins of my customers ????. I have a gist somewhere to copypaste the correct config options for gradle/maven projects.

Why I am telling this: I'd like to test the "official" to-be-released JAR files with their hashes as seen and uploaded to ASF servers, so mavenLocal is not my first preference. I would be fine if local JARs would have same hashes, but this does not work due to timestamps or operating system and java compiler differences inside. It could be that the release manager used a buggy JDK with broken javac ????. I the past I also checked the MR-JARs manually in the 8.x branch to make sure it looks fine.

In short: A targz file is just easier to "manually" review.

Uwe

> On Tue, Oct 12, 2021 at 10:42 AM Uwe Schindler <uwe@thetaphi.de> wrote:
> >
> > Hi,
> >
> > I full agree with most of the things here. Now that Solr is no longer part of
> Lucene, I also see no reason to have all dependencies and JAR artifacts in a TAR
> file!
> >
> > On the other hand, binary artifacts makes reviewing the artifacts easier
> during a release. I am one of the persons that not only instructs policeman
> Jenkins to run the smoketester, I also download the artifacts and review JAR
> files (META-INF, completeness) and Javadocs. If we no longer have a binary
> release, we must also publish the javadocs of the release on the nightlies server
> for quick review! Maybe we can push the javadocs/documentation to apache
> servers before release (into a different directory name on the ASF webserver
> subversion server, when the release is done just "svn mv").
> >
> > Without a binary release it's also harder to do a quick test with the JAR files,
> because they are not yet on Maven Central, so for testing one would need to
> make a maven project with a remote repository pointing to the staging are.
> There are workarounds for that, maybe we should make a script in the
> smoketester utilities that quickly sets up a maven project with the staging
> repository so you can drop in your "tryout code" and do a quick check.
> >
> > So I am not fully happy to completely throw away binary artifacts.
> > Uwe
> >
> > -----
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> > > -----Original Message-----
> > > From: Robert Muir <rcmuir@gmail.com>
> > > Sent: Tuesday, October 12, 2021 2:27 AM
> > > To: dev@lucene.apache.org
> > > Subject: Re: Simplify the release artifacts
> > >
> > > Well there's definitely a good reason to stop publishing convenience
> > > binaries: they aren't required.
> > >
> > > Lucene is a library.
> > >
> > > I think it makes sense to publish convenience binaries for the luke
> > > App, that's it.
> > >
> > > Otherwise, we should publish just source code, that's all that is required.
> > > Library users want to use build systems like gradle and maven, so we
> > > should put the classfiles there too.
> > >
> > > But there's zero requirement to make zips and tgzs of .class files and
> > > 3rd party libs up on the website. zero. and if no one is using them,
> > > we should stop doing it.
> > >
> > > Instead i'd rather focus on testing of what counts (e.g. do those jar
> > > files going to maven have included javadocs so it works well in the
> > > IDE?). These aspects are more important for a library.
> > >
> > > On Mon, Oct 11, 2021 at 8:21 PM Jan Høydahl <jan.asf@cominvent.com>
> > > wrote:
> > > >
> > > > +1 to all suggestions.
> > > >
> > > > ASF has a release policy (https://www.apache.org/legal/release-
> > > policy.html#release-distribution) and artifacts must be uploaded to the
> mirrors.
> > > > There is also a release distribution policy
> (https://infra.apache.org/release-
> > > distribution.html#download-links) that says
> > > >
> > > > "The website documentation for any Apache product must provide
> public
> > > download links where interested parties may obtain current official source
> > > releases and accompanying cryptographic files."
> > > >
> > > > So I see no reason to stop publishing binary convenience releases in the
> > > apache mirrors, although few will use that channel.
> > > >
> > > > Jan
> > > >
> > > > 12. okt. 2021 kl. 01:55 skrev Tomoko Uchida
> > > <tomoko.uchida.1111@gmail.com>:
> > > >
> > > > For what it's worth, I did a little survey on how other
> > > > library/sdk/framework projects distribute their artifacts other than
> > > > Maven repositories.
> > > >
> > > > - Log4j distributes tgz and zip artifacts via the "Download" page.
> > > > https://logging.apache.org/log4j/2.x/download.html
> > > >
> > > > - JavaFX distributes only zip artifacts via the "Download" page
> > > > https://gluonhq.com/products/javafx/
> > > >
> > > > - Jersey has a "Download" page but it is actually a facade to Maven
> Central.
> > > > https://eclipse-ee4j.github.io/jersey/download.html
> > > >
> > > > - JUnit5 has no "download" page
> > > > https://junit.org/junit5/
> > > >
> > > > - Spring has no "download" page (as far as I know)
> > > > https://spring.io/projects/spring-framework
> > > >
> > > > - Jackson has no "download" page (github repo also serves as their
> > > > documentation).
> > > > https://github.com/FasterXML/jackson-core
> > > >
> > > > They are only small examples, but it seems to me that recent or
> > > > recently renewed projects would tend to have no explicit "download"
> > > > page at all. (?)
> > > > I'm not sure there are any ASF rules or policies about that.
> > > >
> > > > Tomoko
> > > >
> > > > 2021?10?11?(?) 21:59 Robert Muir <rcmuir@gmail.com>:
> > > >
> > > >
> > > > +1 overall, comments inline.
> > > >
> > > > On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss
> <dawid.weiss@gmail.com>
> > > wrote:
> > > >
> > > >
> > > > Hi.
> > > >
> > > > These are the thoughts that occurred to me while rewriting the
> > > > packaging in the build system. I think they're worth the discussion
> > > > because they could limit the size of the published artifacts as well
> > > > as their perceptive quality.
> > > >
> > > > 1. Who is going to use the lib/*.jar files we distribute in binary
> > > > releases? I don't think they are useful for anything. The dependency
> > > > information for modules is stored in maven POMs (and can be easily
> > > > written to text files, if it's really something people are dying to
> > > > preserve).
> > > >
> > > >
> > > > +1
> > > >
> > > >
> > > > I don't think redistributing those JARs makes any sense other than to
> > > > make Luke work... What I would suggest is to remove third-party JARs
> > > > entirely from the binary distribution and have a separate binary
> > > > artifact with a fully functional top-level Luke application.
> > > > Alternatively, move those third-party JARs to the top-level
> > > > /thirdparty folder and Luke can access them from there.
> > > >
> > > >
> > > > +1, I think there is already an issue open to give luke its own
> > > > "release artifact"
> > > >
> > > >
> > > > 2. Some of the *.txt files both at the top-level and inside subfolders
> > > > contain obsolete information. We should at least re-read these. My
> > > > personal opinion is that some of the README.txt files inside modules
> > > > have little practical use - their content should go inside the javadoc
> > > > (package level, perhaps) and this should be the only source of
> > > > documentation.
> > > >
> > > >
> > > > +1, either nuke it, or fold it into javadoc, or at the very least
> > > > rename to README.md
> > > >
> > > >
> > > > 3. I would remove the "zip" binary distribution. I'm on Windows myself
> > > > so tgz is a tad more difficult to work with but Lucene is a library.
> > > > If somebody downloads a binary distribution they should know how to
> > > > unpack a tgz file (cygwin, total commander, whatever else).
> > > >
> > > >
> > > > +1
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> >
> >
> > ---------------------------------------------------------------------
> > 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: Simplify the release artifacts [ In reply to ]
> Why I am telling this: I'd like to test the "official" to-be-released JAR files with their hashes as seen and uploaded to ASF servers, so mavenLocal is not my first preference.

Correct - the same build (from the same git revision) will not result
in identical JARs. This can be done but you'll pay the price -- you'd
have to remove all of the variable jar manifest entries (user,
compiler, etc.). This is valuable, I think, so don't consider this a
priority.

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Simplify the release artifacts [ In reply to ]
> In short: A targz file is just easier to "manually" review.

This is off-topic: I'm curious about if some part of the manual review
can be done at daily automated routines (tests, precommit checks,
etc.). I'm not against having a binary distribution for pre-release
review or other purposes (as it used to be done) at all; I just hope
we could reduce the manual effort and worries for every release...

Tomoko

2021?10?12?(?) 19:32 Dawid Weiss <dawid.weiss@gmail.com>:
>
> > Why I am telling this: I'd like to test the "official" to-be-released JAR files with their hashes as seen and uploaded to ASF servers, so mavenLocal is not my first preference.
>
> Correct - the same build (from the same git revision) will not result
> in identical JARs. This can be done but you'll pay the price -- you'd
> have to remove all of the variable jar manifest entries (user,
> compiler, etc.). This is valuable, I think, so don't consider this a
> priority.
>
> 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