+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] >
