Re: [infinispan-dev] some thoughts on mutual dependencies in Query/Search

While reviewing ISPN-200 it's clear that Israel needed to copy over some code from Hibernate Search in Infinispan Query, to make some small changes to internal classes; All the changes I spotted so far are around making some objects serializable. I don't want to keep these copies around, especially as we're talking about very core and complex classes as org.hibernate.search.query.engine.impl.HSQueryImpl, which is not going to be maintainable in a forked situation, and definitely not meant for consumption by other projects. So I have some options: 1) I change the HSQueryImpl in Search to make it serializable, porting Israel's patches "upstream". 2) Create an externalizer in Infinispan Query which knows about the internals of HSQueryImpl

Clearly the Externalizer solution is highly coupled to the specific version of Search, so that might become another issue in maintaining them aligned, and this is not the appropriate class to be bound to a "serialization contract", but is also the recommended way according to Infinispan's spirit (compared to make it Serializable).

We could add a submodule in Hibernate Search to specifically test that the Query module is not going to break, but this is going to create a dangerous embrace in the release cycles of the two projects. I'm starting to wonder if Query shouldn't live in the Hibernate Search repository: it's highly coupled to Search, but nicely decoupled from Infinispan as it depends on it's public API (so still subject to be broken by changes in Infinispan, but that would be considered a bug in Infinispan).

It is of course possible to polish the Search APIs more to make sure that it's also nicely decoupled from it, but it's harder to achieve; specifically by the very recurrent need to serialize/marshal it's objects, or specific Lucene classes. Hibernate Search has always been compatible with a specific version of Lucene only, as this API is in continous flux too, so one of the goals of the project is to "shield" users from the breaking changes which are often introduced; to be conidered as well: most classes in Lucene are not serializable, or even if they are it's a deprecated feature and the maintainers are not interested in keeping wire compatibility. of course in the short term it's easy to make those classes serializable, or not even needed just defining an externalizer. So I think we should start with one of these while this complex contribution takes shape, but also consider options for near-future.