[hibernate-dev] [SEARCH] Integration of Mincong's work on adding JSR-352 support

[Yoann Rodiere]

Hello,

Following our recent (and successful) efforts to fix blocking issues on
https://github.com/mincong-h/gsoc-hsearch/, I recently added a branch on my
repo which contains the Hibernate Search codebase, with the addition of a
JSR-352 submodule. You can find the branch at [1]. The build is working
just fine ([2]).

I tried to preserve as much metadata as possible when building this branch,
without keeping a long list of commits that would probably do more harm
than good. Basically I squashed commits and put the git log of the squashed
commits in the commit's comment. I tried to preserve authorship and
approximate dates, so git blame will still be useful.

If this branch seems acceptable to everyone, we can start working on
further polishing the JSR-352 integration, and eventually merge it. Below
are the next few steps to discuss.

# What's left to do

The full list of remaining issues can be found on the original repo [3]. I
marked as "Blocker" those issues that seem unacceptable in a release.

To sum up:

   - we have some APIs that will need further refining (just a few);
   - we basically don't have any documentation (there is a start, but it's
   already obsolete);
   - we lack some tests, most notably integration tests with other
   implementations than JBeret;
   - composite IDs are not supported correctly;
   - there are performance issues (or at least there were last time we
   checked);
   - failure recovery doesn't seem to be implemented correctly (uses
   AddLuceneWork instead of UpdateLuceneWork for the failing partition);
   - there are still questions about how transaction timeouts should be
   handled.

# Organization

I'd like to avoid merging the branch to master as long as the module isn't
ready. Here's why:

   1. The module isn't ready for prime-time yet (see above)
   2. The module is only loosely tied to Hibernate Search, in a few very
   specific portions of the code, so rebasing it shouldn't be hell. And it'll
   probably be me doing it anyway ;)

So think we should leave the code where it is now (a branch on my repo, see
[1]) and manage pull requests there.

About CI, Travis is working just fine for me, and since we're working on an
additional module the changes we make shouldn't have any impact on the
core. So I don't think setting up a job on ci.hibernate.org is required yet.

Regarding the tickets, I would create issues in our JIRA based on the
existing GitHub issues in the original repo. Probably make them sub-tasks
of HSEARCH-2594 [4]. I'll work on this later this week if nobody is against
it.

As to the planning, I'd say our problem isn't so much the amount of work
(there shouldn't be much more than 2 or 3 man-weeks remaning) than the
amount of time we can put into it.
Mincong isn't studying anymore and has a full-time job; however, he
generously proposed to work on this during his week-ends. But it obviously
wouldn't be reasonable to expect him to work on this every week-end, all
week-end long.
As for Sanne and myself, we'll be working on ES5 integration + Search 5.8 +
Search 6, so we also have a lot to do. I think I'll book some time slots (1
day a week maybe) to work on JSR-352 until we consider the module ready.

Any opinions on all this?

[1] https://github.com/yrodiere/hibernate-search/tree/jsr352
[2] https://travis-ci.org/yrodiere/hibernate-search/builds/203727344
[3] https://github.com/mincong-h/gsoc-hsearch/issues
[4] https://hibernate.atlassian.net/browse/HSEARCH-2594


Yoann Rodière <yoann at hibernate.org>
Hibernate NoORM Team