Does it make sense to mention where to look for the jars Solr uses? Or maybe just where the “major components” live?
The problem is that even leaving out things like contribs and test, it’s still confusing: dist dist/solrj-libs server/solr-webapp/webapp/WEB-INF/lib server/lib > On Dec 24, 2019, at 12:44 PM, David Smiley <[email protected]> wrote: > > Somewhat bigger scope: > SOLR-14149 - Remove non-changes from CHANGES.txt > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, Dec 24, 2019 at 12:33 PM David Smiley <[email protected]> > wrote: > The "new features + upgrade notes in a single place" page in the ref guide > seems to me an odd place to put the current versions of major components. > Seems out of scope. > https://lucene.apache.org/solr/guide/8_4/solr-upgrade-notes.html > > > "I love “Solr System Requirements”" > > LOL > > This page, "solr-system-requirements.adoc" seems to me the right place to > specify ZooKeeper's current version. No need to mention Jetty; users don't > install that. > > I'll file a JIRA issue. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, Dec 24, 2019 at 12:19 PM Cassandra Targett <[email protected]> > wrote: > +1 to removing from CHANGES.txt, but I think we should really try to publish > them somewhere instead of asking people to look for .jars. > > If we were to go the way I’ve been advocating to go - to have a single page > in the Ref Guide for each release that includes the new features + upgrade > notes in a single place instead of two - it would be really trivial to > publish the versions for the major components on the same page. Most of them > already exist as Guide build parameters already, a single place would make it > less likely they're broken for 2 releases (thanks Jan for fixing that), and > it is very little effort to add new ones as needed. > > Cassandra > On Dec 24, 2019, 8:37 AM -0600, Erick Erickson <[email protected]>, > wrote: >> I started out strongly negative on this, since the idea of just looking at >> the jar file names presupposed you know _where_ to look in the first place. >> >> Then realized jar files are a mess, just ask Dawid. There are 272 jar files >> in the 8.3 distro, scattered all over the place. This may get better when we >> move to Gradle, but even then there will still be a lot of jar files. >> >> For instance, there are three copies of slf4j-api-1.7.24.jar in the distro, >> which one is important? At least they all have the same version so that’s >> something. >> >> ./dist/solrj-lib/slf4j-api-1.7.24.jar >> ./server/lib/ext/slf4j-api-1.7.24.jar >> ./contrib/prometheus-exporter/lib/slf4j-api-1.7.24.jar >> >> Zookeeper is in ./dist/solrj-lib/ and >> ./server/solr-webapp/webapp/WEB-INF/lib/. Which one is important? Which one >> is used? Which one should I use if I want to run an external Zookeeper? >> Gaaaaahhhhh. >> >> So the more I thought about it, the more I realized it’s just impossible to >> untangle that in the CHANGES.txt file, and the point of specifying which >> Tika version is well taken (why that and not others?). The only component >> that I think _shouldn’t_ be something a user needs to dig for is Zookeeper >> since we recommend that they install an external ensemble. And just putting >> Zookeeper in CHANGES.txt is awkward. >> >> For that matter, why to we specify the JVM in a different place in >> CHANGES.txt? That should be moved to a system-requirements page too IMO. I’d >> frankly rather go find the one place the relevant information is than >> reconcile multiple, possibly conflicting sources. >> >> So after dithering for far too long, +1 to rip this out of CHANGES.txt. We >> should take the JVM out of CHANGES.txt too. Let’s put this in a system >> requirements page in the ref guide and point to it from CHANGES.txt. I think >> we should just point here: https://lucene.apache.org/solr/guide/ which lets >> them pick the version of the ref guide rather than to a specific version on >> the theory that it’s one less thing to keep synchronized. Perhaps guiding >> them to look at “System requirements>>Solr System Requirements”. (and, BTW, >> I love “Solr System Requirements”, when I was working on the page I wanted >> to start with “start a few billion yeas ago with a lot of interstellar dust >> and gas and...”). >> >>> On Dec 24, 2019, at 6:56 AM, Jan Høydahl <[email protected]> wrote: >>> >>> Jetty version is printed early in the logs so should be easy to find if you >>> don’t want to check the sources. >>> >>> Looking in RefGuide for ZK version, there seems to be a bug, see >>> https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper >>> The variable ${org.apache.zookeeper.version} is not expanded in the >>> asciidoc… I opened https://issues.apache.org/jira/browse/SOLR-14146 >>> >>> Jan >>> >>>> 24. des. 2019 kl. 06:48 skrev David Smiley <[email protected]>: >>>> >>>> +1 to all that Jan; your response was very thoughtful. >>>> >>>> Except "Perhaps just keep Jetty version in CHANGES". Why? Since the WAR >>>> option went away, we now think of Jetty as a component of Solr instead of >>>> something we deploy to, at least in communication to our users. If an >>>> advanced user wants to mess with Jetty configuration, I'm sure he/she will >>>> figure it out. >>>> >>>> ~ David Smiley >>>> Apache Lucene/Solr Search Developer >>>> http://www.linkedin.com/in/davidwsmiley >>>> >>>> >>>> On Mon, Dec 23, 2019 at 5:59 PM Jan Høydahl <[email protected]> wrote: >>>> In the binary distro there is no version.properties... >>>> >>>> Perhaps just keep Jetty version in CHANGES? >>>> The Zookeeper version is useful if you want to choose an external ZK to >>>> install, but the refGuide should help here. >>>> Unfortunately we do not link to the Reference Guide from README in Solr >>>> binary download so that info is not readily available either. >>>> I think we should link to online ref-guide both from README and from >>>> online docs https://lucene.apache.org/solr/8_2_0/ >>>> Also, recommended ZK version for Cloud should be part of >>>> SYSTEM_REQUIREMENTS.txt, i.e. >>>> https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html ? >>>> >>>> Jan >>>> >>>>> 23. des. 2019 kl. 22:49 skrev David Smiley <[email protected]>: >>>>> >>>>> Our CHANGES.txt has "Versions of Major Components" as follows: >>>>> >>>>> Versions of Major Components >>>>> --------------------- >>>>> Apache Tika 1.23 >>>>> Carrot2 3.16.0 >>>>> Velocity 2.0 and Velocity Tools 3.0 >>>>> Apache ZooKeeper 3.5.5 >>>>> Jetty 9.4.24.v20191120 >>>>> >>>>> I think we should just eliminate this. Some of this stuff is really in >>>>> our contribs, and some of those will be ejected soon. But even for the >>>>> others, this sort of thing is pretty easy to figure out (e.g. >>>>> version.properties or simply *look* at the jar names). >>>>> >>>>> ~ David Smiley >>>>> Apache Lucene/Solr Search Developer >>>>> http://www.linkedin.com/in/davidwsmiley >>>> >>> >> >> >> --------------------------------------------------------------------- >> 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]
