Hi, I full agree with most of the things here. Now that Solr is no longer part of Lucene, I also see no reason to have all dependencies and JAR artifacts in a TAR file!
On the other hand, binary artifacts makes reviewing the artifacts easier during a release. I am one of the persons that not only instructs policeman Jenkins to run the smoketester, I also download the artifacts and review JAR files (META-INF, completeness) and Javadocs. If we no longer have a binary release, we must also publish the javadocs of the release on the nightlies server for quick review! Maybe we can push the javadocs/documentation to apache servers before release (into a different directory name on the ASF webserver subversion server, when the release is done just "svn mv"). Without a binary release it's also harder to do a quick test with the JAR files, because they are not yet on Maven Central, so for testing one would need to make a maven project with a remote repository pointing to the staging are. There are workarounds for that, maybe we should make a script in the smoketester utilities that quickly sets up a maven project with the staging repository so you can drop in your "tryout code" and do a quick check. So I am not fully happy to completely throw away binary artifacts. Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Robert Muir <[email protected]> > Sent: Tuesday, October 12, 2021 2:27 AM > To: [email protected] > Subject: Re: Simplify the release artifacts > > 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]
