I'm sorry you're having a "miserable" experience "again". That's certainly not my experience with Solr. That being said:
> First I was getting errors about "Unsupported major.minor version 52.0", so I > needed to install the Linux x64 JRE 1.8.0, which I managed on CentOS 6 with... > yum install openjdk-1.8.0 This is not a Solr problem. Solr requires Java 8. Java 7 has been officially end-of-lifed since april 2015. This means no more patches, no more performance improvements and no more security updates (unless you're paying Oracle). This is clearly stated in the (very decent) Solr documentation. To use your own words: Java 7 is an antiquated nightmare and the rest of the world has moved on to Java 8. > So far so good. But I didn’t have JAVA_HOME set properly apparently, so I > needed to do the not-exactly-intuitive… > export > JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el6_8.x86_64/jre/ You don't need to set JAVA_HOME to run Solr. But if you do have a JAVA_HOME environment variable, and it points to a wrong Java version, you're going to have a bad time. > Then after stopping the old process (with kill -9, since there seems to be no > graceful way to shut down Solr) There's a stop command, which is documented. It's a non-surprising location and has a non-surprising name. And even if there wasn't, "kill" would have sufficed. > There was some kind of problem with StopFilterFactory and the text_general > field type. Thanks to Stack Overflow I was able to determine that the > apparent problem was that there was a parameter, previously fine, which was > no longer fine. So I removed all instances of > enablePositionIncrements="true". That helped, but then I ran into a broader > error: "Plugin Initializing failure for [schema.xml] fieldType". It didn’t > say which field type. Buried in the logs I found a reference in the Java > stack trace—which *disappears* (and distorts the viewing window horribly) > after a few seconds when you try to view it in the web log UI—to the string > "units="degrees"". Sure enough, this string appeared in my schema.xml for a > class called "solr.SpatialRecursivePrefixTreeFieldType" that I’m pretty sure > I never use. I removed that parameter, and moved on to the next set of errors. Releases come with release notes and -- when required -- upgrade instructions and admonitions. It's certainly possible that there's been an oversight here or there and you're more than welcome to point those out. > The user interface is still as buggy as an early alpha of most products, the errors are difficult to understand when they don’t actually specify what’s wrong (and they almost never do), and there should have been an automatic process to highlight and fix problems in old (pre-6) configuration files. What user interface? Are you talking about the Admin UI? That's a convenience feature which helps you manage Solr. It makes life a lot easier, even if it's not perfect. The logs are generally quite good at explaining what's wrong. > Never mind the fact that the XML-based configuration process is an antiquated nightmare when the rest of the world has long since moved onto databases. An antiquated nightmare? The rest of the world? How would this work? What benefit would it possibly have? You're more than welcome to report any bugs you find (https://issues.apache.org/jira/browse/SOLR). But I feel like general ranting on the mailing list isn't very productive. Well, I suppose venting feels good, so there's that. Things that would be more productive: 1. Reading the documentation. 2. Taking a basic system administration class or two. 3. Pointing out -- or contributing to -- parts of the documentation that aren't up to par. Either on the mailing list, or on Jira. Preferably in a constructive way instead of a "miserable experience"-way. I feel like you're missing the part where most open source development, documentation, release management etc is done by volunteers. Volunteers who tend to scratch their own itch first, and are then kind enough to donate the fruit of their labour to the rest of the world. You can certainly make requests, and you can certainly hope for things to improve. If you're having a "miserable" time "again", then you can always hire a Solr consultant to do the work for you. You can't demand free stuff to scratch your every itch. You can either invest your time and figure out how to do things yourself, or your money and have things done for you. But there's no such thing as a free lunch. - Bram
