[ http://issues.apache.org/jira/browse/SOLR-73?page=comments#action_12454198 ] Hoss Man commented on SOLR-73: ------------------------------
> but the issue would be the same if I was a non-programmer adding some simple > plug-ins. If you were a non-programmer why would you care about the package name? ... it would just be a string, and the place you found out about the plugin (be it a sample config, or a wiki, or some third party sourceforge project cranking out Solr Filters) would have give you the schema.xml snippet you would need to use that plugin ... you wouldn't care if it was net.sourceforge.solrextras.CoolExtraFilterFactory or solr.CoolBuiltInFactory ... you only felt like there was ambiguity because as a Java programmer you recognized a Java classname but you didn't recognize what you expected to be the java package name... right? I agree with the sentiment that having good documentation for a crappy product doesn't make the product better -- but I don't exactly think that's the situation we are in ... we're talking about a good product (in my opinion) with a lot of usefull little features that make it easier to use (like this package aliasing) that aren't documented well -- we shouldn't yank a feature just because it would make the product easier to understand if it would also make the product harder to use. If eliminating the ambiguity is the primary concern, we could do that by saying that all "class" refrences in the configs map to a single package name, so <filterCache class="XXX"> unambiguiously refers to org.apache.solr.plugin.XXX and <filter class="YYY"> unambiguisly refers to org.apache.solr.plugin.YYY ... which would eliminate the ambiguity, and make the configs very easy to read for non programmers, at the expense of constraining plugin developers -- but i don't think many people would argue that it would make Solr "better" I still view this as an issue of documentation -- we really have no "official" documentation on configuring Solr, all we have is some examples and some wiki pages -- our only official documentation is the tutorial. But if people really don't believe that this is a usefull feature that just happens to be lacking documentation, my next choice would be to change the feature to make it more explicitly controlled -- not remove it completely. > 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
