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 <[email protected]> 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 <[email protected]> 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 <[email protected]>: > > > > 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 <[email protected]>: > > > > > > +1 overall, comments inline. > > > > On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss <[email protected]> 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: [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]
