[hibernate-dev] Hibernate Search 5: heavy refactoring in progress!

[Sanne Grinovero]

And update regarding:
https://github.com/Sanne/hibernate-search/compare/evolveLucene4

In case you've been poking around in the first iterations, it seemed
we would break a good amount of user code. That's no longer true, and
it looks like we could deliver a same-features & same-API release, at
least when evaluating strictly *our* public API.
Some deprecations are in place, and some SPIs had to change slightly.

Regarding the Lucene code itself, it is definitely going to affect end
users, as some of these are "expert" but some others are probably used
by everyone (like sorting).
- Sorting API changed
- Similarity is different
- Analyzers and Tokenizer: if you have custom ones, you basically have
to rewrite them
- Filters: some simple changes needed
- Solr analyzer framework: unfortunately this is a non-typesafe
breaking change: properties passed to the various Analyzer components
have different names, and if you happen to use the old ones it will
throw a runtime exception with a not-too-helpfull message.
- NumericField: Lucene's API is totally different; user is "safe" if
he uses our annotations but will be affected in custom FieldBridge
implementations
- Queries: the API to create range queries, numeric queries,... is all
different. DSL users are safe.
- Boost at Document level is no longer available: we can reimplement
it by applying to all fields, but the rules are tricky :) If we want
to do that, it's a complex refactoring.
- Document API is different, as is reading of Field

The good news:
 - stuff like FieldCache, FieldSelector, Collectors, etc.. are
significantly different but we can provide all the same functionality
with no API impact as we did a good job at hiding this functionality.
I had to rewrite most of our code but it wasn't too tricky.
 - Spatial, Faceting, etc.. all migrated without too much pain.

The serialization code will need to be rewritten; not only did
Lucene's API change, but also several things which where simply
"serializable" before (think of Fields content and options) are no
longer easily serialized.

Not too bad? (but I'm not done yet)