We actually have something even better than an XML descriptor coming down the pipe.
A programmatic configuration API. Check it out http://in.relation.to/Bloggers/HibernateSearch32ProgrammaticMappingAPI
Supporting other engines than Lucene is not really in the roadmap. The problem is that engines do not share any standard. Unlike SQL, full-text search is in its infancy. That being said, I think it is possible to support Solr but someone will have to contribute that work: we have no immediate plan on that.
I am not sure why we are forcing you to use inheritance. Fancy explaining?
I'm not surprised that plugging into other engines would be tricky. I wasn't sure if there was some sort of standard out there but not surprised to hear there isn't. No problem.
The fluent configuration is nice and will be helpful but a configuration file would also be nice. We're starting to use Spring and I'm no expert but I'm hearing that to autowire object together it's easier to use configuration files to configure objects and then have Spring wire them together. As I said I'm no exert at Spring but that is the direction we're heading. Also, I'm not sure if the fluent configuration will help us with the inheritance problem.
As for the inheritance problem we're trying to abstract our Infinfispan implementation behind a set of interfaces to make it the API more domain specific, allow for easy upgrades to the latest Infinspan version, and allow for other changes without affecting our mainline code.
To do this we've created an interface layer and some base implementations (non Infinispan specific). The only way to get the objects to be queryable is to use the annotations and we don't want to use implementation specific code/annotations at the generic level so therefore we needed to introduce another layer that has those annotations. We can't encapsulate these or use other techniques since when an object is added to a cache it's directly added to the index and therefore needs to be annotated.
If this could be configured say in XML we could point to the interface methods we'd like to use for indexing and all instances of those interfaces would be queryable.
Anyhow, this is specific to our implementation but does cause us a bit of grief (nothing we haven't been able to fix) so I was just checking.