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 <[email protected]> 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 <[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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
