Include elevate.xml and other required config files

I couldn't get solr 3.6.2 to start without the following files:

1. elevate.xml
2. protwords.txt
3. stopwords.txt
4. mapping-ISOLatin1Accent.txt
5. synonyms.txt

We really should include these files in the solr-conf/3.x folder.

Experiencing same issue.
At first I thought removing solrcore.properties and the replication requestHandler would be enough, but those files are referenced from multiple points in the solrconfig.xml

The required files are distributed with Solr, in example/solr/conf, so I don't think this problem is that pressing. However, it's of course possible it would be better to include them in the module. Or maybe placing a note in the INSTALL.txt?

Yeah, at the very least it needs to be noted somewhere obvious.

Using the example files is not recommended since they have dummy/example settings. So you want to customize or remove them unless you want searches for iPods and "foo bar" and such to perhaps act differently from what you expect.
Solr works fine without those files with the default solrconfig.xml

But since the provided solrconfig.xml does require them and the provided solrcore.properties even explicitly demands them I feel they should be either be provided (empty of example content) or be made optional.

I'm moving this to the Common Configurations project, which is where we should probably change this.

I agree with you, the required config files should be packaged with the module, and not include (active, i.e., not out-commented) example settings. I just checked, for Solr 4.x you can't start the server without elevate.xml, stopwords.txt, synonyms.txt and mapping-ISOLatin1Accent.txt. We should really make those optional or include them in this project (and, subsequently, in our respective modules).

Attached is a patch which would add those, along with (I hope) reasonable defaults and a bit of documentation.

Nick? Peter? Any opinions on this?

Hmm, this adds a bit of overhead when Solr decides to update those files but I suppose we could add it to the set of files we require.

Ever since I started working on the apachesolr modules there was a description in the readme.txt to copy the files from drupal in the solr core and you have to make sure you copy the default files also in that solr core.

+++ b/conf/3.x/elevate.xmlundefined
@@ -0,0 +1,47 @@
+ directory, it will be re-loaded every commit.

reloaded can be one word I think? I actually did not realize that if it was present in the data dir it would reload.

Hmm, this adds a bit of overhead when Solr decides to update those files but I suppose we could add it to the set of files we require.

What do you mean? You mean when the format changes? Or just the default ones?
I think in the latter case ours could just stay the same, nearly all of them are empty anyways. The only one that could possibly use improvements from the default file is the mappings file.

Ever since I started working on the apachesolr modules there was a description in the readme.txt to copy the files from drupal in the solr core and you have to make sure you copy the default files also in that solr core.

Ah, you're right, wasn't aware of that. I guess explicitly mentioning this in the documentation files would be a solution, too, yes.
However, additionally providing ready-made ones with the modules would be better, in my opinion. Especially since the ones in Solr's example config have some dummy settings in there which could be annoying in a production environment, at least to a small degree.

I actually did not realize that if it was present in the data dir it would reload.

I was surprised, too, but it clearly says so in the default elevate.xml file. In fact, I just copy-pasted that part – that's also where the peculiar spelling of "reload" originates. We could of course change that, if you want.

Talked with Peter about this and he says it is more an issue of licensing. We could add empty files but then people would install the wrong files. GPL license and Apache licensed files might be a problem.

Stopwords could easily be emptied, same with elevate.xml (so do not include the apache license) but the problem is the character mapping document which is not so easily emptied. Perhaps we need to contact the Solr community to get closure for this.

I'm pretty sure the Apache license should be compatible with GPL, and this site by the ASF suggests the same. But of course you could also contact some professional about it, or otherwise ask around. I understand that you should be careful with such legal problems.

OK, I have to correct my previous statement: it seems that it won't be possible after all to include Apache-licensed files into Drupal.org projects. The problem is that the Apache license is compatible with GPLv3, but not with GPLv2. And since Drupal.org mandates that everything has to be released under GPLv2-or-later, this is a no-go.
(Source: This comment by Crell.)

So, here is a revised patch with all of the ASF's intellectual property removed, plus instructions that you should use the mapping-ISOLatin1Accent.txt file from Solr's example application.
Could we please add that?

And again, without the whitespace errors.

Committed. A bit annoying we couldn't copy the files but better to be safe :)