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 <[email protected]>: > > 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]
