If a dedicated issue for the stand-alone luke distribution is needed, I think this is the one: LUCENE-9978. I have not worked on this yet, since I thought it would be better to wait until the upcoming release is completed. I'm ready to start working on this, but it could/should be delegated to another issue with a much broader perspective.
Thanks, Tomoko 2021年10月12日(火) 16:19 Dawid Weiss <dawid.we...@gmail.com>: > > Thank you for the discussion. I think it'll be easier to take this > forward if presented with a concrete example of what a "binary" > release can look like, what Luke distribution is, etc. > > Let's start by completing the updates to how artifacts are assembled > and making the smoke tester work with these - this should be a low > hanging fruit opening > the possibility of a release. I would love to simplify the binary > artifacts but it can come as a logical next step once we have the > release infrastructure working > on the current main. > > Dawid > > On Tue, Oct 12, 2021 at 2:27 AM Robert Muir <rcm...@gmail.com> wrote: > > > > Well there's definitely a good reason to stop publishing convenience > > binaries: they aren't required. > > > > Lucene is a library. > > > > I think it makes sense to publish convenience binaries for the luke > > App, that's it. > > > > Otherwise, we should publish just source code, that's all that is required. > > Library users want to use build systems like gradle and maven, so we > > should put the classfiles there too. > > > > But there's zero requirement to make zips and tgzs of .class files and > > 3rd party libs up on the website. zero. and if no one is using them, > > we should stop doing it. > > > > Instead i'd rather focus on testing of what counts (e.g. do those jar > > files going to maven have included javadocs so it works well in the > > IDE?). These aspects are more important for a library. > > > > On Mon, Oct 11, 2021 at 8:21 PM Jan Høydahl <jan....@cominvent.com> wrote: > > > > > > +1 to all suggestions. > > > > > > ASF has a release policy > > > (https://www.apache.org/legal/release-policy.html#release-distribution) > > > and artifacts must be uploaded to the mirrors. > > > There is also a release distribution policy > > > (https://infra.apache.org/release-distribution.html#download-links) that > > > says > > > > > > "The website documentation for any Apache product must provide public > > > download links where interested parties may obtain current official > > > source releases and accompanying cryptographic files." > > > > > > So I see no reason to stop publishing binary convenience releases in the > > > apache mirrors, although few will use that channel. > > > > > > Jan > > > > > > 12. okt. 2021 kl. 01:55 skrev Tomoko Uchida > > > <tomoko.uchida.1...@gmail.com>: > > > > > > For what it's worth, I did a little survey on how other > > > library/sdk/framework projects distribute their artifacts other than > > > Maven repositories. > > > > > > - Log4j distributes tgz and zip artifacts via the "Download" page. > > > https://logging.apache.org/log4j/2.x/download.html > > > > > > - JavaFX distributes only zip artifacts via the "Download" page > > > https://gluonhq.com/products/javafx/ > > > > > > - Jersey has a "Download" page but it is actually a facade to Maven > > > Central. > > > https://eclipse-ee4j.github.io/jersey/download.html > > > > > > - JUnit5 has no "download" page > > > https://junit.org/junit5/ > > > > > > - Spring has no "download" page (as far as I know) > > > https://spring.io/projects/spring-framework > > > > > > - Jackson has no "download" page (github repo also serves as their > > > documentation). > > > https://github.com/FasterXML/jackson-core > > > > > > They are only small examples, but it seems to me that recent or > > > recently renewed projects would tend to have no explicit "download" > > > page at all. (?) > > > I'm not sure there are any ASF rules or policies about that. > > > > > > Tomoko > > > > > > 2021年10月11日(月) 21:59 Robert Muir <rcm...@gmail.com>: > > > > > > > > > +1 overall, comments inline. > > > > > > On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss <dawid.we...@gmail.com> wrote: > > > > > > > > > Hi. > > > > > > These are the thoughts that occurred to me while rewriting the > > > packaging in the build system. I think they're worth the discussion > > > because they could limit the size of the published artifacts as well > > > as their perceptive quality. > > > > > > 1. Who is going to use the lib/*.jar files we distribute in binary > > > releases? I don't think they are useful for anything. The dependency > > > information for modules is stored in maven POMs (and can be easily > > > written to text files, if it's really something people are dying to > > > preserve). > > > > > > > > > +1 > > > > > > > > > I don't think redistributing those JARs makes any sense other than to > > > make Luke work... What I would suggest is to remove third-party JARs > > > entirely from the binary distribution and have a separate binary > > > artifact with a fully functional top-level Luke application. > > > Alternatively, move those third-party JARs to the top-level > > > /thirdparty folder and Luke can access them from there. > > > > > > > > > +1, I think there is already an issue open to give luke its own > > > "release artifact" > > > > > > > > > 2. Some of the *.txt files both at the top-level and inside subfolders > > > contain obsolete information. We should at least re-read these. My > > > personal opinion is that some of the README.txt files inside modules > > > have little practical use - their content should go inside the javadoc > > > (package level, perhaps) and this should be the only source of > > > documentation. > > > > > > > > > +1, either nuke it, or fold it into javadoc, or at the very least > > > rename to README.md > > > > > > > > > 3. I would remove the "zip" binary distribution. I'm on Windows myself > > > so tgz is a tad more difficult to work with but Lucene is a library. > > > If somebody downloads a binary distribution they should know how to > > > unpack a tgz file (cygwin, total commander, whatever else). > > > > > > > > > +1 > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
