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