In Solr land we can quickly hack something together, spend some time thinking about the external HTTP interface, and immediately make it available to users (those using nightlies at least). It would be a huge burden to say to Solr that anything of interest to the Lucene community should be pulled out into a module that Solr should then use. As a separate project, Solr is (and should be) free to follow what's in it's own best interest.
[...] > For example, Solr would presumably prefer that trie* remain in contrib? >From a capabilities perspective, it doesn't matter much if it's in contrib or core I think. It's a small amount of work to adapt to class name changes, but nothing to complain about. But it doesn't seem like Trie should be treated specially somehow... seems to go down a path that makes customer provided filters second-class citizens. I hate it when Java does stuff like that to me (their provided classes can do more than mine). > There's a single set of Solr developers, but a very wide range of > direct Lucene users. I don't see how Lucene having good consumability > actually makes Solr's life harder. Those raw APIs would still be > accessible to Solr... simple things should be simple (direct Lucene > users) and complex things should be possible (Solr). But with changes come deprecations - forced changes when the deprecations are removed. Sometimes those are easy to adapt to, sometimes not. If those required changes don't actually add any functionality to Solr, it's a net negative if you're looking at it from Solr's point of view. That doesn't mean Lucene shouldn't - and I've not complained to Lucene in the past because it wasn't Lucene's responsibility. [...] >> and taking it out of Solr's release cycle and easy ability to change - >> if Solr needs to make a change to one of the moved classes, it's >> necessary to get it through the Lucene change process and then upgrade >> to the latest Lucene trunk - all or nothing. > > "Getting through Lucene's change process" should be real simple for > you all :) Y'r kidding, right? ;-) It's sometimes hard enough to get stuff through either community, let alone both. For code that's in Solr, we only have to worry about Solr's concerns, not about all users of Lucene. Big difference. > And, Solr upgrades Lucene's JAR fairly often already? And a lot of our users don't like it. It's also become much more difficult due to all the Lucene changes lately. It's something we should be doing less of, not more of.... unless we formally merge the projects or something ;-) > NumericField would enforce one token, during indexing. That only changes the point at which the user realizes "uh, this won't work", and it's still at a point after they've written their code. Checking like this doesn't even feel like it belongs at the indexing level. -Yonik http://www.lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
