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(a)hibernate.org&gt; Hibernate NoORM Team