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 <[email protected]>: > > Just like *nux can't handle .zip by default. > > On Sat, May 29, 2021 at 7:26 AM Uwe Schindler <[email protected]> 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 <[email protected]>: > >> > >> 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 > >> <[email protected]> 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 <[email protected]>: > >>>> > >>>> > >>>> +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 > >>>> <[email protected]> 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: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>> ________________________________ > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>> ________________________________ > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> ________________________________ > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > -- > > Uwe Schindler > > Achterdiek 19, 28357 Bremen > > https://www.thetaphi.de > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
