I'm fine with just Lucene binaries, signed JARs and checksums + pre-rendered documentation for convenience purposes.
> 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, You can install the artifacts locally (~/.m2 - gradlew mavenToLocal) or just assemble them in a release build folder (the pending patch). I think this should be enough for experiments? D. On Tue, Oct 12, 2021 at 10:42 AM Uwe Schindler <[email protected]> wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
