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]
