Mailing List Archive

A proposition: Make Luke a standalone package (again)
Hello,

As a byproduct of LUCENE-9448, we now have a neat gradle task (thank
you Dawid!) to assemble a standalone Luke package.

I think it makes sense to distribute the standalone "Luke app" that
contains only its executable-jar and minimum dependencies to run it,
as it used to be, on Lucene download page (
https://lucene.apache.org/core/downloads.html ).

Pros:
- Easy to understand for users who need it
- No need to rely on strange hacks to discover dependencies (jars) for
running it

Cons:
- Duplication of many jars (analyzers, queries, codec, etc.)

I am sure it makes sense for long-term Luke users who used to just
download Luke from the original or forked sites - but let me know if
there is anyone who has thoughts (eg. from the aritifact maintainers'
perspective) on it.
If there is no objection/concern, I will explore what changes are
required to do so on LUCENE-9978.

Final note: It doesn't affect ongoing 9.0 release. With the assemble
task, Luke works just fine as before.

Thanks,
Tomoko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: A proposition: Make Luke a standalone package (again) [ In reply to ]
+1, it is an application. So let's package it in a way, so that it is
easy to run this application.
This is a bit different than packaging a library: different target
audience for example (developers vs. operations and other folks)

Definitely +1 to give luke its own "artifact" that might work a bit
differently than the usual library artifacts. The most extreme might
be a kind of shaded application jar, very friendly to the common case,
but perhaps most hostile to expert cases (such as adding custom
analyzers and codecs to classpath). Maybe it's the right tradeoff
though, or something in between: seems like we can sort out those
details.

On Fri, May 28, 2021 at 11:10 PM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> Hello,
>
> As a byproduct of LUCENE-9448, we now have a neat gradle task (thank
> you Dawid!) to assemble a standalone Luke package.
>
> I think it makes sense to distribute the standalone "Luke app" that
> contains only its executable-jar and minimum dependencies to run it,
> as it used to be, on Lucene download page (
> https://lucene.apache.org/core/downloads.html ).
>
> Pros:
> - Easy to understand for users who need it
> - No need to rely on strange hacks to discover dependencies (jars) for
> running it
>
> Cons:
> - Duplication of many jars (analyzers, queries, codec, etc.)
>
> I am sure it makes sense for long-term Luke users who used to just
> download Luke from the original or forked sites - but let me know if
> there is anyone who has thoughts (eg. from the aritifact maintainers'
> perspective) on it.
> If there is no objection/concern, I will explore what changes are
> required to do so on LUCENE-9978.
>
> Final note: It doesn't affect ongoing 9.0 release. With the assemble
> task, Luke works just fine as before.
>
> Thanks,
> Tomoko
>
> ---------------------------------------------------------------------
> 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: A proposition: Make Luke a standalone package (again) [ In reply to ]
Thank you Robert for your reply.
For clarification, I think we will distribute a compressed tarball
(and may be also a zip for Windows?) which contains luke JAR (the GUI)
and its dependent JARs - not a fat or shaded jar. (I forgot to write
the important details in the previous mail.)

Tomoko

2021?5?29?(?) 12:37 Robert Muir <rcmuir@gmail.com>:
>
> +1, it is an application. So let's package it in a way, so that it is
> easy to run this application.
> This is a bit different than packaging a library: different target
> audience for example (developers vs. operations and other folks)
>
> Definitely +1 to give luke its own "artifact" that might work a bit
> differently than the usual library artifacts. The most extreme might
> be a kind of shaded application jar, very friendly to the common case,
> but perhaps most hostile to expert cases (such as adding custom
> analyzers and codecs to classpath). Maybe it's the right tradeoff
> though, or something in between: seems like we can sort out those
> details.
>
> On Fri, May 28, 2021 at 11:10 PM Tomoko Uchida
> <tomoko.uchida.1111@gmail.com> wrote:
> >
> > Hello,
> >
> > As a byproduct of LUCENE-9448, we now have a neat gradle task (thank
> > you Dawid!) to assemble a standalone Luke package.
> >
> > I think it makes sense to distribute the standalone "Luke app" that
> > contains only its executable-jar and minimum dependencies to run it,
> > as it used to be, on Lucene download page (
> > https://lucene.apache.org/core/downloads.html ).
> >
> > Pros:
> > - Easy to understand for users who need it
> > - No need to rely on strange hacks to discover dependencies (jars) for
> > running it
> >
> > Cons:
> > - Duplication of many jars (analyzers, queries, codec, etc.)
> >
> > I am sure it makes sense for long-term Luke users who used to just
> > download Luke from the original or forked sites - but let me know if
> > there is anyone who has thoughts (eg. from the aritifact maintainers'
> > perspective) on it.
> > If there is no objection/concern, I will explore what changes are
> > required to do so on LUCENE-9978.
> >
> > Final note: It doesn't affect ongoing 9.0 release. With the assemble
> > task, Luke works just fine as before.
> >
> > Thanks,
> > Tomoko
> >
> > ---------------------------------------------------------------------
> > 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: A proposition: Make Luke a standalone package (again) [ In reply to ]
That scheme sounds fine to me. It is 2021, can windows deal with .tar.gz yet? :)

On Sat, May 29, 2021 at 6:12 AM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> Thank you Robert for your reply.
> For clarification, I think we will distribute a compressed tarball
> (and may be also a zip for Windows?) which contains luke JAR (the GUI)
> and its dependent JARs - not a fat or shaded jar. (I forgot to write
> the important details in the previous mail.)
>
> Tomoko
>
> 2021?5?29?(?) 12:37 Robert Muir <rcmuir@gmail.com>:
> >
> > +1, it is an application. So let's package it in a way, so that it is
> > easy to run this application.
> > This is a bit different than packaging a library: different target
> > audience for example (developers vs. operations and other folks)
> >
> > Definitely +1 to give luke its own "artifact" that might work a bit
> > differently than the usual library artifacts. The most extreme might
> > be a kind of shaded application jar, very friendly to the common case,
> > but perhaps most hostile to expert cases (such as adding custom
> > analyzers and codecs to classpath). Maybe it's the right tradeoff
> > though, or something in between: seems like we can sort out those
> > details.
> >
> > On Fri, May 28, 2021 at 11:10 PM Tomoko Uchida
> > <tomoko.uchida.1111@gmail.com> wrote:
> > >
> > > Hello,
> > >
> > > As a byproduct of LUCENE-9448, we now have a neat gradle task (thank
> > > you Dawid!) to assemble a standalone Luke package.
> > >
> > > I think it makes sense to distribute the standalone "Luke app" that
> > > contains only its executable-jar and minimum dependencies to run it,
> > > as it used to be, on Lucene download page (
> > > https://lucene.apache.org/core/downloads.html ).
> > >
> > > Pros:
> > > - Easy to understand for users who need it
> > > - No need to rely on strange hacks to discover dependencies (jars) for
> > > running it
> > >
> > > Cons:
> > > - Duplication of many jars (analyzers, queries, codec, etc.)
> > >
> > > I am sure it makes sense for long-term Luke users who used to just
> > > download Luke from the original or forked sites - but let me know if
> > > there is anyone who has thoughts (eg. from the aritifact maintainers'
> > > perspective) on it.
> > > If there is no objection/concern, I will explore what changes are
> > > required to do so on LUCENE-9978.
> > >
> > > Final note: It doesn't affect ongoing 9.0 release. With the assemble
> > > task, Luke works just fine as before.
> > >
> > > Thanks,
> > > Tomoko
> > >
> > > ---------------------------------------------------------------------
> > > 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: A proposition: Make Luke a standalone package (again) [ In reply to ]
Hi,
Nö. Not by default.

But: why not provide only zip? You can also add Unix chmod inside zip.

Uwe

Am May 29, 2021 10:27:12 AM UTC schrieb Robert Muir <rcmuir@gmail.com>:
>That scheme sounds fine to me. It is 2021, can windows deal with
>.tar.gz yet? :)
>
>On Sat, May 29, 2021 at 6:12 AM Tomoko Uchida
><tomoko.uchida.1111@gmail.com> wrote:
>>
>> Thank you Robert for your reply.
>> For clarification, I think we will distribute a compressed tarball
>> (and may be also a zip for Windows?) which contains luke JAR (the
>GUI)
>> and its dependent JARs - not a fat or shaded jar. (I forgot to write
>> the important details in the previous mail.)
>>
>> Tomoko
>>
>> 2021?5?29?(?) 12:37 Robert Muir <rcmuir@gmail.com>:
>> >
>> > +1, it is an application. So let's package it in a way, so that it
>is
>> > easy to run this application.
>> > This is a bit different than packaging a library: different target
>> > audience for example (developers vs. operations and other folks)
>> >
>> > Definitely +1 to give luke its own "artifact" that might work a bit
>> > differently than the usual library artifacts. The most extreme
>might
>> > be a kind of shaded application jar, very friendly to the common
>case,
>> > but perhaps most hostile to expert cases (such as adding custom
>> > analyzers and codecs to classpath). Maybe it's the right tradeoff
>> > though, or something in between: seems like we can sort out those
>> > details.
>> >
>> > On Fri, May 28, 2021 at 11:10 PM Tomoko Uchida
>> > <tomoko.uchida.1111@gmail.com> wrote:
>> > >
>> > > Hello,
>> > >
>> > > As a byproduct of LUCENE-9448, we now have a neat gradle task
>(thank
>> > > you Dawid!) to assemble a standalone Luke package.
>> > >
>> > > I think it makes sense to distribute the standalone "Luke app"
>that
>> > > contains only its executable-jar and minimum dependencies to run
>it,
>> > > as it used to be, on Lucene download page (
>> > > https://lucene.apache.org/core/downloads.html ).
>> > >
>> > > Pros:
>> > > - Easy to understand for users who need it
>> > > - No need to rely on strange hacks to discover dependencies
>(jars) for
>> > > running it
>> > >
>> > > Cons:
>> > > - Duplication of many jars (analyzers, queries, codec, etc.)
>> > >
>> > > I am sure it makes sense for long-term Luke users who used to
>just
>> > > download Luke from the original or forked sites - but let me know
>if
>> > > there is anyone who has thoughts (eg. from the aritifact
>maintainers'
>> > > perspective) on it.
>> > > If there is no objection/concern, I will explore what changes are
>> > > required to do so on LUCENE-9978.
>> > >
>> > > Final note: It doesn't affect ongoing 9.0 release. With the
>assemble
>> > > task, Luke works just fine as before.
>> > >
>> > > Thanks,
>> > > Tomoko
>> > >
>> > >
>---------------------------------------------------------------------
>> > > 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

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
Re: A proposition: Make Luke a standalone package (again) [ In reply to ]
Thank you Uwe for the suggestion.
zip only distribution is fine to me, that would be preferable to
duplicating the same jars three times?

Tomoko

2021?5?29?(?) 20:27 Uwe Schindler <uwe@thetaphi.de>:
>
> Hi,
> Nö. Not by default.
>
> But: why not provide only zip? You can also add Unix chmod inside zip.
>
> Uwe
>
> Am May 29, 2021 10:27:12 AM UTC schrieb Robert Muir <rcmuir@gmail.com>:
>>
>> That scheme sounds fine to me. It is 2021, can windows deal with .tar.gz yet? :)
>>
>> On Sat, May 29, 2021 at 6:12 AM Tomoko Uchida
>> <tomoko.uchida.1111@gmail.com> wrote:
>>>
>>>
>>> Thank you Robert for your reply.
>>> For clarification, I think we will distribute a compressed tarball
>>> (and may be also a zip for Windows?) which contains luke JAR (the GUI)
>>> and its dependent JARs - not a fat or shaded jar. (I forgot to write
>>> the important details in the previous mail.)
>>>
>>> Tomoko
>>>
>>> 2021?5?29?(?) 12:37 Robert Muir <rcmuir@gmail.com>:
>>>>
>>>>
>>>> +1, it is an application. So let's package it in a way, so that it is
>>>> easy to run this application.
>>>> This is a bit different than packaging a library: different target
>>>> audience for example (developers vs. operations and other folks)
>>>>
>>>> Definitely +1 to give luke its own "artifact" that might work a bit
>>>> differently than the usual library artifacts. The most extreme might
>>>> be a kind of shaded application jar, very friendly to the common case,
>>>> but perhaps most hostile to expert cases (such as adding custom
>>>> analyzers and codecs to classpath). Maybe it's the right tradeoff
>>>> though, or something in between: seems like we can sort out those
>>>> details.
>>>>
>>>> On Fri, May 28, 2021 at 11:10 PM Tomoko Uchida
>>>> <tomoko.uchida.1111@gmail.com> wrote:
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> As a byproduct of LUCENE-9448, we now have a neat gradle task (thank
>>>>> you Dawid!) to assemble a standalone Luke package.
>>>>>
>>>>> I think it makes sense to distribute the standalone "Luke app" that
>>>>> contains only its executable-jar and minimum dependencies to run it,
>>>>> as it used to be, on Lucene download page (
>>>>> https://lucene.apache.org/core/downloads.html ).
>>>>>
>>>>> Pros:
>>>>> - Easy to understand for users who need it
>>>>> - No need to rely on strange hacks to discover dependencies (jars) for
>>>>> running it
>>>>>
>>>>> Cons:
>>>>> - Duplication of many jars (analyzers, queries, codec, etc.)
>>>>>
>>>>> I am sure it makes sense for long-term Luke users who used to just
>>>>> download Luke from the original or forked sites - but let me know if
>>>>> there is anyone who has thoughts (eg. from the aritifact maintainers'
>>>>> perspective) on it.
>>>>> If there is no objection/concern, I will explore what changes are
>>>>> required to do so on LUCENE-9978.
>>>>>
>>>>> Final note: It doesn't affect ongoing 9.0 release. With the assemble
>>>>> task, Luke works just fine as before.
>>>>>
>>>>> Thanks,
>>>>> Tomoko
>>>>> ________________________________
>>>>> 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
>>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: A proposition: Make Luke a standalone package (again) [ In reply to ]
Just like *nux can't handle .zip by default.

On Sat, May 29, 2021 at 7:26 AM Uwe Schindler <uwe@thetaphi.de> wrote:
>
> Hi,
> Nö. Not by default.
>
> But: why not provide only zip? You can also add Unix chmod inside zip.
>
> Uwe
>
> Am May 29, 2021 10:27:12 AM UTC schrieb Robert Muir <rcmuir@gmail.com>:
>>
>> That scheme sounds fine to me. It is 2021, can windows deal with .tar.gz yet? :)
>>
>> On Sat, May 29, 2021 at 6:12 AM Tomoko Uchida
>> <tomoko.uchida.1111@gmail.com> wrote:
>>>
>>>
>>> Thank you Robert for your reply.
>>> For clarification, I think we will distribute a compressed tarball
>>> (and may be also a zip for Windows?) which contains luke JAR (the GUI)
>>> and its dependent JARs - not a fat or shaded jar. (I forgot to write
>>> the important details in the previous mail.)
>>>
>>> Tomoko
>>>
>>> 2021?5?29?(?) 12:37 Robert Muir <rcmuir@gmail.com>:
>>>>
>>>>
>>>> +1, it is an application. So let's package it in a way, so that it is
>>>> easy to run this application.
>>>> This is a bit different than packaging a library: different target
>>>> audience for example (developers vs. operations and other folks)
>>>>
>>>> Definitely +1 to give luke its own "artifact" that might work a bit
>>>> differently than the usual library artifacts. The most extreme might
>>>> be a kind of shaded application jar, very friendly to the common case,
>>>> but perhaps most hostile to expert cases (such as adding custom
>>>> analyzers and codecs to classpath). Maybe it's the right tradeoff
>>>> though, or something in between: seems like we can sort out those
>>>> details.
>>>>
>>>> On Fri, May 28, 2021 at 11:10 PM Tomoko Uchida
>>>> <tomoko.uchida.1111@gmail.com> wrote:
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> As a byproduct of LUCENE-9448, we now have a neat gradle task (thank
>>>>> you Dawid!) to assemble a standalone Luke package.
>>>>>
>>>>> I think it makes sense to distribute the standalone "Luke app" that
>>>>> contains only its executable-jar and minimum dependencies to run it,
>>>>> as it used to be, on Lucene download page (
>>>>> https://lucene.apache.org/core/downloads.html ).
>>>>>
>>>>> Pros:
>>>>> - Easy to understand for users who need it
>>>>> - No need to rely on strange hacks to discover dependencies (jars) for
>>>>> running it
>>>>>
>>>>> Cons:
>>>>> - Duplication of many jars (analyzers, queries, codec, etc.)
>>>>>
>>>>> I am sure it makes sense for long-term Luke users who used to just
>>>>> download Luke from the original or forked sites - but let me know if
>>>>> there is anyone who has thoughts (eg. from the aritifact maintainers'
>>>>> perspective) on it.
>>>>> If there is no objection/concern, I will explore what changes are
>>>>> required to do so on LUCENE-9978.
>>>>>
>>>>> Final note: It doesn't affect ongoing 9.0 release. With the assemble
>>>>> task, Luke works just fine as before.
>>>>>
>>>>> Thanks,
>>>>> Tomoko
>>>>> ________________________________
>>>>> 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
>>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: A proposition: Make Luke a standalone package (again) [ In reply to ]
Thanks Robert.
(It seems that I have always used linux distributions that include zip
command...)

I did a rough calculation - If we provide both of TGZ and ZIP for
Luke, we'll add extra 44M + 44M = 88M bytes per our release on the
storage server (the package is just a collection of jars, so their
compression ratio seems to be very low in this case).

Tomoko

2021?5?29?(?) 21:21 Robert Muir <rcmuir@gmail.com>:
>
> Just like *nux can't handle .zip by default.
>
> On Sat, May 29, 2021 at 7:26 AM Uwe Schindler <uwe@thetaphi.de> wrote:
> >
> > Hi,
> > Nö. Not by default.
> >
> > But: why not provide only zip? You can also add Unix chmod inside zip.
> >
> > Uwe
> >
> > Am May 29, 2021 10:27:12 AM UTC schrieb Robert Muir <rcmuir@gmail.com>:
> >>
> >> That scheme sounds fine to me. It is 2021, can windows deal with .tar.gz yet? :)
> >>
> >> On Sat, May 29, 2021 at 6:12 AM Tomoko Uchida
> >> <tomoko.uchida.1111@gmail.com> wrote:
> >>>
> >>>
> >>> Thank you Robert for your reply.
> >>> For clarification, I think we will distribute a compressed tarball
> >>> (and may be also a zip for Windows?) which contains luke JAR (the GUI)
> >>> and its dependent JARs - not a fat or shaded jar. (I forgot to write
> >>> the important details in the previous mail.)
> >>>
> >>> Tomoko
> >>>
> >>> 2021?5?29?(?) 12:37 Robert Muir <rcmuir@gmail.com>:
> >>>>
> >>>>
> >>>> +1, it is an application. So let's package it in a way, so that it is
> >>>> easy to run this application.
> >>>> This is a bit different than packaging a library: different target
> >>>> audience for example (developers vs. operations and other folks)
> >>>>
> >>>> Definitely +1 to give luke its own "artifact" that might work a bit
> >>>> differently than the usual library artifacts. The most extreme might
> >>>> be a kind of shaded application jar, very friendly to the common case,
> >>>> but perhaps most hostile to expert cases (such as adding custom
> >>>> analyzers and codecs to classpath). Maybe it's the right tradeoff
> >>>> though, or something in between: seems like we can sort out those
> >>>> details.
> >>>>
> >>>> On Fri, May 28, 2021 at 11:10 PM Tomoko Uchida
> >>>> <tomoko.uchida.1111@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> As a byproduct of LUCENE-9448, we now have a neat gradle task (thank
> >>>>> you Dawid!) to assemble a standalone Luke package.
> >>>>>
> >>>>> I think it makes sense to distribute the standalone "Luke app" that
> >>>>> contains only its executable-jar and minimum dependencies to run it,
> >>>>> as it used to be, on Lucene download page (
> >>>>> https://lucene.apache.org/core/downloads.html ).
> >>>>>
> >>>>> Pros:
> >>>>> - Easy to understand for users who need it
> >>>>> - No need to rely on strange hacks to discover dependencies (jars) for
> >>>>> running it
> >>>>>
> >>>>> Cons:
> >>>>> - Duplication of many jars (analyzers, queries, codec, etc.)
> >>>>>
> >>>>> I am sure it makes sense for long-term Luke users who used to just
> >>>>> download Luke from the original or forked sites - but let me know if
> >>>>> there is anyone who has thoughts (eg. from the aritifact maintainers'
> >>>>> perspective) on it.
> >>>>> If there is no objection/concern, I will explore what changes are
> >>>>> required to do so on LUCENE-9978.
> >>>>>
> >>>>> Final note: It doesn't affect ongoing 9.0 release. With the assemble
> >>>>> task, Luke works just fine as before.
> >>>>>
> >>>>> Thanks,
> >>>>> Tomoko
> >>>>> ________________________________
> >>>>> 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
> >>
> >
> > --
> > Uwe Schindler
> > Achterdiek 19, 28357 Bremen
> > https://www.thetaphi.de
>
> ---------------------------------------------------------------------
> 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: A proposition: Make Luke a standalone package (again) [ In reply to ]
Yeah, given the sizes in question, .zip only seems like an ok tradeoff to me.
I always have to install zip on linux systems, but that's easy.
Also, since it's geared at java developers, .zip is ok, because if you
have java, then you can unzip: jar -xvf foo.zip :)

On Sat, May 29, 2021 at 9:10 AM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> Thanks Robert.
> (It seems that I have always used linux distributions that include zip
> command...)
>
> I did a rough calculation - If we provide both of TGZ and ZIP for
> Luke, we'll add extra 44M + 44M = 88M bytes per our release on the
> storage server (the package is just a collection of jars, so their
> compression ratio seems to be very low in this case).
>
> Tomoko
>
> 2021?5?29?(?) 21:21 Robert Muir <rcmuir@gmail.com>:
> >
> > Just like *nux can't handle .zip by default.
> >
> > On Sat, May 29, 2021 at 7:26 AM Uwe Schindler <uwe@thetaphi.de> wrote:
> > >
> > > Hi,
> > > Nö. Not by default.
> > >
> > > But: why not provide only zip? You can also add Unix chmod inside zip.
> > >
> > > Uwe
> > >
> > > Am May 29, 2021 10:27:12 AM UTC schrieb Robert Muir <rcmuir@gmail.com>:
> > >>
> > >> That scheme sounds fine to me. It is 2021, can windows deal with .tar.gz yet? :)
> > >>
> > >> On Sat, May 29, 2021 at 6:12 AM Tomoko Uchida
> > >> <tomoko.uchida.1111@gmail.com> wrote:
> > >>>
> > >>>
> > >>> Thank you Robert for your reply.
> > >>> For clarification, I think we will distribute a compressed tarball
> > >>> (and may be also a zip for Windows?) which contains luke JAR (the GUI)
> > >>> and its dependent JARs - not a fat or shaded jar. (I forgot to write
> > >>> the important details in the previous mail.)
> > >>>
> > >>> Tomoko
> > >>>
> > >>> 2021?5?29?(?) 12:37 Robert Muir <rcmuir@gmail.com>:
> > >>>>
> > >>>>
> > >>>> +1, it is an application. So let's package it in a way, so that it is
> > >>>> easy to run this application.
> > >>>> This is a bit different than packaging a library: different target
> > >>>> audience for example (developers vs. operations and other folks)
> > >>>>
> > >>>> Definitely +1 to give luke its own "artifact" that might work a bit
> > >>>> differently than the usual library artifacts. The most extreme might
> > >>>> be a kind of shaded application jar, very friendly to the common case,
> > >>>> but perhaps most hostile to expert cases (such as adding custom
> > >>>> analyzers and codecs to classpath). Maybe it's the right tradeoff
> > >>>> though, or something in between: seems like we can sort out those
> > >>>> details.
> > >>>>
> > >>>> On Fri, May 28, 2021 at 11:10 PM Tomoko Uchida
> > >>>> <tomoko.uchida.1111@gmail.com> wrote:
> > >>>>>
> > >>>>>
> > >>>>> Hello,
> > >>>>>
> > >>>>> As a byproduct of LUCENE-9448, we now have a neat gradle task (thank
> > >>>>> you Dawid!) to assemble a standalone Luke package.
> > >>>>>
> > >>>>> I think it makes sense to distribute the standalone "Luke app" that
> > >>>>> contains only its executable-jar and minimum dependencies to run it,
> > >>>>> as it used to be, on Lucene download page (
> > >>>>> https://lucene.apache.org/core/downloads.html ).
> > >>>>>
> > >>>>> Pros:
> > >>>>> - Easy to understand for users who need it
> > >>>>> - No need to rely on strange hacks to discover dependencies (jars) for
> > >>>>> running it
> > >>>>>
> > >>>>> Cons:
> > >>>>> - Duplication of many jars (analyzers, queries, codec, etc.)
> > >>>>>
> > >>>>> I am sure it makes sense for long-term Luke users who used to just
> > >>>>> download Luke from the original or forked sites - but let me know if
> > >>>>> there is anyone who has thoughts (eg. from the aritifact maintainers'
> > >>>>> perspective) on it.
> > >>>>> If there is no objection/concern, I will explore what changes are
> > >>>>> required to do so on LUCENE-9978.
> > >>>>>
> > >>>>> Final note: It doesn't affect ongoing 9.0 release. With the assemble
> > >>>>> task, Luke works just fine as before.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Tomoko
> > >>>>> ________________________________
> > >>>>> 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
> > >>
> > >
> > > --
> > > Uwe Schindler
> > > Achterdiek 19, 28357 Bremen
> > > https://www.thetaphi.de
> >
> > ---------------------------------------------------------------------
> > 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: A proposition: Make Luke a standalone package (again) [ In reply to ]
Luke standalone seems like a step in the right direction. There’s some
maintenance work on Luke to be done, though. What’s the process for
proposing those changes? Will it still be this email list?

On Sat, May 29, 2021 at 06:29 Robert Muir <rcmuir@gmail.com> wrote:

> Yeah, given the sizes in question, .zip only seems like an ok tradeoff to
> me.
> I always have to install zip on linux systems, but that's easy.
> Also, since it's geared at java developers, .zip is ok, because if you
> have java, then you can unzip: jar -xvf foo.zip :)
>
> On Sat, May 29, 2021 at 9:10 AM Tomoko Uchida
> <tomoko.uchida.1111@gmail.com> wrote:
> >
> > Thanks Robert.
> > (It seems that I have always used linux distributions that include zip
> > command...)
> >
> > I did a rough calculation - If we provide both of TGZ and ZIP for
> > Luke, we'll add extra 44M + 44M = 88M bytes per our release on the
> > storage server (the package is just a collection of jars, so their
> > compression ratio seems to be very low in this case).
> >
> > Tomoko
> >
> > 2021?5?29?(?) 21:21 Robert Muir <rcmuir@gmail.com>:
> > >
> > > Just like *nux can't handle .zip by default.
> > >
> > > On Sat, May 29, 2021 at 7:26 AM Uwe Schindler <uwe@thetaphi.de> wrote:
> > > >
> > > > Hi,
> > > > Nö. Not by default.
> > > >
> > > > But: why not provide only zip? You can also add Unix chmod inside
> zip.
> > > >
> > > > Uwe
> > > >
> > > > Am May 29, 2021 10:27:12 AM UTC schrieb Robert Muir <
> rcmuir@gmail.com>:
> > > >>
> > > >> That scheme sounds fine to me. It is 2021, can windows deal with
> .tar.gz yet? :)
> > > >>
> > > >> On Sat, May 29, 2021 at 6:12 AM Tomoko Uchida
> > > >> <tomoko.uchida.1111@gmail.com> wrote:
> > > >>>
> > > >>>
> > > >>> Thank you Robert for your reply.
> > > >>> For clarification, I think we will distribute a compressed tarball
> > > >>> (and may be also a zip for Windows?) which contains luke JAR (the
> GUI)
> > > >>> and its dependent JARs - not a fat or shaded jar. (I forgot to
> write
> > > >>> the important details in the previous mail.)
> > > >>>
> > > >>> Tomoko
> > > >>>
> > > >>> 2021?5?29?(?) 12:37 Robert Muir <rcmuir@gmail.com>:
> > > >>>>
> > > >>>>
> > > >>>> +1, it is an application. So let's package it in a way, so that
> it is
> > > >>>> easy to run this application.
> > > >>>> This is a bit different than packaging a library: different
> target
> > > >>>> audience for example (developers vs. operations and other folks)
> > > >>>>
> > > >>>> Definitely +1 to give luke its own "artifact" that might work a
> bit
> > > >>>> differently than the usual library artifacts. The most extreme
> might
> > > >>>> be a kind of shaded application jar, very friendly to the common
> case,
> > > >>>> but perhaps most hostile to expert cases (such as adding custom
> > > >>>> analyzers and codecs to classpath). Maybe it's the right tradeoff
> > > >>>> though, or something in between: seems like we can sort out those
> > > >>>> details.
> > > >>>>
> > > >>>> On Fri, May 28, 2021 at 11:10 PM Tomoko Uchida
> > > >>>> <tomoko.uchida.1111@gmail.com> wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>> Hello,
> > > >>>>>
> > > >>>>> As a byproduct of LUCENE-9448, we now have a neat gradle task
> (thank
> > > >>>>> you Dawid!) to assemble a standalone Luke package.
> > > >>>>>
> > > >>>>> I think it makes sense to distribute the standalone "Luke app"
> that
> > > >>>>> contains only its executable-jar and minimum dependencies to
> run it,
> > > >>>>> as it used to be, on Lucene download page (
> > > >>>>> https://lucene.apache.org/core/downloads.html ).
> > > >>>>>
> > > >>>>> Pros:
> > > >>>>> - Easy to understand for users who need it
> > > >>>>> - No need to rely on strange hacks to discover dependencies
> (jars) for
> > > >>>>> running it
> > > >>>>>
> > > >>>>> Cons:
> > > >>>>> - Duplication of many jars (analyzers, queries, codec, etc.)
> > > >>>>>
> > > >>>>> I am sure it makes sense for long-term Luke users who used to
> just
> > > >>>>> download Luke from the original or forked sites - but let me
> know if
> > > >>>>> there is anyone who has thoughts (eg. from the aritifact
> maintainers'
> > > >>>>> perspective) on it.
> > > >>>>> If there is no objection/concern, I will explore what changes
> are
> > > >>>>> required to do so on LUCENE-9978.
> > > >>>>>
> > > >>>>> Final note: It doesn't affect ongoing 9.0 release. With the
> assemble
> > > >>>>> task, Luke works just fine as before.
> > > >>>>>
> > > >>>>> Thanks,
> > > >>>>> Tomoko
> > > >>>>> ________________________________
> > > >>>>> 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
> > > >>
> > > >
> > > > --
> > > > Uwe Schindler
> > > > Achterdiek 19, 28357 Bremen
> > > > https://www.thetaphi.de
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
> --
Marcus Eagan
Re: A proposition: Make Luke a standalone package (again) [ In reply to ]
Hi,
at least we need to tweak the artifact assemble tasks and the download page.
I have opened LUCENE-9978 to investigate on what changes are required.

Tomoko

2021?5?30?(?) 3:11 Marcus Eagan <marcuseagan@gmail.com>:
>
> Luke standalone seems like a step in the right direction. There’s some maintenance work on Luke to be done, though. What’s the process for proposing those changes? Will it still be this email list?
>
> On Sat, May 29, 2021 at 06:29 Robert Muir <rcmuir@gmail.com> wrote:
>>
>> Yeah, given the sizes in question, .zip only seems like an ok tradeoff to me.
>> I always have to install zip on linux systems, but that's easy.
>> Also, since it's geared at java developers, .zip is ok, because if you
>> have java, then you can unzip: jar -xvf foo.zip :)
>>
>> On Sat, May 29, 2021 at 9:10 AM Tomoko Uchida
>> <tomoko.uchida.1111@gmail.com> wrote:
>> >
>> > Thanks Robert.
>> > (It seems that I have always used linux distributions that include zip
>> > command...)
>> >
>> > I did a rough calculation - If we provide both of TGZ and ZIP for
>> > Luke, we'll add extra 44M + 44M = 88M bytes per our release on the
>> > storage server (the package is just a collection of jars, so their
>> > compression ratio seems to be very low in this case).
>> >
>> > Tomoko
>> >
>> > 2021?5?29?(?) 21:21 Robert Muir <rcmuir@gmail.com>:
>> > >
>> > > Just like *nux can't handle .zip by default.
>> > >
>> > > On Sat, May 29, 2021 at 7:26 AM Uwe Schindler <uwe@thetaphi.de> wrote:
>> > > >
>> > > > Hi,
>> > > > Nö. Not by default.
>> > > >
>> > > > But: why not provide only zip? You can also add Unix chmod inside zip.
>> > > >
>> > > > Uwe
>> > > >
>> > > > Am May 29, 2021 10:27:12 AM UTC schrieb Robert Muir <rcmuir@gmail.com>:
>> > > >>
>> > > >> That scheme sounds fine to me. It is 2021, can windows deal with .tar.gz yet? :)
>> > > >>
>> > > >> On Sat, May 29, 2021 at 6:12 AM Tomoko Uchida
>> > > >> <tomoko.uchida.1111@gmail.com> wrote:
>> > > >>>
>> > > >>>
>> > > >>> Thank you Robert for your reply.
>> > > >>> For clarification, I think we will distribute a compressed tarball
>> > > >>> (and may be also a zip for Windows?) which contains luke JAR (the GUI)
>> > > >>> and its dependent JARs - not a fat or shaded jar. (I forgot to write
>> > > >>> the important details in the previous mail.)
>> > > >>>
>> > > >>> Tomoko
>> > > >>>
>> > > >>> 2021?5?29?(?) 12:37 Robert Muir <rcmuir@gmail.com>:
>> > > >>>>
>> > > >>>>
>> > > >>>> +1, it is an application. So let's package it in a way, so that it is
>> > > >>>> easy to run this application.
>> > > >>>> This is a bit different than packaging a library: different target
>> > > >>>> audience for example (developers vs. operations and other folks)
>> > > >>>>
>> > > >>>> Definitely +1 to give luke its own "artifact" that might work a bit
>> > > >>>> differently than the usual library artifacts. The most extreme might
>> > > >>>> be a kind of shaded application jar, very friendly to the common case,
>> > > >>>> but perhaps most hostile to expert cases (such as adding custom
>> > > >>>> analyzers and codecs to classpath). Maybe it's the right tradeoff
>> > > >>>> though, or something in between: seems like we can sort out those
>> > > >>>> details.
>> > > >>>>
>> > > >>>> On Fri, May 28, 2021 at 11:10 PM Tomoko Uchida
>> > > >>>> <tomoko.uchida.1111@gmail.com> wrote:
>> > > >>>>>
>> > > >>>>>
>> > > >>>>> Hello,
>> > > >>>>>
>> > > >>>>> As a byproduct of LUCENE-9448, we now have a neat gradle task (thank
>> > > >>>>> you Dawid!) to assemble a standalone Luke package.
>> > > >>>>>
>> > > >>>>> I think it makes sense to distribute the standalone "Luke app" that
>> > > >>>>> contains only its executable-jar and minimum dependencies to run it,
>> > > >>>>> as it used to be, on Lucene download page (
>> > > >>>>> https://lucene.apache.org/core/downloads.html ).
>> > > >>>>>
>> > > >>>>> Pros:
>> > > >>>>> - Easy to understand for users who need it
>> > > >>>>> - No need to rely on strange hacks to discover dependencies (jars) for
>> > > >>>>> running it
>> > > >>>>>
>> > > >>>>> Cons:
>> > > >>>>> - Duplication of many jars (analyzers, queries, codec, etc.)
>> > > >>>>>
>> > > >>>>> I am sure it makes sense for long-term Luke users who used to just
>> > > >>>>> download Luke from the original or forked sites - but let me know if
>> > > >>>>> there is anyone who has thoughts (eg. from the aritifact maintainers'
>> > > >>>>> perspective) on it.
>> > > >>>>> If there is no objection/concern, I will explore what changes are
>> > > >>>>> required to do so on LUCENE-9978.
>> > > >>>>>
>> > > >>>>> Final note: It doesn't affect ongoing 9.0 release. With the assemble
>> > > >>>>> task, Luke works just fine as before.
>> > > >>>>>
>> > > >>>>> Thanks,
>> > > >>>>> Tomoko
>> > > >>>>> ________________________________
>> > > >>>>> 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
>> > > >>
>> > > >
>> > > > --
>> > > > Uwe Schindler
>> > > > Achterdiek 19, 28357 Bremen
>> > > > https://www.thetaphi.de
>> > >
>> > > ---------------------------------------------------------------------
>> > > 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
>>
> --
> Marcus Eagan
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: A proposition: Make Luke a standalone package (again) [ In reply to ]
Thank you guys who involved here.

According to the conversation on this thread so far, the proposal
seemed to gain a some level of consensus. We would release standalone
Luke package as a zip archive (Windows-friendly format; *nix users may
live with it).

I did a little survey on the build script in lucene/packaging and the
ReleaseWizard script - the operations are done in a semi-automated
manner; so I hope we will publish the Luke artifact (and make an
announcement on the website) without adding any extra cumbersome
manual steps.
Nevertheless I'd like to delay this until 9.1 or above to avoid
introducing another layer of complexity for the major release. (I need
some time to get a clear picture of how the tools/scripts work,
anyway.)

Tomoko

2021?5?30?(?) 8:52 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>
> Hi,
> at least we need to tweak the artifact assemble tasks and the download page.
> I have opened LUCENE-9978 to investigate on what changes are required.
>
> Tomoko
>
> 2021?5?30?(?) 3:11 Marcus Eagan <marcuseagan@gmail.com>:
> >
> > Luke standalone seems like a step in the right direction. There’s some maintenance work on Luke to be done, though. What’s the process for proposing those changes? Will it still be this email list?
> >
> > On Sat, May 29, 2021 at 06:29 Robert Muir <rcmuir@gmail.com> wrote:
> >>
> >> Yeah, given the sizes in question, .zip only seems like an ok tradeoff to me.
> >> I always have to install zip on linux systems, but that's easy.
> >> Also, since it's geared at java developers, .zip is ok, because if you
> >> have java, then you can unzip: jar -xvf foo.zip :)
> >>
> >> On Sat, May 29, 2021 at 9:10 AM Tomoko Uchida
> >> <tomoko.uchida.1111@gmail.com> wrote:
> >> >
> >> > Thanks Robert.
> >> > (It seems that I have always used linux distributions that include zip
> >> > command...)
> >> >
> >> > I did a rough calculation - If we provide both of TGZ and ZIP for
> >> > Luke, we'll add extra 44M + 44M = 88M bytes per our release on the
> >> > storage server (the package is just a collection of jars, so their
> >> > compression ratio seems to be very low in this case).
> >> >
> >> > Tomoko
> >> >
> >> > 2021?5?29?(?) 21:21 Robert Muir <rcmuir@gmail.com>:
> >> > >
> >> > > Just like *nux can't handle .zip by default.
> >> > >
> >> > > On Sat, May 29, 2021 at 7:26 AM Uwe Schindler <uwe@thetaphi.de> wrote:
> >> > > >
> >> > > > Hi,
> >> > > > Nö. Not by default.
> >> > > >
> >> > > > But: why not provide only zip? You can also add Unix chmod inside zip.
> >> > > >
> >> > > > Uwe
> >> > > >
> >> > > > Am May 29, 2021 10:27:12 AM UTC schrieb Robert Muir <rcmuir@gmail.com>:
> >> > > >>
> >> > > >> That scheme sounds fine to me. It is 2021, can windows deal with .tar.gz yet? :)
> >> > > >>
> >> > > >> On Sat, May 29, 2021 at 6:12 AM Tomoko Uchida
> >> > > >> <tomoko.uchida.1111@gmail.com> wrote:
> >> > > >>>
> >> > > >>>
> >> > > >>> Thank you Robert for your reply.
> >> > > >>> For clarification, I think we will distribute a compressed tarball
> >> > > >>> (and may be also a zip for Windows?) which contains luke JAR (the GUI)
> >> > > >>> and its dependent JARs - not a fat or shaded jar. (I forgot to write
> >> > > >>> the important details in the previous mail.)
> >> > > >>>
> >> > > >>> Tomoko
> >> > > >>>
> >> > > >>> 2021?5?29?(?) 12:37 Robert Muir <rcmuir@gmail.com>:
> >> > > >>>>
> >> > > >>>>
> >> > > >>>> +1, it is an application. So let's package it in a way, so that it is
> >> > > >>>> easy to run this application.
> >> > > >>>> This is a bit different than packaging a library: different target
> >> > > >>>> audience for example (developers vs. operations and other folks)
> >> > > >>>>
> >> > > >>>> Definitely +1 to give luke its own "artifact" that might work a bit
> >> > > >>>> differently than the usual library artifacts. The most extreme might
> >> > > >>>> be a kind of shaded application jar, very friendly to the common case,
> >> > > >>>> but perhaps most hostile to expert cases (such as adding custom
> >> > > >>>> analyzers and codecs to classpath). Maybe it's the right tradeoff
> >> > > >>>> though, or something in between: seems like we can sort out those
> >> > > >>>> details.
> >> > > >>>>
> >> > > >>>> On Fri, May 28, 2021 at 11:10 PM Tomoko Uchida
> >> > > >>>> <tomoko.uchida.1111@gmail.com> wrote:
> >> > > >>>>>
> >> > > >>>>>
> >> > > >>>>> Hello,
> >> > > >>>>>
> >> > > >>>>> As a byproduct of LUCENE-9448, we now have a neat gradle task (thank
> >> > > >>>>> you Dawid!) to assemble a standalone Luke package.
> >> > > >>>>>
> >> > > >>>>> I think it makes sense to distribute the standalone "Luke app" that
> >> > > >>>>> contains only its executable-jar and minimum dependencies to run it,
> >> > > >>>>> as it used to be, on Lucene download page (
> >> > > >>>>> https://lucene.apache.org/core/downloads.html ).
> >> > > >>>>>
> >> > > >>>>> Pros:
> >> > > >>>>> - Easy to understand for users who need it
> >> > > >>>>> - No need to rely on strange hacks to discover dependencies (jars) for
> >> > > >>>>> running it
> >> > > >>>>>
> >> > > >>>>> Cons:
> >> > > >>>>> - Duplication of many jars (analyzers, queries, codec, etc.)
> >> > > >>>>>
> >> > > >>>>> I am sure it makes sense for long-term Luke users who used to just
> >> > > >>>>> download Luke from the original or forked sites - but let me know if
> >> > > >>>>> there is anyone who has thoughts (eg. from the aritifact maintainers'
> >> > > >>>>> perspective) on it.
> >> > > >>>>> If there is no objection/concern, I will explore what changes are
> >> > > >>>>> required to do so on LUCENE-9978.
> >> > > >>>>>
> >> > > >>>>> Final note: It doesn't affect ongoing 9.0 release. With the assemble
> >> > > >>>>> task, Luke works just fine as before.
> >> > > >>>>>
> >> > > >>>>> Thanks,
> >> > > >>>>> Tomoko
> >> > > >>>>> ________________________________
> >> > > >>>>> 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
> >> > > >>
> >> > > >
> >> > > > --
> >> > > > Uwe Schindler
> >> > > > Achterdiek 19, 28357 Bremen
> >> > > > https://www.thetaphi.de
> >> > >
> >> > > ---------------------------------------------------------------------
> >> > > 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
> >>
> > --
> > Marcus Eagan
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: A proposition: Make Luke a standalone package (again) [ In reply to ]
Is there any possibility that Luke could be sensitive to the version of
Lucene it's looking at? Luke 8.0 doesn't recognize a Lucene database that
is recognized by Luke 3.5.0, for example. Luke 3.5.0 says Index version
1791d04c61f, Index format 11 (Lucene 3.1).

Failing that, a list of the versions of Lucene that the current version of
Luke supports would be useful. It might also be useful to archive versions
of Luke that support versions of Lucene that the current version doesn't.

Thanks in advance for any guidance.

Cheers, Scott
Re: A proposition: Make Luke a standalone package (again) [ In reply to ]
Hi,

> Is there any possibility that Luke could be sensitive to the version of Lucene it's looking at? Luke 8.0 doesn't recognize a Lucene database that is recognized by Luke 3.5.0, for example. Luke 3.5.0 says Index version 1791d04c61f, Index format 11 (Lucene 3.1).

Yes, but this is not the limitation of Luke itself but comes from
Lucene's binary backwards compat policy. Lucene (and Luke) understands
index formats the current and the one before major version. (e.g.,
Lucene/Luke 8.x suppports only indexes that is created by Lucene 8.x
and 7.x.) I think it may be documented in somewhere but I don't know
where it is...

Tomoko

2021?6?5?(?) 20:55 Scott Guthery <sguthery@gmail.com>:
>
> Is there any possibility that Luke could be sensitive to the version of Lucene it's looking at? Luke 8.0 doesn't recognize a Lucene database that is recognized by Luke 3.5.0, for example. Luke 3.5.0 says Index version 1791d04c61f, Index format 11 (Lucene 3.1).
>
> Failing that, a list of the versions of Lucene that the current version of Luke supports would be useful. It might also be useful to archive versions of Luke that support versions of Lucene that the current version doesn't.
>
> Thanks in advance for any guidance.
>
> Cheers, Scott

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