Hello XWiki devs, I've been playing a bit to adapt the xwiki lucene plugin, actually the curriki lucene plugin which is very similar, to the tastes of Intergeo. One thing that surprised me is that most of the fields in the lucene plugin are stored fields. This sounds like a big overkill when you think that all the values of the fields of a document are loaded when you have this document as match. Not surprisingly, the curriki search result was almost only using fullname, using lucene directly is somewhat faster, I think it's good practice. Could this be configurable? (i.e. the names of the fields that are stored) One powerful way to make it configurable would to migrate to solr which bases on lucene but uses a schema that describes well type of the fields. Three other pluggeabilities I would wish: - the search-result class really would wish to be subclassable, the configuration could define a search-result-factory or something such which would help (a lot) as a cursor exploiting the hits list - I deem it very important to also have query expansion but maybe that can be inside the rest of the application - what is indexed how should also be subclasses (a pluggeable factory for ObjectData?) Finally, I wanted to use different analyzers per language, using the Snowball family of analyzers so that stemming really does happen. I kind of have it now but I would like to test it in unit tests and, well... how can I do that? Is there a way to get a "unit-test xwiki environment" (context, xwiki) where my unit tests would create a few documents then query them? Is there active work on this plugin? Which patch is most interesting for the others? paul