[ http://issues.apache.org/jira/browse/SOLR-73?page=comments#action_12454142 ] Hoss Man commented on SOLR-73: ------------------------------
The problem with eliminating the alias completley is that it could lead to confusion when people go to impliment their own classes and run into problems ... people are more likely to impliment their own Filters as packageless classes then they are to put them in a "solr.*" package ... so if someone says 'class="SynonymFilterFactory"' expecting to use their own custom class that deals with Synonyms some special way, but they don't put their code into the classpath properly then they'd wind up getting the o.a.s.a.SynonymFilterFactory instead and not understand why it works, but doesn't work as they expect. I was a little weirded out by the aliasing when Yonik first pointed it out... http://www.nabble.com/Re%3A--Solr-Wiki--Update-of-%22AnalyzersTokenizersTokenFilters%22-by-YonikSeeley-tf1111051.html#a2909046 ...but he's right, it makes the configs a *lot* easier to read and deal with. Would people feel better if we had some sort of '<packageAlias alias="solr">org.apache.solr.analysis</packageAlias>' type directives in both files so that it was less magic and more explicit? > schema.xml and solrconfig.xml use CNET-internal class names > ----------------------------------------------------------- > > Key: SOLR-73 > URL: http://issues.apache.org/jira/browse/SOLR-73 > Project: Solr > Issue Type: Bug > Components: search > Reporter: Walter Underwood > > The configuration files in the example directory still use the old > CNET-internal class names, like solr.LRUCache instead of > org.apache.solr.search.LRUCache. This is confusing to new users and should > be fixed before the first release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
