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
