[HSEARCH-886] Provide the ability to configure specific paths to index within @IndexEmbedded as an alternative to depth #156

Closed
wants to merge 6 commits into
from

Conversation

Projects
None yet
5 participants
Owner

DavideD commented Sep 18, 2011

A first prototype.

Maybe when the paths is set depth should have 0 has default value.

Let me know what you think.

Davide

Owner

DavideD commented Sep 25, 2011

I've added the validation of the paths and set default depth to 0 if you only set the paths attribute.

Owner

DavideD commented Sep 26, 2011

I've removed the validation. I need to think a bit more about it

Owner

Sanne commented Sep 27, 2011

Hi Davide,
I had a brief look and I'm liking what I'm seeing. Liking it a lot.

While playing with this, can you consider as well HSEARCH-638 ? It seems you're already working on the depth, adding it as a parameter.

What's the validation you removed?

I think you should add more tests, especially some to mix the different strategies (to have both depth and paths)

Owner

DavideD commented Sep 27, 2011

I'm very happy you like it.

Zach Kurey tried it and he gave me some suggestions:
https://hibernate.onjira.com/browse/HSEARCH-886

Since the paths are specified as a String sometimes you can have some errors in it (for example when you mispelled the name of a field). It would be nice to have some kind of validation for this cases. I've pushed a first version that throws an exception when a path doesn't exists but it doesn't seem towork in every case at the moment so I prefered to remove it.

I think you are right about adding tests...it was actually a bit of lazyness... :)

Owner

Sanne commented Sep 27, 2011

Right, adding validation on the attribute names makes sense. Remember it should work on both getters and field accessors.

Owner

Sanne commented Sep 27, 2011

BTW, keep rebasing it as we're doing many changes ;)

Owner

DavideD commented Sep 27, 2011

No problem ;)

Owner

DavideD commented Sep 28, 2011

I've added the test for the depth and rebased the project to the latest master version.
I have one problem at the moment: if I run the tests I've added in eclipse everything works fine but if I execute the maven build they fail.

My maven build doesn't look very reliable lately. Can anyone try it?

Thanks

Owner

Sanne commented Sep 28, 2011

tried it, only your tests fail:

`Tests in error:
testPathIsIndexed(org.hibernate.search.test.embedded.path.PathEmbeddedTest): Unknown entity: org.hibernate.search.test.embedded.path.C
testPathIsIndexedWithPrefix(org.hibernate.search.test.embedded.path.PathEmbeddedTest): Unknown entity: org.hibernate.search.test.embedded.path.C
testMultiFieldsAreIndexedIfInPath(org.hibernate.search.test.embedded.path.PathEmbeddedTest): Unknown entity: org.hibernate.search.test.embedded.path.C
testEmbeddedNotIndexedIfNotInPath(org.hibernate.search.test.embedded.path.PathEmbeddedTest): Unknown entity: org.hibernate.search.test.embedded.path.C
testFieldNotIndexedIfNotInPath(org.hibernate.search.test.embedded.path.PathEmbeddedTest): Unknown entity: org.hibernate.search.test.embedded.path.C

Tests run: 392, Failures: 0, Errors: 5, Skipped: 0
`

Owner

DavideD commented Sep 28, 2011

Thanks,
they seem sto work in eclipse...

I will take another look this evening.

Owner

DavideD commented Sep 28, 2011

It seems the problem was in the setup and teardown methods.
Now everything seems to work.

Don't know if it comes in handy but after the latest rebase the CollectionUpdateEventTest doesn't fail anymore.

Owner

Sanne commented Sep 28, 2011

CollectionUpdateEventTest is not failing anymore because I've "silenced" it with the following change:
50b7b1e

but there still is a problem with it, Hardy is looking into it. at least it's not annoying people until we find out.

I just checked the tests of your last version, and all is green for me too. But I'm too sleepy to inspect the code now :)

@zackurey could you check this out too and see if it's going to solve your needs?
If not, or if you have any doubt, could you please help Davide with additional tests, especially thinking about the tricky corner cases?

Owner

Sanne commented Sep 28, 2011

And congratulations for surviving the GIT skills tests after all the code reorganization we did in the last few days ;)

Contributor

zackurey commented Sep 28, 2011

@Sanne
Definitely. I've been trying to get back around to looking at the latest changes today, but am running low on time. I'll give it it a review and a spin soon(hopefully tomorrow).

Thanks Davide.

Owner

DavideD commented Sep 29, 2011

The validation of the path is still missing though. If everything else works maybe it can become a new JIRA.

@Sanne
Git did most of the work :)

Cheers

Contributor

zackurey commented Sep 29, 2011

@davide

I'd be happy to take a crack at the path validation work. Seems only fair since I'm pushing for the feature. I'm not sure if we'd want it to come in as a different JIRA or not. I'm fine with it if Sanne is. If I'm having to fork your fork, things could get convoluted coordinating things.

Let me take a look over the latest and see if there is anything that needs changing with the basic feature support. The last time I gave it a spin everything worked fine.

Owner

Sanne commented Sep 29, 2011

you can work as you think is best, we can include Davide's work first and add validation later, or Zack can start working on validation from Davide's work.

I don't think Davide will need to rebase as often as in the last few days as we definitely don't move around files every week, but make sure you talk to each other so that he stops rebasing when you fork from this branch, or it will be hard to keep in sync.
@davided can you stop rebasing? do you think it's stable enough that you can apply eventually needed improvements/fixes on top of it as additional commits?

As far as timing goes, I'd be happy to include Davide's patch as soon as possible (even without the validation) but since it's an important change I'd love it if @zackurey could test it first to see if all was clear on the requirements, if you can now practically express the minimum graph needed for your real world use case (likely more complex than the unit tests). That's what I meant with helping with testing, you might have some advanced test case you want to add.

Generally it's a great idea to add your own product's use case as a test, so you'll know for sure the used frameworks won't break that in future ;)

Contributor

zackurey commented Sep 29, 2011

I think I'd prefer to work on it separately, just to reduce the number of hoops to jump through.

@real world use case
Actually I already integrated Davide's changes into a custom 3.4.1 hibernate search lib and used it in our app. The performance gains for the problem @indexembedded marked entity were huge. 5x faster huge.

I used it in two locations that were performance problems. Each with > 5 paths per @indexembedded. A variety of different use cases are covered by each path.

  • Leaf ending in a field bridge
  • Leaf ending in simple types
  • Leaf ending in a field bridge for a collection of simple types(Longs)
  • Paths where a portion of the path in the middle is a @indexembedded Collection

I don't really have a use case right now for a mixed bag case where we have a default depth + some paths that are deeper than the depth. But I'll contrive one up.

Also all the other traditional depth based indexing done in the app was unharmed, and worked as it always has.

I commented on a particular bit of code that could potentially mis-identify a path match. But as long as that is fixed I think its probably good to go. I should re-merge/integrate into a 3.4.1 branch and test again though. I tried upgrading to Hibernate core and decided to abandon the attempt for now. Nothing wrong with 4.x, just a few changed apis that we used a lot for custom type conversion, and some deprecated annotations/apis that I'll have to verify the substitutes for actually work as intended.

Owner

Sanne commented Sep 29, 2011

@zackurey
thanks a lot for the prompt feedback. Just to clarify there are no misunderstandings, I don't think we will include this in 3.4, you'll have to maintain your own branch if you don't upgrade Core ..

BTW the "at" symbol has a real meaning on github, make sure you use it to ping the correct nicknames. So far you notified mister "real" and "davide" already.

@davided, do you have a test to protect the code from the mis-identification Zack just mentioned?

Contributor

zackurey commented Sep 29, 2011

thanks a lot for the prompt feedback. Just to clarify there are no misunderstandings, I don't think we will include this in 3.4, you'll have to maintain your own branch if you don't upgrade Core ..

Understood. 4.x rocks the boat to much for a near term release we have. Next release I'll take the necessary 4.x steps.

BTW the "at" symbol has a real meaning on github, make sure you use it to ping the correct nicknames. So far you notified mister "real" and "davide" already.

How embarrassing.. Thanks for limiting future mistakes. I frequently use 'at' as 'an answer' to something as well.

do you have a test to protect the code from the mis-identification Zack just mentioned?

I just reviewed the code. The suggested fix has been applied.

Owner

DavideD commented Sep 29, 2011

I've applied all the fix suggested by @zackurey. I added the test to check that the depth parameter is respected (using the genealogy tree of John England). I didn't add the tests for the mis-identification (shame on me).

I don't have any problem in zack working on the validation. This solution seems stable enough and as long as no other bugs are found I won't touch it. At the moment I would just add a test for the mis-identification problem.
I think it's safe for zack to work on the validation starting from my work anyway.

Contributor

zackurey commented Sep 30, 2011

@davided
I re-tested your latest code in my app Davide. Everything worked as expected. I thought I saw a problem with a super classes @indexedembedded collections not being picked up even though they were part of a path, but the issue has mysteriously gone away. I'll add a test for that and all of our other 'path' use cases as Sanne suggested above when I do the validation work.

@Sanne
Can you accept Davide's pull requests now? Looks pretty solid to me, and working from my own fork seems like the easiest way to proceed.

Contributor

zackurey commented Sep 30, 2011

@Sanne
Sorry to flip flop, but nevermind on pulling Davide's code in first. I just finished the validation + test cases. I'll fork Davide's fork first thing tomorrow and send the pull requests to him so you can pull everything in in one go. I'm out of energy for tonight.

Contributor

zackurey commented Sep 30, 2011

OK. Apparently I can't have two separate forks that share the same parent. When I try to fork Davide's fork nothing happens and it just drops me on the same page as my fork of hibernate-search.

I would delete my other repo/fork and then refork from Davide's but I'm waiting for my pull requests for HSEARCH-926 to be accepted. @Sanne, the contributor agreement is signed for both the corporate and individual level. Can that pull request proceed now?

The other option is @davided's work can get pulled into the main branch, and then I can pull the changes into my own fork.

If I'm missing something as a newb to Git, please point it out. Thx.

Owner

Sanne commented Sep 30, 2011

Hi, sure I'll try to merge this soon, sorry have been busy with other issues.
TBH I still have to review this, so I don't know yet if some changes are required.

To answer your git doubts: yes you don't need to fork again. You should have now a copy of yourself on github, and a personal copy on your dev-station. Usually you push/pull to your github repository (conventionally named "origin") but you can add more "remote"s (remote is the git term), so you can pull changes from Davide, push them to your own, or pull changes from "upstream" (conventional name for the project reference). I will for example pull from both of you, test locally, send a proposal to my personal github to have that integrated from another committer if we feel more reviews are needed (as usually when new APIs are involved).
If you join us on IRC #hibernate-dev I can help you directly in the first steps.

Contributor

zackurey commented Sep 30, 2011

Thanks Sanne. Your nudge about the remote repos pointed me in the right direction. Neat stuff.

I've sent the pull request to Davide: DavideD#1. @davided, can you pull that in and let me know if you have any concerns, or thoughts about additional tests?

I could also send a pull request directly to hibernate search:master, which would contain both our changes. But just in case Davide needs to make further changes I went that route first. But if the other way is preferred let me know.

Owner

DavideD commented Oct 2, 2011

Sorry @zackurey if I didn't reply to your messages in these days but I was on holiday. After a quick look everything seems great.

I will include it in the already existing pull request tomorrow when I'm less tired.

Cheers

Owner

DavideD commented Oct 7, 2011

Rebased, cleaned and joined with the validation made by @zackurey.

Should be ready for a review.

Cheers

Owner

Sanne commented Oct 13, 2011

Hi, sorry I didn't integrate it yet as I'm adding some tests; I'm not sure about the chosen algorithm being respecting the depth in both directions (i.e. from @containedin too). Maybe my tests will prove me wrong but I'm not done with it yet.

The general code quality is very good, thanks! Some more comments could help, don't take the original source as an example of well commented code.

Owner

DavideD commented Oct 13, 2011

It's my fault. I tend to avoid comments because most of the time they are useless.

If you can tell me which part of the code is not clear I'm going to fix this.

Owner

DavideD commented Oct 13, 2011

I remember we've talked about the @containedin problem. I'm not sure what you mean but the more tests there are the better :)

Owner

Sanne commented Oct 13, 2011

no worries, in fact I think the part which is puzzling me most was not changed by you :D
I'm referring to the logic around the depth counter checks, like https://github.com/hibernate/hibernate-search/pull/156/files#L1L653

I believe it's correct because of all the tests, but the code is not self-explanatory about this.

Owner

hferentschik commented Nov 4, 2011

I still feel separate annotations would be better. I think we had this discussion somewhere

Owner

DavideD commented Nov 7, 2011

@Sanne
I think I finally understand the problem with the @containedin annotation. I suppose you are talking about https://hibernate.onjira.com/browse/HSEARCH-638 ?
I've created a quick patch that seems to pass the existing (commented) tests in https://github.com/hibernate/hibernate-search/blob/master/hibernate-search-orm/src/test/java/org/hibernate/search/test/embedded/depth/RecursiveGraphTest.java
But I Have to add more tests. I see if I can inlcude it in this pull request by the end of the week

Owner

Sanne commented Nov 7, 2011

@davided, awesome :) was good talking to you in person.
Ask me anything if you have doubts, or if you want to you can send me "early previews" of your tests.

Owner

DavideD commented Nov 8, 2011

@Sanne
A first quick patch that passes the tests previous commented for HSEARCH-638 is here: https://github.com/DavideD/hibernate-search/commits/HSEARCH-638

Right now it doesn't consider paths and actually I'm not so sure of the general correctness but it should be enough for an exchange of ideas.

Owner

Sanne commented Jan 5, 2012

So HSEARCH-638 was merged, I'm only waiting for @davided to rebase this and address @hferentschik concerns.
Hope to see that soon as I think this is a very nice feature.

Owner

DavideD commented Jan 10, 2012

Should be rebased and merged now.

Owner

hferentschik commented Feb 2, 2012

As Sanne pointed just out to me, I never elaborated on why I think there should be two annotations - @indexembedded (as is) and a (new) @indexpath.

I think adding paths to @indexembedded introduces potential conflicts between depth and paths. What if depth is set to 1 and your specified path is longer? What do you do? Longest wins? Warning? Exception? IMO it is not obvious what should happen. ATM, I think the javadocs are even wrong. They say:
{quote}
Ignore depth and index the fields at the specified paths.
{quote}
According to @Sanne the behavior is actually that you can specify depth and a path which exceeds the depth the path still gets indexed.
Here is the discussion I was referring to - http://lists.jboss.org/pipermail/hibernate-dev/2011-August/006940.html. In particular http://lists.jboss.org/pipermail/hibernate-dev/2011-August/006988.html

Owner

hferentschik commented Feb 2, 2012

Another border case is:

@IndexEmbedded(paths="foo") 

Does this just index the path? If so, that's a contradiction to the default value of depth. If we keep the default value as Integer.MAX_VALUE all configuration using paths need to specify also a depth parameter in order to be useful.

Owner

hferentschik commented Feb 2, 2012

We could change the default for depth, but that would break backwards compatibility.

Owner

hferentschik commented Feb 2, 2012

But changing the depth default introduces another problem:

@indexedembedded

There the default should be MAX_DEFAULT. So two different use cases which require different defaults. IMO this cannot be resolved in a consistent way using a single annotation.

Contributor

zackurey commented Feb 2, 2012

I think adding paths to @indexembedded introduces potential conflicts between depth and paths. What if depth is set to 1 and your specified path is longer? What do you do? Longest wins? Warning? Exception? IMO it is not obvious what should happen. ATM, I think the javadocs are even wrong.

Yes, it sounds like the documentation is incorrect. It is not that they are in conflict, but that they can both be used simultaneously. In the case you mention (where depth=1 and you have some paths configured that exceed that depth) all paths will be traversed one level down, and any paths that are additionally configured that exceed that depth also get indexed. I actually think this is really nice(as long as its documented properly) that you can still get some automated behavior where most paths you want to index you can use depth, and then if you want to add some specific extra paths that have much deeper depth you can do that as well.

@indexembedded(paths="foo"), what the behavior should be

Davide and I thought that it made sense that if paths is specified and depth is NOT specified then we treat depth as '0'(because its non-sensical to specify paths and have Integer.MAX_VALUE depth). This is not changing the default to 0, but changing the default to 0 only if paths are specified.

I haven't had an ideas that would resolve the ambiguity in absence of documentation. Whether its depth and paths as attributes of @indexedembedded, or @indexedembedded with a nested @paths annotation, or stand alone @indexpaths and @indexedembedded annotations, all need proper documentation to communicate the behavior. Again I say that because I do think that folks(including myself) will want the ability to both auto-index up to some depth and configure explicit paths of deeper depth. This is a pretty flexible combo, and agree documentation for @indexedembedded needs to be updated to say something along the lines of:

  • Paths and depth may both be specified. If both are specified the default indexing behavior will occur up the depth specified, and paths that exceed the configured depth will be indexed as well
  • If paths is specified and depth is not specified, depth will default to 0. Only the paths explicitly configured will be indexed
  • If neither depth or paths are specified, depth defaults to Integer.MAX_VALUE and paths is clearly not applicable

If clearly documented in this way do you still have concerns Hardy?

Owner

DavideD commented Feb 2, 2012

The idea is that the paths are indexed even if they are beyond the depth threshold.
I admit that the Javadoc is misleading (I'm going to change it) so as a summary this are the use cases:

  1. Depth is shorter than path length: Ex. _IndexEmbedded(depth = 1, paths = {"entity.entity.entity.field"})
    In this case everything inside depth is indexed + "entity.entity.entity.field"

  2. Depth is bigger than path length: Ex. _IndexEmbedded(depth=100, paths = {"field"})
    Since the field is inside the depth threshold is going to be indexed anyway. In practice this is equivalent to
    _IndexEmbedded(depth=100, paths = {}) or _IndexEmbedded(depth=100)

  3. Depth is not set and path is set: Ex. _IndexEmbedded(path={"field"})
    At the moment this is equivalent to _IndexEmbedded(depth=0, path = {"field"})
    If we stick with the usual value for depth it would be equivalent to _IndexEmbedded and therefore useless. Maybe this can confuse the user but it seems more practical. It's very easy to change, anyway

I think very good documentation is going to be needed even if we use two annotations. The fact that they interact together it can be an argument to put them in the same place.
What is gonna happen in this case?
_IndexEmbedded(1)
_IndexPath("foo")

It doesn't look easier to understand than this _IndexEmbedded(depth=1, path={"field"}). I would use another annotation if it can be used in other contexts. Anyway, I'm ready to change it, starting from the JavaDoc :)

Owner

DavideD commented Feb 2, 2012

Ah, sorry I read the reply of @zackurey only after I've sent the comment.
So it's a bit of a repetition.
Just to state it again if the "path" is not specified or is empty the annotation works exactly as before (with default value set to INFINITE).

Owner

hferentschik commented Feb 2, 2012

Hi guys,

just wanted to make clear again that feature wise we want exactly the same. Under the hood this is all fine. Great work.

Just to state it again if the "path" is not specified or is empty the annotation works exactly as before (with default value set to INFINITE).

This is exactly where the problem is. If the path is specified the depth value changes and I don't think it should. Java annotations just don't allow that:

int depth() default Integer.MAX_VALUE;

means - "if depth is not specified it is Integer.MAX_VALUE". There is no additional but. In our case we want depth to be different things for each of the case:

@IndexEmbedded 
@IndexEmbedded(depth=2, paths="foo")
@IndexEmbedded(paths="foo")

Of course I can do that, but should I? IMO, no, because no matter what you write in the Javadocs in the end it is inconsistent with how Java annotations work.

One could make depth a mandatory parameter, but then you don't have the simple @indexembedded usecase anymore.

I am also against annotation overuse, but this is a case where a new annotation makes sense, because it removes an ambiguity.

Personally I am surprised that you all so willingly agree to bend the rules of annotations.

Owner

DavideD commented Feb 3, 2012

Given that we can leave the default value for depth set to MAX_VALUE in every case.

If I understand correctly the problem is that before the patch the depth attribute means
"Stop indexing embedded elements when depth is reached"
after the patch we are actually saying
"Stop indexing embedded elements when depth is reached except for the one included in the paths".

Is this the inconsistency you are talking about? Inside the patch the depth behavior seems consistent because it refers to the value not defined in the paths, if paths is empty it is applied to every value. In the end it works has an additional filter.

I'm trying to understand, I'm not used to discuss over this things :)

Contributor

zackurey commented Feb 3, 2012

Hey Hardy,

Those latest comments definitely clarify your objection for me a bit more. Its a fair point.

I guess I'm still wondering how we remove the ambiguity. As I said in my comments I think you still want to give the API user the ability to do some default indexing to a certain depth while being able to explicitly index deeper paths. So with the new annotation what do we do with the following case?:


@IndexPaths(paths={"a.b.c.d.e.f.g" })
@IndexedEmbedded()
private SomeType someType;

Should this be an error, since its clear the user doesn't quite understand that the default depth of INFINITE will essentially make the @indexpaths specified pointless? Or should it be illegal to specify @indexedembedded at the same time as @indexpaths? If so, in order to give the user the ability to do some 'auto indexing' and indexing based on paths, you'd have to add an attribute. Something like 'autoIndexDepth', which can default to 0 in the @indexembeddedpaths annotation.


@IndexEmbeddedPaths(autoIndexDepth=2, paths={"a.b.c.d.e.f.g" })
private SomeType someType;

If we do want to go down this road, I'd prefer the annotation be called 'IndexEmbeddedPaths'. It just feels weird to have @indexpaths, and @indexembedded, when @indexpaths is indexing embedded objects, just a very specific set of them. To be clear its basically an explicit form of @indexedembedded, it seems more natural to call it @indexembeddedpaths. It also makes it more clear to me that it should be an error to specify them both simultaneously.

The other option, is to just let depth default to INFINITE, and keep paths as an attribute. In that case you'd still have to document(or throw an error) that its essentially useless to not specify a depth if you specify paths.

I hate to sound like I'm flip flopping a lot, but there are good points on either side. If ignoring the runtime annotation value is bad etiquette(or just downright wrong) and likely to generate lots of confusion then something like @indexembeddedpaths(autoIndexDepth=2, paths={"a.b.c.d.e.f.g" }) would be a good option. Also it has the benefit that more configuration attributes can potentially be added in the future.

Frankly I think Hardy and Sanne should just hash this out at this point. = ) You guys have way more experience dealing with public facing APIs and dealing with the repercussions. Obviously I'll work with whatever you guys decide.

Owner

hferentschik commented Feb 3, 2012

Those latest comments definitely clarify your objection for me a bit more. Its a fair point.

Great :-)

I guess I'm still wondering how we remove the ambiguity.

Same here.

So with the new annotation what do we do with the following case?:

@indexpaths(paths={"a.b.c.d.e.f.g" })
@indexedembedded()
private SomeType someType;

Right, that's a border case with two annotations as well. However, at least we there is no default changing magic. Also most people hopefully do know that @indexedembedded has an infinite depth. That's what we have been communicating all the time and that's what the default value says.

Should this be an error, since its clear the user doesn't quite understand that the default depth of INFINITE will essentially > make the @indexpaths specified pointless?

I don't think it would have to be a an error. I could imagine logging a warning (more for educational purposes)

Or should it be illegal to specify @indexedembedded at the same time as @indexpaths?

No. In this case the two annotation do not provide the same functionality anymore as the single IndexedEmbedded (unless of course you add more parameters as you suggest.)

If we do want to go down this road, I'd prefer the annotation be called 'IndexEmbeddedPaths'.

That's fine with me. I agree that some sort of symmetry to the @indexembedded annotation would be nice. Maybe @indexembeddedbypath

The other option, is to just let depth default to INFINITE, and keep paths as an attribute. In that case you'd still have to
document(or throw an error) that its essentially useless to not specify a depth if you specify paths.

After my last comment yesterday, I was thinking the same thing. If one single annotation, we should at least keep the default value for depth. That is really my biggest objection. If we go down this path we basically loose the ability to just specify the path:

@IndexEmbedded(paths="foo")

I guess we can decide whether we make this an exceptional case, log a warning or just go ahead and index the whole graph and wait for the user to figure things out.

I hate to sound like I'm flip flopping a lot, but there are good points on either side.

:-)

then something like @indexembeddedpaths(autoIndexDepth=2, paths={"a.b.c.d.e.f.g" }) would be a good option.
Also it has the benefit that more configuration attributes can potentially be added in the future.

This approach works as well for me, btw (the don't allow @indexembedded and @indexembeddedpaths, but have an additional autoIndexDepth). I did not comment on this on my comment above.

As said, my main objection is the default switching part. AFAICS, we have now three viable alternatives:

  • Keep the single IndexEmbedded with a default depth of infinitive in all cases. What we exactly do for the no depth only path property specified is open for discussion.
  • Have @indexembedded and _@IndexEmbeddedPaths_which can be specified together on the same field. It still allows for some "stupid" configurations, but I think it is more explicit and easier to understand why still "everything" gets indexed
  • Have @indexembedded and _@IndexEmbeddedPaths, but don't allow to specify both annotation at the same time. To make this work and have the same feature range we need to add something like autoIndexDepth to @indexembeddedpaths

I could live with any of the three solutions. I still favor #2, then #3 and lastly #1

Owner

Sanne commented Feb 3, 2012

@zackurey and @davided , thank you for the long discussion and great feedback. Wanted to assure you it's generally not that hard and time consuming! This is really an exceptional case, if you have more cool ideas and patches just send them don't be scared out of this long discussions ;-)


Let me try resume my position on this:

  • I agree on Hardy's concerns on changing defaults ravishing annotation's default
  • I dislike having an additional annotation:
    • Looks like we introduce an alternative way of mapping, while we already have one. A good API should not provide many ways to do the same thing (you may disagree if they are actually the same - but it's still be confusing for the non-expert)
    • Too many annotations
    • Need of cross-linking between the two in documentations is a sign of smelly design

So my vote goes for Hardy's proposal #1, but agreeing with him (and think we all are on the same page now?) that we need to find a good solution for inconsistent applied options:

#1 Keep the single IndexEmbedded with a default depth of infinitive in all cases. What we exactly do for the no depth only path property specified is open for discussion.


Proposal

So my idea is

  • one unique annotation for the mapping purpose
  • depth option doesn't change in any way
  • no defaults change, no complexity to explain
  • paths offer a way to "reach farther" on certain specific paths, assuming it's longer than depth. This makes it a functional extension of IndexedEmbedded and makes it consistent with not adding a new annotation. @hferentschik : this addresses your main reason to dislike #1 correct?
  • no errors: at most a warning. It's an advanced optimization API and so are other annotations like ReadOnly, etc.. people using it should understand, and no harm is done anyway as people will definitely notice if nothing is ever matching your queries.

Examples

@IndexEmbedded(paths="foo")
paths is redundant, will be ignored as depth is infinite. We might decide to print a warning at bootup about it.

@IndexEmbedded(depth=4, paths="owner.address.city.name")
paths is redundant, will be ignored as depth is higher/equal. Also, possibly a warning.

@IndexEmbedded(depth=4)
No changes, nothing new

@IndexEmbedded(depth=2, paths="owner.address.city.name")
Cool self-explanatory feature ;-)

Why warnings and no errors? I can easily see myself doing some experiments on new queries to add new features to my app and changing some values here and there, I would hate it to see exceptions just because I didn't take a final decision yet. Warnings could help though to polish the app when I've clarifies with myself what I'm needing.

I hope we can find an agreement to something similar to the above soon. @emmanuelbernard might help on the democratic decision :-)

Implementation comments

Assuming we agree soon, after applying needed changes I hope you'll add some awesome documentation + polish javadocs ?

Also, be careful with the field names: field names can be overridden, and don't necessarily match the entity property names . I would expect paths to match the field name being written in the index, not the entity property name.

Owner

hferentschik commented Feb 3, 2012

@zackurey and @davided , thank you for the long discussion and great feedback. Wanted to assure you it's
generally not that hard and time consuming! This is really an exceptional case, if you have more cool ideas and > patches just send them don't be scared out of this long discussions ;-)

Totally agree. This must be the longest pull request / feature discussion ever.

I dislike having an additional annotation:

Still need to disagree here. IMO you are actually arguing from the expert position and not from the non-expert position.

Proposal

So my idea is

  • one unique annotation for the mapping purpose
  • depth option doesn't change in any way
  • no defaults change, no complexity to explain
  • paths offer a way to "reach farther" on certain specific paths, assuming it's longer than depth. This makes it a
    functional extension of IndexedEmbedded and makes it consistent with not adding a new annotation.
    @hferentschik : this addresses your main reason to dislike #1 correct?
  • no errors: at most a warning. It's an advanced optimization API and so are other annotations like ReadOnly,

Works for me and it addresses my main concern. Maybe we could name the parameter additionalPaths instead of paths. In the end depth is still the driving force and this option really only makes sense as additional "extending" paths which exceed the specified depth.
Warnings instead of exceptions works for me.

Assuming we agree soon, after applying needed changes I hope you'll add some awesome documentation +
polish javadocs ?

that would be great

Also, be careful with the field names: field names can be overridden, and don't necessarily match the entity
property names . I would expect paths to match the field name being written in the index, not the entity property > name.

Right. How do we handle the prefix option? What happens if a prefix is specified, but not used in the specified path? Is this still a no exceptional case? There I think it is justified to throw an exception.

Owner

DavideD commented Feb 3, 2012

@zackurey and @davided , thank you for the long discussion and great feedback. Wanted to assure you it's generally not that hard and time consuming! This is really an exceptional case, if you have more cool ideas and patches just send them don't be scared out of this long discussions ;-)

The things I'm learning are worth the effort :-)

I have to check the code but I will give a quick reply now:

Also, be careful with the field names: field names can be overridden, and don't necessarily match the entity property names . I would expect paths to match the field name being written in the index, not the entity property name.

You are right, I think I chose this way because it was the easiest way to implement it. It becomes a bit inconsistent because I'm concatenating the name of the attribute (not the field) to the prefix .

Right. How do we handle the prefix option? What happens if a prefix is specified, but not used in the specified path? Is this still a no exceptional case? There I think it is justified to throw an exception.

No other exceptional cases :)
The prefix is considered when checking the path. If you specify a prefix that doesn't exist the validation should fail.
I don't see any tests for this situation at the moment (shame on me). I will add them.

I will try to add all the mentioned things this evening.
Cheers

Owner

Sanne commented Feb 3, 2012

Works for me and it addresses my main concern. Maybe we could name the parameter additionalPaths instead of paths. In the end depth is still the driving force and this option really only makes sense as additional "extending" paths which exceed the specified depth.
Warnings instead of exceptions works for me.

+1 right, this is getting nice and consistent by changing the parameter name. Fight was worth it :) Let's name it additionalPaths

How do we handle the prefix option? What happens if a prefix is specified, but not used in the specified path? Is this still a no exceptional case? There I think it is justified to throw an exception.

Right we need to defend against typos, that would be not an inconsistency but just wrong.
+1 for an exception if the defined paths strings are not resolvable.

Owner

hferentschik commented Feb 3, 2012

Ahh, the sweet smell of progress is in the air :-)

Owner

emmanuelbernard commented Feb 3, 2012

Do you all agree that having @IndexEmbedded(depth=4, paths="owner.address.city.name") and @IndexedEmbedded(paths="owner.address.city.name") as no op (assuming not cyclic relations) is a good thing?

To me that looks counterintuitive. Though I understand the reasoning for keeping the default consistent, having a default meaning undefined and thus behaving differently depending on other factors is not unheard of in the annotation world.

What's the most common use case here in decreasing priority

  1. @IndexedEmbedded
  2. @IndexedEmbedded(depth=0, paths={"a.b.c", "a.e.f"})
  3. @IndexedEmbedded(depth=3)
  4. @IndexedEmbedded(depth=3, paths="a.b.c.d")

I'm not too happy to have 2. being more complicated than necessary

Owner

Sanne commented Feb 3, 2012

Do you all agree that having @indexembedded(depth=4, paths="owner.address.city.name") and @indexedembedded(paths="owner.address.city.name") as no op (assuming not cyclic relations) is a good thing?
To me that looks counterintuitive

Agree it's not as good as if we could start from scratch, but I think it's a good compromise I can live with to move forward.

I was planning to propose in a second step to drastically change the depth default. Hadn't disclosed it yet as I thought that should be a discussion for a next change, possibly independent to not swamp progress on this one.

So now that I have to talk about it, my proposal for next step would be to have depth=0 as a default instead of infinite.
The change in default would be always applied consistently: not depending on the existence or not of additionalPaths definitions.

This would indeed break compatibility, but only for those use cases having
@IndexedEmbedded
only, which I believe are very limited, and we can easily print a warning about it or even fail to deploy.

I'm not too happy to have 2. being more complicated than necessary

A feature for better control of the indexed graph is highly needed if you want to avoid tons of additional loads in certain scenarios. As an example, it's just been asked again: https://forum.hibernate.org/viewtopic.php?f=9&t=1014328 , and likewise I see it quite often. I usually recommend custom bridges, but that involves quite some work and maintenance.

Real JOIN coming soon

With the coming of real JOINs - proposed to be in Lucene 3.6, definitely already in 4.0 (trunk) we will likely need a different annotation to mark the special new kind of relation, which makes queries possible on related entities without embedding the child fields in the root Document, so for that case I will agree that IndexedEmbedded is not a suited name anymore. But now it definitely is, as we're in the feature-context of defining the embedded graphs.

Owner

emmanuelbernard commented Feb 3, 2012

Your proposal would make 1. more complicated than necessary just like the current proposal does for 2.

I am not saying we should not offer something to cover the usercase 2., I'm just saying it should be simpler (ie with the need to define depth=0).

Owner

Sanne commented Feb 3, 2012

I am not saying we should not offer something to cover the usercase 2., I'm just saying it should be simpler (ie with the need to define depth=0).

You mean using a single annotation and imply that depth=MAX is going to be interpreted as depth=0 when paths are specified? That's how Davide currently implemented it.

Owner

hferentschik commented Feb 3, 2012

Argh ;-)

@emmanuelbernard

To me that looks counterintuitive.

To me anything changing the default is counterintuative.

Though I understand the reasoning for keeping the default consistent, having a default meaning undefined and thus
behaving differently depending on other factors is not unheard of in the annotation world.

I am not so sure about the not unheard of part. Do you have an example? One thing which comes to mind are some of the old Hibernate annotations and there I always thought it would have been better to be consistent. Don't nail me on an example now, I would have to dig it out. You might know better anyways.

I am not saying we should not offer something to cover the usercase 2., I'm just saying it should be simpler (ie with the
need to define depth=0).

Right a second annotation :-)

@Sanne

So now that I have to talk about it, my proposal for next step would be to have depth=0 as a default instead of infinite.
The change in default would be always applied consistently: not depending on the existence or not of additionalPaths
definitions.

This would indeed break compatibility, but only for those use cases having
@indexedembedded
only, which I believe are very limited, and we can easily print a warning about it or even fail to deploy.

I think this is a case of Converse fallacy of accident or hasty generalization. Obviously we are dealing more with people who report bugs and write forum posts. They reach a point where they hit the boundaries of Search. I like to believe though that we don't hear from the majority of users, because it just works just fine for them. For this reason I would not like to make the @indexembedded() case harder.

Bottom line, to make all Emmanuel's use cases easy to configure without compromising consistency and annotations is to introduce a second annotation.

Owner

emmanuelbernard commented Feb 3, 2012

To me that looks counterintuitive.

To me anything changing the default is counterintuative.

But we are not changing the default on a behavior that is possible today. We are changing the default in a case that we are about to support.

About an example on different defaults based on external factors, you can think of all the examples involving default "". In many cases "" can mean:

  • use a well defined default value (that's not empty string)
  • ignore the value altogether because the attribute has no meaning

The way to solve that in a "normal form" is by introducing a different annotation. However there is complexity in adding a new annotation in an environment already covered by one because there is not natural way to say that one might want to use the new annotation as well or instead of. JavaDoc is the best place but we know people don't read them too often. So this ends up being an extra expert knowledge someone has to remember.

Owner

Sanne commented Feb 3, 2012

I wouldn't be too afraid in relying on expert knowledge for proper understanding of this features, as it's targeting performance tuning anyway.
I guess most prototype applications won't care at all, still this is important to have to solve performance problems as otherwise people is stuck writing complex workarounds; in those cases reading the javadoc is likely, and people will be having tools to measure benefit vs. this stuff doesn't work experience you would get when forgetting a specific path.

Like I mentioned above, I see the complexity of this feature comparable to the read-only entity annotation. While seldom used, it's very important to have the option as it can dramatically improve performance.

Owner

emmanuelbernard commented Feb 3, 2012

That's not true, this will be an essential feature of our integration for the OGM query engine. We will be path based and that metadata will be generated somehow eventually but we will have to live in a period when the data will be provided by the suer

And again I'm not against the feature, I'm just concerned how we expose it, as we all are it seems ;)

On 3 févr. 2012, at 17:49, Sanne Grinovero wrote:

I wouldn't be too afraid in relying on expert knowledge for proper understanding of this features, as it's targeting performance tuning anyway.
I guess most prototype applications won't care at all, still this is important to have to solve performance problems as otherwise people is stuck writing complex workarounds; in those cases reading the javadoc is likely, and people will be having tools to measure benefit vs. this stuff doesn't work experience you would get when forgetting a specific path.

Like I mentioned above, I see the complexity of this feature comparable to the read-only entity annotation. While seldom used, it's very important to have the option as it can dramatically improve performance.


Reply to this email directly or view it on GitHub:
#156 (comment)

Owner

Sanne commented Feb 3, 2012

That's not true, this will be an essential feature of our integration for the OGM query engine. We will be path based and that metadata will be generated somehow.

Sure, but since we will generate the metadata, the average user won't need to deal with the complex problem of reading the javadoc to get the annotations right.
And I'm not disagreeing with you statement: there is indeed a complexity, but I'd point out that we don't need to worry too much about it as it will work fine for most users whether they read or not the manual.

Contributor

zackurey commented Feb 3, 2012

Hope this doesn't sound drastic, but since there is no clear right/wrong winner in the set of current ideas, thought I'd throw another proposal out there:

What about if we:

  1. Deprecate @indexembedded because the name itself, and the historical expectations it has are part of the cognitive dissonance we are all experiencing here. This says 'hey there are new options on how to do this, and based those new options some cleanup had to be done, so go look at the two new Embedded style annotations'. But it also lets them keep on using the old annotation until the next major revision release. For major revisions I expect some pain on removing use of deprecated APIs.
  2. Introduce a replacement for the @indexembedded annotation: @indexembeddedbydepth. Personally I think it should be required to specify a depth. They could always set it to Integer.MAX_VALUE to get back to the infinite approach. But I really don't think that is what people really want, and its really easy to make mistakes where at one point in time that was fine, but then someone introduces cycles and it quietly becomes a major problem.
  3. Introduce @indexembeddedbypaths
  4. Allow both to be specified on a particular field/property.
  5. Emit a warning if both are specified and depth exceeds any configured path
Owner

DavideD commented Feb 4, 2012

I've rebased everything, changed the tests to be simpler and now the the field name is considered when renamed.

It seems that we don't have a final verdict at the moment so left the default depth value set to 0 when paths is not empty.
Anyway, It should be easy to change the defaut value and use an additional annotation instead of the attribute.

Owner

emmanuelbernard commented Feb 10, 2012

Ok let's reach a conclusion and use a vote.

There are three main options floating

  1. Use two annotations (or even three if @IndexEmbedded is deprecated following @zackurey proposal)
  2. Use one annotation and leave the default as it is (ie infinite depth)
  3. Use one annotation but define that depth = 0 if it's not overridden and if path is used

I think my preference goes to 3. see my arguments before to prefer it over 2.

I find @zackurey proposal appealing as it clarify things but I am a little concern that we will want to change these annotations yet again when Lucene joins come to reality and we integrate them. But I'm not familiar with how that will shape in Lucene so maybe my concerns are void.

Owner

emmanuelbernard commented Feb 10, 2012

By the way even if we don't reach a conclusion by monday, I think it's a good idea to push this code into master with documentation so that people can try it out in Beta2

Owner

Sanne commented Feb 10, 2012

+1 for solution 3

I don't dislike Kurey's proposal either, but it's not my primary preference and I think it is from his point of view also an attempt to settle down and speedup decision, but not his favourite choice either? Please correct me if I'm wrong.

Owner

hferentschik commented Feb 10, 2012

I like @zackurey proposal best. For me it seems to be the best way forward. It addresses all ambiguities we are experiencing.

+1 for solution 1

-1 for solution 3 - I think we all see the potential problems and there are solutions, so why settle for something which doesn't address the problems. I also have no problem with changing the annotation again or adding to them once Lucene joins are coming. This is still a fair bit down the track and we don't even know yet how this all will look like.

Contributor

zackurey commented Feb 10, 2012

+1 for solution 1

I almost voted for 3 just because its already done, but the conversation has brought up some good points:

  • There needs to be a way to broadcast there are new options to embedded indexing. Deprecation accomplishes that
  • There is a desire to eliminate all ambiguity of how paths and depth might interact. Personally I'm fine with how option 3 works, but 1 is the clearest
  • I also think I've heard(correct me if I'm wrong) a desire to change the default depth or to make it required. Personally I don't like the old default depth of infinite. The 'adding annotations' phase of development is a tiny amount of time. In my experience, every single time I've chosen to specify depth(or in hindsight specified it because of some problem). So I'd prefer a new annotation that forces me to think and make a choice. And its a bonus that this also eliminates the ambiguity of the interaction with indexing by paths.
  • From what I've read about JOIN(https://issues.apache.org/jira/browse/LUCENE-3602), there will of course be a higher cost, and it sounds like a query time problem, not a indexing problem. For one:one, one:many, one:few I would still expect people to take the embedded approach to get the best performance. For many:one where the world has to be re-indexed because a single entity changed, I would expect a Join to be the approach, and that for a particular path from a root entity you can have a combination of @indexedembedded and @join(with=SomeOtherEntity.class, joinField='someField', inverseJoinField='someOtherField').

It sounds like the JOIN feature is done on 3.6 and 4.0, so maybe its clearer now on how that would impact hibernate search and could help make this decision less opinion based. If my impressions of how joins might work are true, then I would think @emmanuelbernard would be more inclined to go with solution 1(correct me if I'm wrong). Maybe even @Sanne would also be ok with the approach if its unlikely join impacts these annotations, and default depth behavior gets changed moving forward.

But again. I really don't feel that strongly one way or the other so I won't be upset if you ignore my vote if there is no tie breaker. Option 3 has something going for it(its done).

Owner

emmanuelbernard commented Feb 11, 2012

@davided do you have an opinion?

Owner

DavideD commented Feb 11, 2012

I'm more for number 3 at the moment.

It makes the addition of excludes path harder though and I'm not sure why @Sanne doesn't like that feature.
Anyway, we can always deprecate this annotation later when we have a better idea of the use cases, isn't it?

Owner

Sanne commented Feb 11, 2012

I don't dislike adding exclusions a well, just that I would do it in a second time to not delay this one further. It seems a well perfectly compatible with the option 3 so s can easily add it later without needing to deprecate anything.

I think3 is winning, I'll merge it and see how it goes in the next beta.

Zach,I take it that even if that's not your first choice you still like the solution, and we can readdress some of your concerns via better logging of what's being indexed?

Owner

DavideD commented Feb 11, 2012

Rebased

Contributor

zackurey commented Feb 11, 2012

@Sanne. Yes I'm perfectly happy with option 3. There is always the option of deprecating IndexEmbedded in the future if it turns out that in hindsight the community needs something more like option 1. And I agree that exclusions should be fine with option 3 as well.

Owner

hferentschik commented Feb 11, 2012

(--)/ ...

Owner

Sanne commented Feb 13, 2012

merged

Sanne closed this Feb 13, 2012

@yrodiere yrodiere added a commit to yrodiere/hibernate-search that referenced this pull request Feb 20, 2017

@mincong-h @yrodiere mincong-h + yrodiere Squashed commit - RENAME ME
This commit has been extracted from https://github.com/mincong-h/gsoc-hsearch/tree/master/
It is the result of squashing commits
576f105 to 40aff727a4ca70dd809ca72dcb6315d71f80a37f
(see git log below).

commit 40aff727a4ca70dd809ca72dcb6315d71f80a37f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 23:18:43 2017 +0100

    #168 test batch job runnability over a poorly-formed entity
    It has multiple ID-like fields, which make it difficult to identify the real identifier.

commit 3cd83d9b5d9c055ee133d66a5af7e9c027a572dc
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 22:22:33 2017 +0100

    #165 delete unused import

commit 58fabd11044b64f82f69432061fe1a37ad8967a4
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 21:55:17 2017 +0100

    #165 remove duplicate ID projection

commit d0c23f934851866ecfc797c889a9c3f69971208c
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 21:49:01 2017 +0100

    #165 avoid using toString() method

commit 15d2952a30d14384ed9a1a514b7a9a72b2d30ae6
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Jan 3 22:34:49 2017 +0100

    #165 use `Projections#id()`
    instead of `DocumentBuilderIndexedEntity#getIdPropertyName()` to avoid null reference issue for provided IDs.

commit 89624d52f7b6b955bbf45d576b538b8fc93445fb
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 21:40:45 2016 +0100

    #162 refactor entitiyType

commit c15633f0a2912b2cf50531c7742ae37b201d1229
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 21:13:59 2016 +0100

    #162 increase default itemCount to 200

commit 21be31a72a59e933006c1ccdc9e372b76a979098
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 20:27:12 2016 +0100

    #162 rename ID to Id

commit 81a39117cb8f9c8d0086c2252c2a3c759488fa4f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 20:13:51 2016 +0100

    #162 rename entityClazz to entityType

commit 6a7f42a8b3f3ef23dc6df3d93ea0c8b69210b5cb
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 17:10:03 2016 +0100

    #162 rename PartitionUnit to PartitionBound

commit 58add35f70ff943c915be7aeaf03b411db1847e7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 16:49:48 2016 +0100

    #162 refactor job context data setup

commit 0e942211a850a0d5c5b6c5a20f6e9a441123a8e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 15:56:51 2016 +0100

    #162 format code according to hibernate-ide-codestyles
    https://github.com/hibernate/hibernate-ide-codestyles

commit d0c9d69f2a702b997d40160f0aba6960fd22c4f8
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 12:10:43 2016 +0100

    #161 use getName() instead of toString()

commit d26d5c9acf9d08d303f1e2f1f728227a66bad87f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 11:15:29 2016 +0100

    #134 rename StepContextData to PartitionContextData
    to provide a better understanding

commit f4983aacf9b14faebcbe8f553eb68d5182caea0a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 17:37:12 2016 +0100

    #134 persist indexing progress using `setPersistentData`

commit 3dd8b30bbaf623acddd3f240a9a0ca3583a5b488
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 12:48:42 2016 +0100

    #134 fix indexing progress error: avoid storing increment

commit a2c5ffcb60e99eff7245bd4999d81079f31db4e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 12:10:29 2016 +0100

    #134 delete unused attributes
    `isRestarted` and `rowsToIndex`

commit f4bcbd422a735364b9f90f71f1e1bf198d983eb5
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 11:22:37 2016 +0100

    #134 refactor process of indexing-progress-monitoring

commit 3c6b1d373a5096f993a77198e239acbe7a7fd844
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Dec 5 21:42:45 2016 +0100

    #134 add class StepProgress, storing indexing progress at step level

commit bc037f453f1b25dd86b60f5d3e5e34f3eff584b1
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Dec 2 09:44:05 2016 +0100

    #87 rename lgpl.txt to LICENSE.txt

commit 9ab00469a589cf9bdb118a6f952760c8e555836f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Nov 21 10:59:41 2016 +0100

    #160 add Travis CI status

commit cd5b933953dc4c523541709ccbe0100632823950
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Nov 21 10:50:47 2016 +0100

    #160 set up Travis CI

commit 0229fdb56e9218994cdc4d7793553337ba93d476
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Sep 30 21:39:53 2016 +0200

    #146 misc. enhance & use another test scenario for WF
    which demonstrates the possibility to index recent inserted entities

commit 13bc769a101c8f4cfa53fbe46433abdae2047a98
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 16:29:48 2016 +0200

    #133 type and naming enhancement

commit b7ca7eab62eec0457ee56586c66c90946364c6f0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 15:44:26 2016 +0200

    #151 rename "massIndex" / "mass-index" -> "BatchIndexingJob"

commit 031e6a02fabc8fb7ee731fdf3a8258f88aab0e6a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 15:28:17 2016 +0200

    #156 #159 refactor the MassIndexer -> BatchIndexingJob
    - Make a second level Builder class Builder.
    - Avoid using constructor of MassIndexer.
    - Various arguments of type Class<?>, Class<?>... for builder to allow at least 1 argument.
    - Rename MassIndexer to BatchIndexingJob
    - Avoid a static reference to the EMF
    - Update all the test cases according to the changes

commit 950106e036309e24560a599b9132644d3b328e74
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Sep 28 13:26:39 2016 +0200

    #133 the batch insertion counter need to be incremented

commit 4b8f5525a9ab716618bb42f0b90de0e5d77f5ec9
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Sep 27 16:59:52 2016 +0200

    #133 require at least one element for MassIndexer#addRootEntities(...)

commit 556e88e74d5f39212af86712bd767821f7839de0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Sep 27 10:50:42 2016 +0200

    #146 Allow to select the entities through a HQL/JPQL query

commit ff9f4c6dfdee918d4f59d1e4a03b0765105746db
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 25 22:10:50 2016 +0200

    #150 add test for validating the job start/stop in CLI

commit 4258265f34ddb69b0e14c15a9f30d20ca6170b9a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 25 17:37:00 2016 +0200

    #133 rename the war using the class's name

commit 038d53c0ac765f0ebd3826323c8c01a23b9255ad
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 22 17:29:13 2016 +0200

    #136 refactor mocked tests
    Use real EntityManagerFactory instead of mocked one. Batch properties are now passed using a protected args-constructor. After the refactoring, there's no need to use PowerMock anymore.

commit 217d560424171e83864dfe55f6d08d955baeb763
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 18 21:23:13 2016 +0200

    #158 store Object as job property, e.g. Hibernate criterion
    enable selection of entities to be re-indexed through criteria

commit e3a097a7eec8057b9c105684c9ab473645d08d3e
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Sep 16 16:58:44 2016 +0200

    #154 banne caching option for PartitionMapper

commit 3bf541a6ebfd4aa7d10a6d1475e4977a2fbb706d
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 15 18:36:22 2016 +0200

    #153 avoid SNAPSHOT versions among the dependencies

commit de4be0b1478c66237537847d27868059d38e981f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 15 18:09:03 2016 +0200

    #152 use java.lang.String for all the batch properties

commit e4e1ed4a33fcd616ccf5d58e065e77b85bcbf187
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Aug 26 21:46:36 2016 +0200

    #132 remove dummy job xml

commit e52939897253a79320ad471645637275e1e3b6a8
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Aug 26 21:41:38 2016 +0200

    #132 enable the module approach

commit a4fa8430b43ce138180eda8ce682d393ce55f473
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 24 23:47:53 2016 +0200

    #132 enable arquillian-managed WF's debug

commit 188fba5902ca1dc3777048db8039721ada32abb3
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 25 22:57:10 2016 +0200

    #132 WFLY-7000 Batch jobs from installed modules should be detected for non-batch app

commit 68ccad9abb1562f0f8cd0bbdc4b5057469fb7f77
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 24 23:47:53 2016 +0200

    #132 enable arquillian-managed WF's debug

commit 88c2dac3e7a7a7b2f8b7f4cc93d10d197b1b5244
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Aug 22 23:55:34 2016 +0200

    #132 add org.jberet.jberet-core as a module dependency
    to fix unsatisfied dependencies issue

commit 3fb229edb54f78c79208391a722168751b7811e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 15:10:20 2016 +0200

    #132 implement an SPI like this ?

commit c44d5f7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 23:54:34 2016 +0200

    #133 avoid dependence on the existing mass indexer
    for batchlets

commit 5c4add3
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:47:33 2016 +0200

    #143 change log level to INFO

commit e1b8229
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:47:06 2016 +0200

    #143 maven cleanup

commit 3c111e5
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:40:22 2016 +0200

    #140 change project version to 1.0

commit 1070a6d
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:08:44 2016 +0200

    #143 add issue management

commit 5ae4508
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:03:48 2016 +0200

    #143 maven clean up

commit e9bad75
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 20:59:43 2016 +0200

    #143 add license and developers info

commit 1b9f491
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 20:41:07 2016 +0200

    #139 separate simple integration test and performance test

commit 3a18b7b
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 18:43:59 2016 +0200

    #143 delete profiles

commit 35d8ba7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 18:40:53 2016 +0200

    #143 revert WF module installation approach

commit a78086f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 17:27:29 2016 +0200

    #143 rename maven module javaee-wildfly to wildfly

commit d9fadc8
Merge: 50908f9 ca09828
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 21:15:00 2016 +0200

    #132 import meta-inf from dependency

commit 50908f9
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 02:06:07 2016 +0200

    #132 update for IT

commit 576f105
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 17 23:50:36 2016 +0200

    #132 package batch job as module for WildFly

commit ca09828
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 02:06:07 2016 +0200

    #132 update for IT

commit 69440de
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 17 23:50:36 2016 +0200

    #132 package batch job as module for WildFly
360d8a3

@yrodiere yrodiere added a commit to yrodiere/hibernate-search that referenced this pull request Feb 20, 2017

@yrodiere yrodiere Squashed commit - RENAME ME
This commit has been extracted from https://github.com/mincong-h/gsoc-hsearch/tree/master/
It is the result of squashing commits
94dc13e12b8477b357a4d6fcb3bff3008813e73a to 6a9df85c0d7351d83e05cc7062b9a18fbb6b3701
(see git log below).

commit 6a9df85c0d7351d83e05cc7062b9a18fbb6b3701
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Thu Jan 12 13:05:47 2017 +0100

    Fix a NPE when the conversion from EntityManagerFactory to SessionFactory fails

commit 596454f6d6bdfe89cf99646033e5b6a2b38d5934
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 17:35:15 2017 +0100

    Fix the dependencies in the WildFly module

commit f25e3a21327d301bae3f4f31a0062924a6f85f0a
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 17:31:41 2017 +0100

    Align the project version on the Hibernate Search version

    This avoids some weird issues with snippets of poms copied over
    from Hibernate Search.

commit 4830e5cf19a33a267c8bf7927910e0c21cda3d1c
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 11:43:39 2017 +0100

    Upgrade to Hibernate Search 5.7.0.Beta2 / Hibernate ORM 5.2.1.Final

    This will make it easier to work with SessionFactory if we have to,
    because starting from Hibernate ORM 5.2 SessionFactory extends
    EntityManagerFactory.

commit c903608a10f3c3db7db34ffbc693edcf7499d6a6
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Tue Jan 10 10:14:39 2017 +0100

    Reduce the use of JobSEEnvironment and @PersistenceUnit to a minimum

    That's because:

     * JobSEEnvironment will have to be replaced by something else, see #156 .
     * Injected persistence units do not work when CDI is disabled, so we
       might as well only use it where it is absolutely necessary.

commit 65aa7fec8d2a0e5c35f600cb5bad9ef822a08d45
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 14:48:46 2017 +0100

    i178 Remove "jobContextData" from the job parameters

commit db591e1c02deb1295306c9fdb7fb0bcb7cc85945
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 16:18:48 2017 +0100

    Add missing "static" keywords

commit 94dc13e12b8477b357a4d6fcb3bff3008813e73a
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 15:17:29 2017 +0100

    Also run integration tests in travis
e912577

@yrodiere yrodiere added a commit to yrodiere/hibernate-search that referenced this pull request Feb 20, 2017

@mincong-h @yrodiere mincong-h + yrodiere HSEARCH-2594 Initial work on JSR-352 - third part
This commit has been extracted from https://github.com/mincong-h/gsoc-hsearch/tree/master/
It is the result of squashing commits
576f105 to 40aff727a4ca70dd809ca72dcb6315d71f80a37f
(see git log below).

commit 40aff727a4ca70dd809ca72dcb6315d71f80a37f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 23:18:43 2017 +0100

    #168 test batch job runnability over a poorly-formed entity
    It has multiple ID-like fields, which make it difficult to identify the real identifier.

commit 3cd83d9b5d9c055ee133d66a5af7e9c027a572dc
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 22:22:33 2017 +0100

    #165 delete unused import

commit 58fabd11044b64f82f69432061fe1a37ad8967a4
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 21:55:17 2017 +0100

    #165 remove duplicate ID projection

commit d0c23f934851866ecfc797c889a9c3f69971208c
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 21:49:01 2017 +0100

    #165 avoid using toString() method

commit 15d2952a30d14384ed9a1a514b7a9a72b2d30ae6
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Jan 3 22:34:49 2017 +0100

    #165 use `Projections#id()`
    instead of `DocumentBuilderIndexedEntity#getIdPropertyName()` to avoid null reference issue for provided IDs.

commit 89624d52f7b6b955bbf45d576b538b8fc93445fb
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 21:40:45 2016 +0100

    #162 refactor entitiyType

commit c15633f0a2912b2cf50531c7742ae37b201d1229
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 21:13:59 2016 +0100

    #162 increase default itemCount to 200

commit 21be31a72a59e933006c1ccdc9e372b76a979098
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 20:27:12 2016 +0100

    #162 rename ID to Id

commit 81a39117cb8f9c8d0086c2252c2a3c759488fa4f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 20:13:51 2016 +0100

    #162 rename entityClazz to entityType

commit 6a7f42a8b3f3ef23dc6df3d93ea0c8b69210b5cb
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 17:10:03 2016 +0100

    #162 rename PartitionUnit to PartitionBound

commit 58add35f70ff943c915be7aeaf03b411db1847e7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 16:49:48 2016 +0100

    #162 refactor job context data setup

commit 0e942211a850a0d5c5b6c5a20f6e9a441123a8e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 15:56:51 2016 +0100

    #162 format code according to hibernate-ide-codestyles
    https://github.com/hibernate/hibernate-ide-codestyles

commit d0c9d69f2a702b997d40160f0aba6960fd22c4f8
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 12:10:43 2016 +0100

    #161 use getName() instead of toString()

commit d26d5c9acf9d08d303f1e2f1f728227a66bad87f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 11:15:29 2016 +0100

    #134 rename StepContextData to PartitionContextData
    to provide a better understanding

commit f4983aacf9b14faebcbe8f553eb68d5182caea0a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 17:37:12 2016 +0100

    #134 persist indexing progress using `setPersistentData`

commit 3dd8b30bbaf623acddd3f240a9a0ca3583a5b488
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 12:48:42 2016 +0100

    #134 fix indexing progress error: avoid storing increment

commit a2c5ffcb60e99eff7245bd4999d81079f31db4e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 12:10:29 2016 +0100

    #134 delete unused attributes
    `isRestarted` and `rowsToIndex`

commit f4bcbd422a735364b9f90f71f1e1bf198d983eb5
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 11:22:37 2016 +0100

    #134 refactor process of indexing-progress-monitoring

commit 3c6b1d373a5096f993a77198e239acbe7a7fd844
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Dec 5 21:42:45 2016 +0100

    #134 add class StepProgress, storing indexing progress at step level

commit bc037f453f1b25dd86b60f5d3e5e34f3eff584b1
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Dec 2 09:44:05 2016 +0100

    #87 rename lgpl.txt to LICENSE.txt

commit 9ab00469a589cf9bdb118a6f952760c8e555836f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Nov 21 10:59:41 2016 +0100

    #160 add Travis CI status

commit cd5b933953dc4c523541709ccbe0100632823950
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Nov 21 10:50:47 2016 +0100

    #160 set up Travis CI

commit 0229fdb56e9218994cdc4d7793553337ba93d476
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Sep 30 21:39:53 2016 +0200

    #146 misc. enhance & use another test scenario for WF
    which demonstrates the possibility to index recent inserted entities

commit 13bc769a101c8f4cfa53fbe46433abdae2047a98
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 16:29:48 2016 +0200

    #133 type and naming enhancement

commit b7ca7eab62eec0457ee56586c66c90946364c6f0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 15:44:26 2016 +0200

    #151 rename "massIndex" / "mass-index" -> "BatchIndexingJob"

commit 031e6a02fabc8fb7ee731fdf3a8258f88aab0e6a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 15:28:17 2016 +0200

    #156 #159 refactor the MassIndexer -> BatchIndexingJob
    - Make a second level Builder class Builder.
    - Avoid using constructor of MassIndexer.
    - Various arguments of type Class<?>, Class<?>... for builder to allow at least 1 argument.
    - Rename MassIndexer to BatchIndexingJob
    - Avoid a static reference to the EMF
    - Update all the test cases according to the changes

commit 950106e036309e24560a599b9132644d3b328e74
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Sep 28 13:26:39 2016 +0200

    #133 the batch insertion counter need to be incremented

commit 4b8f5525a9ab716618bb42f0b90de0e5d77f5ec9
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Sep 27 16:59:52 2016 +0200

    #133 require at least one element for MassIndexer#addRootEntities(...)

commit 556e88e74d5f39212af86712bd767821f7839de0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Sep 27 10:50:42 2016 +0200

    #146 Allow to select the entities through a HQL/JPQL query

commit ff9f4c6dfdee918d4f59d1e4a03b0765105746db
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 25 22:10:50 2016 +0200

    #150 add test for validating the job start/stop in CLI

commit 4258265f34ddb69b0e14c15a9f30d20ca6170b9a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 25 17:37:00 2016 +0200

    #133 rename the war using the class's name

commit 038d53c0ac765f0ebd3826323c8c01a23b9255ad
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 22 17:29:13 2016 +0200

    #136 refactor mocked tests
    Use real EntityManagerFactory instead of mocked one. Batch properties are now passed using a protected args-constructor. After the refactoring, there's no need to use PowerMock anymore.

commit 217d560424171e83864dfe55f6d08d955baeb763
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 18 21:23:13 2016 +0200

    #158 store Object as job property, e.g. Hibernate criterion
    enable selection of entities to be re-indexed through criteria

commit e3a097a7eec8057b9c105684c9ab473645d08d3e
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Sep 16 16:58:44 2016 +0200

    #154 banne caching option for PartitionMapper

commit 3bf541a6ebfd4aa7d10a6d1475e4977a2fbb706d
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 15 18:36:22 2016 +0200

    #153 avoid SNAPSHOT versions among the dependencies

commit de4be0b1478c66237537847d27868059d38e981f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 15 18:09:03 2016 +0200

    #152 use java.lang.String for all the batch properties

commit e4e1ed4a33fcd616ccf5d58e065e77b85bcbf187
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Aug 26 21:46:36 2016 +0200

    #132 remove dummy job xml

commit e52939897253a79320ad471645637275e1e3b6a8
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Aug 26 21:41:38 2016 +0200

    #132 enable the module approach

commit a4fa8430b43ce138180eda8ce682d393ce55f473
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 24 23:47:53 2016 +0200

    #132 enable arquillian-managed WF's debug

commit 188fba5902ca1dc3777048db8039721ada32abb3
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 25 22:57:10 2016 +0200

    #132 WFLY-7000 Batch jobs from installed modules should be detected for non-batch app

commit 68ccad9abb1562f0f8cd0bbdc4b5057469fb7f77
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 24 23:47:53 2016 +0200

    #132 enable arquillian-managed WF's debug

commit 88c2dac3e7a7a7b2f8b7f4cc93d10d197b1b5244
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Aug 22 23:55:34 2016 +0200

    #132 add org.jberet.jberet-core as a module dependency
    to fix unsatisfied dependencies issue

commit 3fb229edb54f78c79208391a722168751b7811e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 15:10:20 2016 +0200

    #132 implement an SPI like this ?

commit c44d5f7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 23:54:34 2016 +0200

    #133 avoid dependence on the existing mass indexer
    for batchlets

commit 5c4add3
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:47:33 2016 +0200

    #143 change log level to INFO

commit e1b8229
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:47:06 2016 +0200

    #143 maven cleanup

commit 3c111e5
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:40:22 2016 +0200

    #140 change project version to 1.0

commit 1070a6d
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:08:44 2016 +0200

    #143 add issue management

commit 5ae4508
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:03:48 2016 +0200

    #143 maven clean up

commit e9bad75
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 20:59:43 2016 +0200

    #143 add license and developers info

commit 1b9f491
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 20:41:07 2016 +0200

    #139 separate simple integration test and performance test

commit 3a18b7b
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 18:43:59 2016 +0200

    #143 delete profiles

commit 35d8ba7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 18:40:53 2016 +0200

    #143 revert WF module installation approach

commit a78086f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 17:27:29 2016 +0200

    #143 rename maven module javaee-wildfly to wildfly

commit d9fadc8
Merge: 50908f9 ca09828
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 21:15:00 2016 +0200

    #132 import meta-inf from dependency

commit 50908f9
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 02:06:07 2016 +0200

    #132 update for IT

commit 576f105
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 17 23:50:36 2016 +0200

    #132 package batch job as module for WildFly

commit ca09828
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 02:06:07 2016 +0200

    #132 update for IT

commit 69440de
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 17 23:50:36 2016 +0200

    #132 package batch job as module for WildFly
ba3d35d

@yrodiere yrodiere added a commit to yrodiere/hibernate-search that referenced this pull request Feb 20, 2017

@yrodiere yrodiere HSEARCH-2594 Adjustments on JSR-352 integration
This commit has been extracted from https://github.com/mincong-h/gsoc-hsearch/tree/master/
It is the result of squashing commits
94dc13e12b8477b357a4d6fcb3bff3008813e73a to 6a9df85c0d7351d83e05cc7062b9a18fbb6b3701
(see git log below).

commit 6a9df85c0d7351d83e05cc7062b9a18fbb6b3701
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Thu Jan 12 13:05:47 2017 +0100

    Fix a NPE when the conversion from EntityManagerFactory to SessionFactory fails

commit 596454f6d6bdfe89cf99646033e5b6a2b38d5934
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 17:35:15 2017 +0100

    Fix the dependencies in the WildFly module

commit f25e3a21327d301bae3f4f31a0062924a6f85f0a
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 17:31:41 2017 +0100

    Align the project version on the Hibernate Search version

    This avoids some weird issues with snippets of poms copied over
    from Hibernate Search.

commit 4830e5cf19a33a267c8bf7927910e0c21cda3d1c
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 11:43:39 2017 +0100

    Upgrade to Hibernate Search 5.7.0.Beta2 / Hibernate ORM 5.2.1.Final

    This will make it easier to work with SessionFactory if we have to,
    because starting from Hibernate ORM 5.2 SessionFactory extends
    EntityManagerFactory.

commit c903608a10f3c3db7db34ffbc693edcf7499d6a6
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Tue Jan 10 10:14:39 2017 +0100

    Reduce the use of JobSEEnvironment and @PersistenceUnit to a minimum

    That's because:

     * JobSEEnvironment will have to be replaced by something else, see #156 .
     * Injected persistence units do not work when CDI is disabled, so we
       might as well only use it where it is absolutely necessary.

commit 65aa7fec8d2a0e5c35f600cb5bad9ef822a08d45
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 14:48:46 2017 +0100

    i178 Remove "jobContextData" from the job parameters

commit db591e1c02deb1295306c9fdb7fb0bcb7cc85945
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 16:18:48 2017 +0100

    Add missing "static" keywords

commit 94dc13e12b8477b357a4d6fcb3bff3008813e73a
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 15:17:29 2017 +0100

    Also run integration tests in travis
4c3251c

@yrodiere yrodiere added a commit to yrodiere/hibernate-search that referenced this pull request Feb 20, 2017

@mincong-h @yrodiere mincong-h + yrodiere HSEARCH-2594 Initial work on JSR-352 - third part
This commit has been extracted from https://github.com/mincong-h/gsoc-hsearch/tree/master/
It is the result of squashing commits
576f105 to 40aff727a4ca70dd809ca72dcb6315d71f80a37f
(see git log below).

commit 40aff727a4ca70dd809ca72dcb6315d71f80a37f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 23:18:43 2017 +0100

    #168 test batch job runnability over a poorly-formed entity
    It has multiple ID-like fields, which make it difficult to identify the real identifier.

commit 3cd83d9b5d9c055ee133d66a5af7e9c027a572dc
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 22:22:33 2017 +0100

    #165 delete unused import

commit 58fabd11044b64f82f69432061fe1a37ad8967a4
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 21:55:17 2017 +0100

    #165 remove duplicate ID projection

commit d0c23f934851866ecfc797c889a9c3f69971208c
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 21:49:01 2017 +0100

    #165 avoid using toString() method

commit 15d2952a30d14384ed9a1a514b7a9a72b2d30ae6
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Jan 3 22:34:49 2017 +0100

    #165 use `Projections#id()`
    instead of `DocumentBuilderIndexedEntity#getIdPropertyName()` to avoid null reference issue for provided IDs.

commit 89624d52f7b6b955bbf45d576b538b8fc93445fb
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 21:40:45 2016 +0100

    #162 refactor entitiyType

commit c15633f0a2912b2cf50531c7742ae37b201d1229
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 21:13:59 2016 +0100

    #162 increase default itemCount to 200

commit 21be31a72a59e933006c1ccdc9e372b76a979098
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 20:27:12 2016 +0100

    #162 rename ID to Id

commit 81a39117cb8f9c8d0086c2252c2a3c759488fa4f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 20:13:51 2016 +0100

    #162 rename entityClazz to entityType

commit 6a7f42a8b3f3ef23dc6df3d93ea0c8b69210b5cb
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 17:10:03 2016 +0100

    #162 rename PartitionUnit to PartitionBound

commit 58add35f70ff943c915be7aeaf03b411db1847e7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 16:49:48 2016 +0100

    #162 refactor job context data setup

commit 0e942211a850a0d5c5b6c5a20f6e9a441123a8e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 15:56:51 2016 +0100

    #162 format code according to hibernate-ide-codestyles
    https://github.com/hibernate/hibernate-ide-codestyles

commit d0c9d69f2a702b997d40160f0aba6960fd22c4f8
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 12:10:43 2016 +0100

    #161 use getName() instead of toString()

commit d26d5c9acf9d08d303f1e2f1f728227a66bad87f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 11:15:29 2016 +0100

    #134 rename StepContextData to PartitionContextData
    to provide a better understanding

commit f4983aacf9b14faebcbe8f553eb68d5182caea0a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 17:37:12 2016 +0100

    #134 persist indexing progress using `setPersistentData`

commit 3dd8b30bbaf623acddd3f240a9a0ca3583a5b488
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 12:48:42 2016 +0100

    #134 fix indexing progress error: avoid storing increment

commit a2c5ffcb60e99eff7245bd4999d81079f31db4e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 12:10:29 2016 +0100

    #134 delete unused attributes
    `isRestarted` and `rowsToIndex`

commit f4bcbd422a735364b9f90f71f1e1bf198d983eb5
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 11:22:37 2016 +0100

    #134 refactor process of indexing-progress-monitoring

commit 3c6b1d373a5096f993a77198e239acbe7a7fd844
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Dec 5 21:42:45 2016 +0100

    #134 add class StepProgress, storing indexing progress at step level

commit bc037f453f1b25dd86b60f5d3e5e34f3eff584b1
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Dec 2 09:44:05 2016 +0100

    #87 rename lgpl.txt to LICENSE.txt

commit 9ab00469a589cf9bdb118a6f952760c8e555836f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Nov 21 10:59:41 2016 +0100

    #160 add Travis CI status

commit cd5b933953dc4c523541709ccbe0100632823950
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Nov 21 10:50:47 2016 +0100

    #160 set up Travis CI

commit 0229fdb56e9218994cdc4d7793553337ba93d476
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Sep 30 21:39:53 2016 +0200

    #146 misc. enhance & use another test scenario for WF
    which demonstrates the possibility to index recent inserted entities

commit 13bc769a101c8f4cfa53fbe46433abdae2047a98
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 16:29:48 2016 +0200

    #133 type and naming enhancement

commit b7ca7eab62eec0457ee56586c66c90946364c6f0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 15:44:26 2016 +0200

    #151 rename "massIndex" / "mass-index" -> "BatchIndexingJob"

commit 031e6a02fabc8fb7ee731fdf3a8258f88aab0e6a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 15:28:17 2016 +0200

    #156 #159 refactor the MassIndexer -> BatchIndexingJob
    - Make a second level Builder class Builder.
    - Avoid using constructor of MassIndexer.
    - Various arguments of type Class<?>, Class<?>... for builder to allow at least 1 argument.
    - Rename MassIndexer to BatchIndexingJob
    - Avoid a static reference to the EMF
    - Update all the test cases according to the changes

commit 950106e036309e24560a599b9132644d3b328e74
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Sep 28 13:26:39 2016 +0200

    #133 the batch insertion counter need to be incremented

commit 4b8f5525a9ab716618bb42f0b90de0e5d77f5ec9
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Sep 27 16:59:52 2016 +0200

    #133 require at least one element for MassIndexer#addRootEntities(...)

commit 556e88e74d5f39212af86712bd767821f7839de0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Sep 27 10:50:42 2016 +0200

    #146 Allow to select the entities through a HQL/JPQL query

commit ff9f4c6dfdee918d4f59d1e4a03b0765105746db
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 25 22:10:50 2016 +0200

    #150 add test for validating the job start/stop in CLI

commit 4258265f34ddb69b0e14c15a9f30d20ca6170b9a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 25 17:37:00 2016 +0200

    #133 rename the war using the class's name

commit 038d53c0ac765f0ebd3826323c8c01a23b9255ad
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 22 17:29:13 2016 +0200

    #136 refactor mocked tests
    Use real EntityManagerFactory instead of mocked one. Batch properties are now passed using a protected args-constructor. After the refactoring, there's no need to use PowerMock anymore.

commit 217d560424171e83864dfe55f6d08d955baeb763
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 18 21:23:13 2016 +0200

    #158 store Object as job property, e.g. Hibernate criterion
    enable selection of entities to be re-indexed through criteria

commit e3a097a7eec8057b9c105684c9ab473645d08d3e
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Sep 16 16:58:44 2016 +0200

    #154 banne caching option for PartitionMapper

commit 3bf541a6ebfd4aa7d10a6d1475e4977a2fbb706d
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 15 18:36:22 2016 +0200

    #153 avoid SNAPSHOT versions among the dependencies

commit de4be0b1478c66237537847d27868059d38e981f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 15 18:09:03 2016 +0200

    #152 use java.lang.String for all the batch properties

commit e4e1ed4a33fcd616ccf5d58e065e77b85bcbf187
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Aug 26 21:46:36 2016 +0200

    #132 remove dummy job xml

commit e52939897253a79320ad471645637275e1e3b6a8
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Aug 26 21:41:38 2016 +0200

    #132 enable the module approach

commit a4fa8430b43ce138180eda8ce682d393ce55f473
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 24 23:47:53 2016 +0200

    #132 enable arquillian-managed WF's debug

commit 188fba5902ca1dc3777048db8039721ada32abb3
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 25 22:57:10 2016 +0200

    #132 WFLY-7000 Batch jobs from installed modules should be detected for non-batch app

commit 68ccad9abb1562f0f8cd0bbdc4b5057469fb7f77
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 24 23:47:53 2016 +0200

    #132 enable arquillian-managed WF's debug

commit 88c2dac3e7a7a7b2f8b7f4cc93d10d197b1b5244
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Aug 22 23:55:34 2016 +0200

    #132 add org.jberet.jberet-core as a module dependency
    to fix unsatisfied dependencies issue

commit 3fb229edb54f78c79208391a722168751b7811e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 15:10:20 2016 +0200

    #132 implement an SPI like this ?

commit c44d5f7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 23:54:34 2016 +0200

    #133 avoid dependence on the existing mass indexer
    for batchlets

commit 5c4add3
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:47:33 2016 +0200

    #143 change log level to INFO

commit e1b8229
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:47:06 2016 +0200

    #143 maven cleanup

commit 3c111e5
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:40:22 2016 +0200

    #140 change project version to 1.0

commit 1070a6d
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:08:44 2016 +0200

    #143 add issue management

commit 5ae4508
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:03:48 2016 +0200

    #143 maven clean up

commit e9bad75
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 20:59:43 2016 +0200

    #143 add license and developers info

commit 1b9f491
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 20:41:07 2016 +0200

    #139 separate simple integration test and performance test

commit 3a18b7b
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 18:43:59 2016 +0200

    #143 delete profiles

commit 35d8ba7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 18:40:53 2016 +0200

    #143 revert WF module installation approach

commit a78086f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 17:27:29 2016 +0200

    #143 rename maven module javaee-wildfly to wildfly

commit d9fadc8
Merge: 50908f9 ca09828
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 21:15:00 2016 +0200

    #132 import meta-inf from dependency

commit 50908f9
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 02:06:07 2016 +0200

    #132 update for IT

commit 576f105
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 17 23:50:36 2016 +0200

    #132 package batch job as module for WildFly

commit ca09828
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 02:06:07 2016 +0200

    #132 update for IT

commit 69440de
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 17 23:50:36 2016 +0200

    #132 package batch job as module for WildFly
6230393

@yrodiere yrodiere added a commit to yrodiere/hibernate-search that referenced this pull request Feb 20, 2017

@yrodiere yrodiere HSEARCH-2594 Adjustments on JSR-352 integration
This commit has been extracted from https://github.com/mincong-h/gsoc-hsearch/tree/master/
It is the result of squashing commits
94dc13e12b8477b357a4d6fcb3bff3008813e73a to 6a9df85c0d7351d83e05cc7062b9a18fbb6b3701
(see git log below).

commit 6a9df85c0d7351d83e05cc7062b9a18fbb6b3701
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Thu Jan 12 13:05:47 2017 +0100

    Fix a NPE when the conversion from EntityManagerFactory to SessionFactory fails

commit 596454f6d6bdfe89cf99646033e5b6a2b38d5934
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 17:35:15 2017 +0100

    Fix the dependencies in the WildFly module

commit f25e3a21327d301bae3f4f31a0062924a6f85f0a
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 17:31:41 2017 +0100

    Align the project version on the Hibernate Search version

    This avoids some weird issues with snippets of poms copied over
    from Hibernate Search.

commit 4830e5cf19a33a267c8bf7927910e0c21cda3d1c
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 11:43:39 2017 +0100

    Upgrade to Hibernate Search 5.7.0.Beta2 / Hibernate ORM 5.2.1.Final

    This will make it easier to work with SessionFactory if we have to,
    because starting from Hibernate ORM 5.2 SessionFactory extends
    EntityManagerFactory.

commit c903608a10f3c3db7db34ffbc693edcf7499d6a6
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Tue Jan 10 10:14:39 2017 +0100

    Reduce the use of JobSEEnvironment and @PersistenceUnit to a minimum

    That's because:

     * JobSEEnvironment will have to be replaced by something else, see #156 .
     * Injected persistence units do not work when CDI is disabled, so we
       might as well only use it where it is absolutely necessary.

commit 65aa7fec8d2a0e5c35f600cb5bad9ef822a08d45
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 14:48:46 2017 +0100

    i178 Remove "jobContextData" from the job parameters

commit db591e1c02deb1295306c9fdb7fb0bcb7cc85945
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 16:18:48 2017 +0100

    Add missing "static" keywords

commit 94dc13e12b8477b357a4d6fcb3bff3008813e73a
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 15:17:29 2017 +0100

    Also run integration tests in travis
772aea8

@yrodiere yrodiere added a commit to yrodiere/hibernate-search that referenced this pull request Feb 20, 2017

@mincong-h @yrodiere mincong-h + yrodiere HSEARCH-2594 Initial work on JSR-352 - third part
This commit has been extracted from https://github.com/mincong-h/gsoc-hsearch/tree/master/
It is the result of squashing commits
576f105 to 40aff727a4ca70dd809ca72dcb6315d71f80a37f
(see git log below).

commit 40aff727a4ca70dd809ca72dcb6315d71f80a37f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 23:18:43 2017 +0100

    #168 test batch job runnability over a poorly-formed entity
    It has multiple ID-like fields, which make it difficult to identify the real identifier.

commit 3cd83d9b5d9c055ee133d66a5af7e9c027a572dc
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 22:22:33 2017 +0100

    #165 delete unused import

commit 58fabd11044b64f82f69432061fe1a37ad8967a4
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 21:55:17 2017 +0100

    #165 remove duplicate ID projection

commit d0c23f934851866ecfc797c889a9c3f69971208c
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 21:49:01 2017 +0100

    #165 avoid using toString() method

commit 15d2952a30d14384ed9a1a514b7a9a72b2d30ae6
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Jan 3 22:34:49 2017 +0100

    #165 use `Projections#id()`
    instead of `DocumentBuilderIndexedEntity#getIdPropertyName()` to avoid null reference issue for provided IDs.

commit 89624d52f7b6b955bbf45d576b538b8fc93445fb
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 21:40:45 2016 +0100

    #162 refactor entitiyType

commit c15633f0a2912b2cf50531c7742ae37b201d1229
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 21:13:59 2016 +0100

    #162 increase default itemCount to 200

commit 21be31a72a59e933006c1ccdc9e372b76a979098
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 20:27:12 2016 +0100

    #162 rename ID to Id

commit 81a39117cb8f9c8d0086c2252c2a3c759488fa4f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 20:13:51 2016 +0100

    #162 rename entityClazz to entityType

commit 6a7f42a8b3f3ef23dc6df3d93ea0c8b69210b5cb
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 17:10:03 2016 +0100

    #162 rename PartitionUnit to PartitionBound

commit 58add35f70ff943c915be7aeaf03b411db1847e7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 16:49:48 2016 +0100

    #162 refactor job context data setup

commit 0e942211a850a0d5c5b6c5a20f6e9a441123a8e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 15:56:51 2016 +0100

    #162 format code according to hibernate-ide-codestyles
    https://github.com/hibernate/hibernate-ide-codestyles

commit d0c9d69f2a702b997d40160f0aba6960fd22c4f8
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 12:10:43 2016 +0100

    #161 use getName() instead of toString()

commit d26d5c9acf9d08d303f1e2f1f728227a66bad87f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 11:15:29 2016 +0100

    #134 rename StepContextData to PartitionContextData
    to provide a better understanding

commit f4983aacf9b14faebcbe8f553eb68d5182caea0a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 17:37:12 2016 +0100

    #134 persist indexing progress using `setPersistentData`

commit 3dd8b30bbaf623acddd3f240a9a0ca3583a5b488
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 12:48:42 2016 +0100

    #134 fix indexing progress error: avoid storing increment

commit a2c5ffcb60e99eff7245bd4999d81079f31db4e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 12:10:29 2016 +0100

    #134 delete unused attributes
    `isRestarted` and `rowsToIndex`

commit f4bcbd422a735364b9f90f71f1e1bf198d983eb5
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 11:22:37 2016 +0100

    #134 refactor process of indexing-progress-monitoring

commit 3c6b1d373a5096f993a77198e239acbe7a7fd844
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Dec 5 21:42:45 2016 +0100

    #134 add class StepProgress, storing indexing progress at step level

commit bc037f453f1b25dd86b60f5d3e5e34f3eff584b1
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Dec 2 09:44:05 2016 +0100

    #87 rename lgpl.txt to LICENSE.txt

commit 9ab00469a589cf9bdb118a6f952760c8e555836f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Nov 21 10:59:41 2016 +0100

    #160 add Travis CI status

commit cd5b933953dc4c523541709ccbe0100632823950
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Nov 21 10:50:47 2016 +0100

    #160 set up Travis CI

commit 0229fdb56e9218994cdc4d7793553337ba93d476
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Sep 30 21:39:53 2016 +0200

    #146 misc. enhance & use another test scenario for WF
    which demonstrates the possibility to index recent inserted entities

commit 13bc769a101c8f4cfa53fbe46433abdae2047a98
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 16:29:48 2016 +0200

    #133 type and naming enhancement

commit b7ca7eab62eec0457ee56586c66c90946364c6f0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 15:44:26 2016 +0200

    #151 rename "massIndex" / "mass-index" -> "BatchIndexingJob"

commit 031e6a02fabc8fb7ee731fdf3a8258f88aab0e6a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 15:28:17 2016 +0200

    #156 #159 refactor the MassIndexer -> BatchIndexingJob
    - Make a second level Builder class Builder.
    - Avoid using constructor of MassIndexer.
    - Various arguments of type Class<?>, Class<?>... for builder to allow at least 1 argument.
    - Rename MassIndexer to BatchIndexingJob
    - Avoid a static reference to the EMF
    - Update all the test cases according to the changes

commit 950106e036309e24560a599b9132644d3b328e74
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Sep 28 13:26:39 2016 +0200

    #133 the batch insertion counter need to be incremented

commit 4b8f5525a9ab716618bb42f0b90de0e5d77f5ec9
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Sep 27 16:59:52 2016 +0200

    #133 require at least one element for MassIndexer#addRootEntities(...)

commit 556e88e74d5f39212af86712bd767821f7839de0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Sep 27 10:50:42 2016 +0200

    #146 Allow to select the entities through a HQL/JPQL query

commit ff9f4c6dfdee918d4f59d1e4a03b0765105746db
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 25 22:10:50 2016 +0200

    #150 add test for validating the job start/stop in CLI

commit 4258265f34ddb69b0e14c15a9f30d20ca6170b9a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 25 17:37:00 2016 +0200

    #133 rename the war using the class's name

commit 038d53c0ac765f0ebd3826323c8c01a23b9255ad
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 22 17:29:13 2016 +0200

    #136 refactor mocked tests
    Use real EntityManagerFactory instead of mocked one. Batch properties are now passed using a protected args-constructor. After the refactoring, there's no need to use PowerMock anymore.

commit 217d560424171e83864dfe55f6d08d955baeb763
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 18 21:23:13 2016 +0200

    #158 store Object as job property, e.g. Hibernate criterion
    enable selection of entities to be re-indexed through criteria

commit e3a097a7eec8057b9c105684c9ab473645d08d3e
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Sep 16 16:58:44 2016 +0200

    #154 banne caching option for PartitionMapper

commit 3bf541a6ebfd4aa7d10a6d1475e4977a2fbb706d
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 15 18:36:22 2016 +0200

    #153 avoid SNAPSHOT versions among the dependencies

commit de4be0b1478c66237537847d27868059d38e981f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 15 18:09:03 2016 +0200

    #152 use java.lang.String for all the batch properties

commit e4e1ed4a33fcd616ccf5d58e065e77b85bcbf187
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Aug 26 21:46:36 2016 +0200

    #132 remove dummy job xml

commit e52939897253a79320ad471645637275e1e3b6a8
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Aug 26 21:41:38 2016 +0200

    #132 enable the module approach

commit a4fa8430b43ce138180eda8ce682d393ce55f473
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 24 23:47:53 2016 +0200

    #132 enable arquillian-managed WF's debug

commit 188fba5902ca1dc3777048db8039721ada32abb3
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 25 22:57:10 2016 +0200

    #132 WFLY-7000 Batch jobs from installed modules should be detected for non-batch app

commit 68ccad9abb1562f0f8cd0bbdc4b5057469fb7f77
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 24 23:47:53 2016 +0200

    #132 enable arquillian-managed WF's debug

commit 88c2dac3e7a7a7b2f8b7f4cc93d10d197b1b5244
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Aug 22 23:55:34 2016 +0200

    #132 add org.jberet.jberet-core as a module dependency
    to fix unsatisfied dependencies issue

commit 3fb229edb54f78c79208391a722168751b7811e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 15:10:20 2016 +0200

    #132 implement an SPI like this ?

commit c44d5f7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 23:54:34 2016 +0200

    #133 avoid dependence on the existing mass indexer
    for batchlets

commit 5c4add3
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:47:33 2016 +0200

    #143 change log level to INFO

commit e1b8229
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:47:06 2016 +0200

    #143 maven cleanup

commit 3c111e5
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:40:22 2016 +0200

    #140 change project version to 1.0

commit 1070a6d
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:08:44 2016 +0200

    #143 add issue management

commit 5ae4508
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:03:48 2016 +0200

    #143 maven clean up

commit e9bad75
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 20:59:43 2016 +0200

    #143 add license and developers info

commit 1b9f491
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 20:41:07 2016 +0200

    #139 separate simple integration test and performance test

commit 3a18b7b
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 18:43:59 2016 +0200

    #143 delete profiles

commit 35d8ba7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 18:40:53 2016 +0200

    #143 revert WF module installation approach

commit a78086f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 17:27:29 2016 +0200

    #143 rename maven module javaee-wildfly to wildfly

commit d9fadc8
Merge: 50908f9 ca09828
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 21:15:00 2016 +0200

    #132 import meta-inf from dependency

commit 50908f9
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 02:06:07 2016 +0200

    #132 update for IT

commit 576f105
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 17 23:50:36 2016 +0200

    #132 package batch job as module for WildFly

commit ca09828
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 02:06:07 2016 +0200

    #132 update for IT

commit 69440de
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 17 23:50:36 2016 +0200

    #132 package batch job as module for WildFly
7a9a65e

@yrodiere yrodiere added a commit to yrodiere/hibernate-search that referenced this pull request Feb 20, 2017

@yrodiere yrodiere HSEARCH-2594 Adjustments on JSR-352 integration
This commit has been extracted from https://github.com/mincong-h/gsoc-hsearch/tree/master/
It is the result of squashing commits
94dc13e12b8477b357a4d6fcb3bff3008813e73a to 6a9df85c0d7351d83e05cc7062b9a18fbb6b3701
(see git log below).

commit 6a9df85c0d7351d83e05cc7062b9a18fbb6b3701
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Thu Jan 12 13:05:47 2017 +0100

    Fix a NPE when the conversion from EntityManagerFactory to SessionFactory fails

commit 596454f6d6bdfe89cf99646033e5b6a2b38d5934
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 17:35:15 2017 +0100

    Fix the dependencies in the WildFly module

commit f25e3a21327d301bae3f4f31a0062924a6f85f0a
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 17:31:41 2017 +0100

    Align the project version on the Hibernate Search version

    This avoids some weird issues with snippets of poms copied over
    from Hibernate Search.

commit 4830e5cf19a33a267c8bf7927910e0c21cda3d1c
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 11:43:39 2017 +0100

    Upgrade to Hibernate Search 5.7.0.Beta2 / Hibernate ORM 5.2.1.Final

    This will make it easier to work with SessionFactory if we have to,
    because starting from Hibernate ORM 5.2 SessionFactory extends
    EntityManagerFactory.

commit c903608a10f3c3db7db34ffbc693edcf7499d6a6
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Tue Jan 10 10:14:39 2017 +0100

    Reduce the use of JobSEEnvironment and @PersistenceUnit to a minimum

    That's because:

     * JobSEEnvironment will have to be replaced by something else, see #156 .
     * Injected persistence units do not work when CDI is disabled, so we
       might as well only use it where it is absolutely necessary.

commit 65aa7fec8d2a0e5c35f600cb5bad9ef822a08d45
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 14:48:46 2017 +0100

    i178 Remove "jobContextData" from the job parameters

commit db591e1c02deb1295306c9fdb7fb0bcb7cc85945
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 16:18:48 2017 +0100

    Add missing "static" keywords

commit 94dc13e12b8477b357a4d6fcb3bff3008813e73a
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 15:17:29 2017 +0100

    Also run integration tests in travis
0f044cf

@yrodiere yrodiere added a commit to yrodiere/hibernate-search that referenced this pull request May 17, 2017

@mincong-h @yrodiere mincong-h + yrodiere HSEARCH-2594 Initial work on JSR-352 - third part
This commit has been extracted from https://github.com/mincong-h/gsoc-hsearch/tree/master/
It is the result of squashing commits
576f105 to 40aff727a4ca70dd809ca72dcb6315d71f80a37f
(see git log below).

commit 40aff727a4ca70dd809ca72dcb6315d71f80a37f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 23:18:43 2017 +0100

    #168 test batch job runnability over a poorly-formed entity
    It has multiple ID-like fields, which make it difficult to identify the real identifier.

commit 3cd83d9b5d9c055ee133d66a5af7e9c027a572dc
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 22:22:33 2017 +0100

    #165 delete unused import

commit 58fabd11044b64f82f69432061fe1a37ad8967a4
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 21:55:17 2017 +0100

    #165 remove duplicate ID projection

commit d0c23f934851866ecfc797c889a9c3f69971208c
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 21:49:01 2017 +0100

    #165 avoid using toString() method

commit 15d2952a30d14384ed9a1a514b7a9a72b2d30ae6
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Jan 3 22:34:49 2017 +0100

    #165 use `Projections#id()`
    instead of `DocumentBuilderIndexedEntity#getIdPropertyName()` to avoid null reference issue for provided IDs.

commit 89624d52f7b6b955bbf45d576b538b8fc93445fb
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 21:40:45 2016 +0100

    #162 refactor entitiyType

commit c15633f0a2912b2cf50531c7742ae37b201d1229
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 21:13:59 2016 +0100

    #162 increase default itemCount to 200

commit 21be31a72a59e933006c1ccdc9e372b76a979098
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 20:27:12 2016 +0100

    #162 rename ID to Id

commit 81a39117cb8f9c8d0086c2252c2a3c759488fa4f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 20:13:51 2016 +0100

    #162 rename entityClazz to entityType

commit 6a7f42a8b3f3ef23dc6df3d93ea0c8b69210b5cb
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 17:10:03 2016 +0100

    #162 rename PartitionUnit to PartitionBound

commit 58add35f70ff943c915be7aeaf03b411db1847e7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 16:49:48 2016 +0100

    #162 refactor job context data setup

commit 0e942211a850a0d5c5b6c5a20f6e9a441123a8e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 15:56:51 2016 +0100

    #162 format code according to hibernate-ide-codestyles
    https://github.com/hibernate/hibernate-ide-codestyles

commit d0c9d69f2a702b997d40160f0aba6960fd22c4f8
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 12:10:43 2016 +0100

    #161 use getName() instead of toString()

commit d26d5c9acf9d08d303f1e2f1f728227a66bad87f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 11:15:29 2016 +0100

    #134 rename StepContextData to PartitionContextData
    to provide a better understanding

commit f4983aacf9b14faebcbe8f553eb68d5182caea0a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 17:37:12 2016 +0100

    #134 persist indexing progress using `setPersistentData`

commit 3dd8b30bbaf623acddd3f240a9a0ca3583a5b488
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 12:48:42 2016 +0100

    #134 fix indexing progress error: avoid storing increment

commit a2c5ffcb60e99eff7245bd4999d81079f31db4e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 12:10:29 2016 +0100

    #134 delete unused attributes
    `isRestarted` and `rowsToIndex`

commit f4bcbd422a735364b9f90f71f1e1bf198d983eb5
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 11:22:37 2016 +0100

    #134 refactor process of indexing-progress-monitoring

commit 3c6b1d373a5096f993a77198e239acbe7a7fd844
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Dec 5 21:42:45 2016 +0100

    #134 add class StepProgress, storing indexing progress at step level

commit bc037f453f1b25dd86b60f5d3e5e34f3eff584b1
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Dec 2 09:44:05 2016 +0100

    #87 rename lgpl.txt to LICENSE.txt

commit 9ab00469a589cf9bdb118a6f952760c8e555836f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Nov 21 10:59:41 2016 +0100

    #160 add Travis CI status

commit cd5b933953dc4c523541709ccbe0100632823950
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Nov 21 10:50:47 2016 +0100

    #160 set up Travis CI

commit 0229fdb56e9218994cdc4d7793553337ba93d476
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Sep 30 21:39:53 2016 +0200

    #146 misc. enhance & use another test scenario for WF
    which demonstrates the possibility to index recent inserted entities

commit 13bc769a101c8f4cfa53fbe46433abdae2047a98
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 16:29:48 2016 +0200

    #133 type and naming enhancement

commit b7ca7eab62eec0457ee56586c66c90946364c6f0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 15:44:26 2016 +0200

    #151 rename "massIndex" / "mass-index" -> "BatchIndexingJob"

commit 031e6a02fabc8fb7ee731fdf3a8258f88aab0e6a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 15:28:17 2016 +0200

    #156 #159 refactor the MassIndexer -> BatchIndexingJob
    - Make a second level Builder class Builder.
    - Avoid using constructor of MassIndexer.
    - Various arguments of type Class<?>, Class<?>... for builder to allow at least 1 argument.
    - Rename MassIndexer to BatchIndexingJob
    - Avoid a static reference to the EMF
    - Update all the test cases according to the changes

commit 950106e036309e24560a599b9132644d3b328e74
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Sep 28 13:26:39 2016 +0200

    #133 the batch insertion counter need to be incremented

commit 4b8f5525a9ab716618bb42f0b90de0e5d77f5ec9
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Sep 27 16:59:52 2016 +0200

    #133 require at least one element for MassIndexer#addRootEntities(...)

commit 556e88e74d5f39212af86712bd767821f7839de0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Sep 27 10:50:42 2016 +0200

    #146 Allow to select the entities through a HQL/JPQL query

commit ff9f4c6dfdee918d4f59d1e4a03b0765105746db
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 25 22:10:50 2016 +0200

    #150 add test for validating the job start/stop in CLI

commit 4258265f34ddb69b0e14c15a9f30d20ca6170b9a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 25 17:37:00 2016 +0200

    #133 rename the war using the class's name

commit 038d53c0ac765f0ebd3826323c8c01a23b9255ad
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 22 17:29:13 2016 +0200

    #136 refactor mocked tests
    Use real EntityManagerFactory instead of mocked one. Batch properties are now passed using a protected args-constructor. After the refactoring, there's no need to use PowerMock anymore.

commit 217d560424171e83864dfe55f6d08d955baeb763
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 18 21:23:13 2016 +0200

    #158 store Object as job property, e.g. Hibernate criterion
    enable selection of entities to be re-indexed through criteria

commit e3a097a7eec8057b9c105684c9ab473645d08d3e
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Sep 16 16:58:44 2016 +0200

    #154 banne caching option for PartitionMapper

commit 3bf541a6ebfd4aa7d10a6d1475e4977a2fbb706d
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 15 18:36:22 2016 +0200

    #153 avoid SNAPSHOT versions among the dependencies

commit de4be0b1478c66237537847d27868059d38e981f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 15 18:09:03 2016 +0200

    #152 use java.lang.String for all the batch properties

commit e4e1ed4a33fcd616ccf5d58e065e77b85bcbf187
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Aug 26 21:46:36 2016 +0200

    #132 remove dummy job xml

commit e52939897253a79320ad471645637275e1e3b6a8
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Aug 26 21:41:38 2016 +0200

    #132 enable the module approach

commit a4fa8430b43ce138180eda8ce682d393ce55f473
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 24 23:47:53 2016 +0200

    #132 enable arquillian-managed WF's debug

commit 188fba5902ca1dc3777048db8039721ada32abb3
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 25 22:57:10 2016 +0200

    #132 WFLY-7000 Batch jobs from installed modules should be detected for non-batch app

commit 68ccad9abb1562f0f8cd0bbdc4b5057469fb7f77
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 24 23:47:53 2016 +0200

    #132 enable arquillian-managed WF's debug

commit 88c2dac3e7a7a7b2f8b7f4cc93d10d197b1b5244
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Aug 22 23:55:34 2016 +0200

    #132 add org.jberet.jberet-core as a module dependency
    to fix unsatisfied dependencies issue

commit 3fb229edb54f78c79208391a722168751b7811e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 15:10:20 2016 +0200

    #132 implement an SPI like this ?

commit c44d5f7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 23:54:34 2016 +0200

    #133 avoid dependence on the existing mass indexer
    for batchlets

commit 5c4add3
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:47:33 2016 +0200

    #143 change log level to INFO

commit e1b8229
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:47:06 2016 +0200

    #143 maven cleanup

commit 3c111e5
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:40:22 2016 +0200

    #140 change project version to 1.0

commit 1070a6d
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:08:44 2016 +0200

    #143 add issue management

commit 5ae4508
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:03:48 2016 +0200

    #143 maven clean up

commit e9bad75
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 20:59:43 2016 +0200

    #143 add license and developers info

commit 1b9f491
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 20:41:07 2016 +0200

    #139 separate simple integration test and performance test

commit 3a18b7b
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 18:43:59 2016 +0200

    #143 delete profiles

commit 35d8ba7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 18:40:53 2016 +0200

    #143 revert WF module installation approach

commit a78086f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 17:27:29 2016 +0200

    #143 rename maven module javaee-wildfly to wildfly

commit d9fadc8
Merge: 50908f9 ca09828
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 21:15:00 2016 +0200

    #132 import meta-inf from dependency

commit 50908f9
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 02:06:07 2016 +0200

    #132 update for IT

commit 576f105
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 17 23:50:36 2016 +0200

    #132 package batch job as module for WildFly

commit ca09828
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 02:06:07 2016 +0200

    #132 update for IT

commit 69440de
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 17 23:50:36 2016 +0200

    #132 package batch job as module for WildFly
09616af

@yrodiere yrodiere added a commit to yrodiere/hibernate-search that referenced this pull request May 17, 2017

@yrodiere yrodiere HSEARCH-2594 Adjustments on JSR-352 integration
This commit has been extracted from https://github.com/mincong-h/gsoc-hsearch/tree/master/
It is the result of squashing commits
94dc13e12b8477b357a4d6fcb3bff3008813e73a to 6a9df85c0d7351d83e05cc7062b9a18fbb6b3701
(see git log below).

commit 6a9df85c0d7351d83e05cc7062b9a18fbb6b3701
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Thu Jan 12 13:05:47 2017 +0100

    Fix a NPE when the conversion from EntityManagerFactory to SessionFactory fails

commit 596454f6d6bdfe89cf99646033e5b6a2b38d5934
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 17:35:15 2017 +0100

    Fix the dependencies in the WildFly module

commit f25e3a21327d301bae3f4f31a0062924a6f85f0a
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 17:31:41 2017 +0100

    Align the project version on the Hibernate Search version

    This avoids some weird issues with snippets of poms copied over
    from Hibernate Search.

commit 4830e5cf19a33a267c8bf7927910e0c21cda3d1c
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 11:43:39 2017 +0100

    Upgrade to Hibernate Search 5.7.0.Beta2 / Hibernate ORM 5.2.1.Final

    This will make it easier to work with SessionFactory if we have to,
    because starting from Hibernate ORM 5.2 SessionFactory extends
    EntityManagerFactory.

commit c903608a10f3c3db7db34ffbc693edcf7499d6a6
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Tue Jan 10 10:14:39 2017 +0100

    Reduce the use of JobSEEnvironment and @PersistenceUnit to a minimum

    That's because:

     * JobSEEnvironment will have to be replaced by something else, see #156 .
     * Injected persistence units do not work when CDI is disabled, so we
       might as well only use it where it is absolutely necessary.

commit 65aa7fec8d2a0e5c35f600cb5bad9ef822a08d45
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 14:48:46 2017 +0100

    i178 Remove "jobContextData" from the job parameters

commit db591e1c02deb1295306c9fdb7fb0bcb7cc85945
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 16:18:48 2017 +0100

    Add missing "static" keywords

commit 94dc13e12b8477b357a4d6fcb3bff3008813e73a
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 15:17:29 2017 +0100

    Also run integration tests in travis
edf4903

@yrodiere yrodiere added a commit to yrodiere/hibernate-search that referenced this pull request Jun 19, 2017

@mincong-h @yrodiere mincong-h + yrodiere HSEARCH-2594 Initial work on JSR-352 - third part
This commit has been extracted from https://github.com/mincong-h/gsoc-hsearch/tree/master/
It is the result of squashing commits
576f105 to 40aff727a4ca70dd809ca72dcb6315d71f80a37f
(see git log below).

commit 40aff727a4ca70dd809ca72dcb6315d71f80a37f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 23:18:43 2017 +0100

    #168 test batch job runnability over a poorly-formed entity
    It has multiple ID-like fields, which make it difficult to identify the real identifier.

commit 3cd83d9b5d9c055ee133d66a5af7e9c027a572dc
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 22:22:33 2017 +0100

    #165 delete unused import

commit 58fabd11044b64f82f69432061fe1a37ad8967a4
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 21:55:17 2017 +0100

    #165 remove duplicate ID projection

commit d0c23f934851866ecfc797c889a9c3f69971208c
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Jan 5 21:49:01 2017 +0100

    #165 avoid using toString() method

commit 15d2952a30d14384ed9a1a514b7a9a72b2d30ae6
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Jan 3 22:34:49 2017 +0100

    #165 use `Projections#id()`
    instead of `DocumentBuilderIndexedEntity#getIdPropertyName()` to avoid null reference issue for provided IDs.

commit 89624d52f7b6b955bbf45d576b538b8fc93445fb
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 21:40:45 2016 +0100

    #162 refactor entitiyType

commit c15633f0a2912b2cf50531c7742ae37b201d1229
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 21:13:59 2016 +0100

    #162 increase default itemCount to 200

commit 21be31a72a59e933006c1ccdc9e372b76a979098
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 20:27:12 2016 +0100

    #162 rename ID to Id

commit 81a39117cb8f9c8d0086c2252c2a3c759488fa4f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 20:13:51 2016 +0100

    #162 rename entityClazz to entityType

commit 6a7f42a8b3f3ef23dc6df3d93ea0c8b69210b5cb
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 17:10:03 2016 +0100

    #162 rename PartitionUnit to PartitionBound

commit 58add35f70ff943c915be7aeaf03b411db1847e7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 16:49:48 2016 +0100

    #162 refactor job context data setup

commit 0e942211a850a0d5c5b6c5a20f6e9a441123a8e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 15:56:51 2016 +0100

    #162 format code according to hibernate-ide-codestyles
    https://github.com/hibernate/hibernate-ide-codestyles

commit d0c9d69f2a702b997d40160f0aba6960fd22c4f8
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 12:10:43 2016 +0100

    #161 use getName() instead of toString()

commit d26d5c9acf9d08d303f1e2f1f728227a66bad87f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Dec 8 11:15:29 2016 +0100

    #134 rename StepContextData to PartitionContextData
    to provide a better understanding

commit f4983aacf9b14faebcbe8f553eb68d5182caea0a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 17:37:12 2016 +0100

    #134 persist indexing progress using `setPersistentData`

commit 3dd8b30bbaf623acddd3f240a9a0ca3583a5b488
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 12:48:42 2016 +0100

    #134 fix indexing progress error: avoid storing increment

commit a2c5ffcb60e99eff7245bd4999d81079f31db4e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 12:10:29 2016 +0100

    #134 delete unused attributes
    `isRestarted` and `rowsToIndex`

commit f4bcbd422a735364b9f90f71f1e1bf198d983eb5
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Dec 6 11:22:37 2016 +0100

    #134 refactor process of indexing-progress-monitoring

commit 3c6b1d373a5096f993a77198e239acbe7a7fd844
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Dec 5 21:42:45 2016 +0100

    #134 add class StepProgress, storing indexing progress at step level

commit bc037f453f1b25dd86b60f5d3e5e34f3eff584b1
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Dec 2 09:44:05 2016 +0100

    #87 rename lgpl.txt to LICENSE.txt

commit 9ab00469a589cf9bdb118a6f952760c8e555836f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Nov 21 10:59:41 2016 +0100

    #160 add Travis CI status

commit cd5b933953dc4c523541709ccbe0100632823950
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Nov 21 10:50:47 2016 +0100

    #160 set up Travis CI

commit 0229fdb56e9218994cdc4d7793553337ba93d476
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Sep 30 21:39:53 2016 +0200

    #146 misc. enhance & use another test scenario for WF
    which demonstrates the possibility to index recent inserted entities

commit 13bc769a101c8f4cfa53fbe46433abdae2047a98
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 16:29:48 2016 +0200

    #133 type and naming enhancement

commit b7ca7eab62eec0457ee56586c66c90946364c6f0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 15:44:26 2016 +0200

    #151 rename "massIndex" / "mass-index" -> "BatchIndexingJob"

commit 031e6a02fabc8fb7ee731fdf3a8258f88aab0e6a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 29 15:28:17 2016 +0200

    #156 #159 refactor the MassIndexer -> BatchIndexingJob
    - Make a second level Builder class Builder.
    - Avoid using constructor of MassIndexer.
    - Various arguments of type Class<?>, Class<?>... for builder to allow at least 1 argument.
    - Rename MassIndexer to BatchIndexingJob
    - Avoid a static reference to the EMF
    - Update all the test cases according to the changes

commit 950106e036309e24560a599b9132644d3b328e74
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Sep 28 13:26:39 2016 +0200

    #133 the batch insertion counter need to be incremented

commit 4b8f5525a9ab716618bb42f0b90de0e5d77f5ec9
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Sep 27 16:59:52 2016 +0200

    #133 require at least one element for MassIndexer#addRootEntities(...)

commit 556e88e74d5f39212af86712bd767821f7839de0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Tue Sep 27 10:50:42 2016 +0200

    #146 Allow to select the entities through a HQL/JPQL query

commit ff9f4c6dfdee918d4f59d1e4a03b0765105746db
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 25 22:10:50 2016 +0200

    #150 add test for validating the job start/stop in CLI

commit 4258265f34ddb69b0e14c15a9f30d20ca6170b9a
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 25 17:37:00 2016 +0200

    #133 rename the war using the class's name

commit 038d53c0ac765f0ebd3826323c8c01a23b9255ad
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 22 17:29:13 2016 +0200

    #136 refactor mocked tests
    Use real EntityManagerFactory instead of mocked one. Batch properties are now passed using a protected args-constructor. After the refactoring, there's no need to use PowerMock anymore.

commit 217d560424171e83864dfe55f6d08d955baeb763
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sun Sep 18 21:23:13 2016 +0200

    #158 store Object as job property, e.g. Hibernate criterion
    enable selection of entities to be re-indexed through criteria

commit e3a097a7eec8057b9c105684c9ab473645d08d3e
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Sep 16 16:58:44 2016 +0200

    #154 banne caching option for PartitionMapper

commit 3bf541a6ebfd4aa7d10a6d1475e4977a2fbb706d
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 15 18:36:22 2016 +0200

    #153 avoid SNAPSHOT versions among the dependencies

commit de4be0b1478c66237537847d27868059d38e981f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Sep 15 18:09:03 2016 +0200

    #152 use java.lang.String for all the batch properties

commit e4e1ed4a33fcd616ccf5d58e065e77b85bcbf187
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Aug 26 21:46:36 2016 +0200

    #132 remove dummy job xml

commit e52939897253a79320ad471645637275e1e3b6a8
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Fri Aug 26 21:41:38 2016 +0200

    #132 enable the module approach

commit a4fa8430b43ce138180eda8ce682d393ce55f473
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 24 23:47:53 2016 +0200

    #132 enable arquillian-managed WF's debug

commit 188fba5902ca1dc3777048db8039721ada32abb3
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 25 22:57:10 2016 +0200

    #132 WFLY-7000 Batch jobs from installed modules should be detected for non-batch app

commit 68ccad9abb1562f0f8cd0bbdc4b5057469fb7f77
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 24 23:47:53 2016 +0200

    #132 enable arquillian-managed WF's debug

commit 88c2dac3e7a7a7b2f8b7f4cc93d10d197b1b5244
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Mon Aug 22 23:55:34 2016 +0200

    #132 add org.jberet.jberet-core as a module dependency
    to fix unsatisfied dependencies issue

commit 3fb229edb54f78c79208391a722168751b7811e0
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 15:10:20 2016 +0200

    #132 implement an SPI like this ?

commit c44d5f7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 23:54:34 2016 +0200

    #133 avoid dependence on the existing mass indexer
    for batchlets

commit 5c4add3
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:47:33 2016 +0200

    #143 change log level to INFO

commit e1b8229
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:47:06 2016 +0200

    #143 maven cleanup

commit 3c111e5
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:40:22 2016 +0200

    #140 change project version to 1.0

commit 1070a6d
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:08:44 2016 +0200

    #143 add issue management

commit 5ae4508
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 22:03:48 2016 +0200

    #143 maven clean up

commit e9bad75
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 20:59:43 2016 +0200

    #143 add license and developers info

commit 1b9f491
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 20:41:07 2016 +0200

    #139 separate simple integration test and performance test

commit 3a18b7b
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 18:43:59 2016 +0200

    #143 delete profiles

commit 35d8ba7
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 18:40:53 2016 +0200

    #143 revert WF module installation approach

commit a78086f
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Sat Aug 20 17:27:29 2016 +0200

    #143 rename maven module javaee-wildfly to wildfly

commit d9fadc8
Merge: 50908f9 ca09828
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 21:15:00 2016 +0200

    #132 import meta-inf from dependency

commit 50908f9
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 02:06:07 2016 +0200

    #132 update for IT

commit 576f105
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 17 23:50:36 2016 +0200

    #132 package batch job as module for WildFly

commit ca09828
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Thu Aug 18 02:06:07 2016 +0200

    #132 update for IT

commit 69440de
Author: Mincong HUANG <mincong.h@gmail.com>
Date:   Wed Aug 17 23:50:36 2016 +0200

    #132 package batch job as module for WildFly
36b6a57

@yrodiere yrodiere added a commit to yrodiere/hibernate-search that referenced this pull request Jun 19, 2017

@yrodiere yrodiere HSEARCH-2594 Adjustments on JSR-352 integration
This commit has been extracted from https://github.com/mincong-h/gsoc-hsearch/tree/master/
It is the result of squashing commits
94dc13e12b8477b357a4d6fcb3bff3008813e73a to 6a9df85c0d7351d83e05cc7062b9a18fbb6b3701
(see git log below).

commit 6a9df85c0d7351d83e05cc7062b9a18fbb6b3701
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Thu Jan 12 13:05:47 2017 +0100

    Fix a NPE when the conversion from EntityManagerFactory to SessionFactory fails

commit 596454f6d6bdfe89cf99646033e5b6a2b38d5934
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 17:35:15 2017 +0100

    Fix the dependencies in the WildFly module

commit f25e3a21327d301bae3f4f31a0062924a6f85f0a
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 17:31:41 2017 +0100

    Align the project version on the Hibernate Search version

    This avoids some weird issues with snippets of poms copied over
    from Hibernate Search.

commit 4830e5cf19a33a267c8bf7927910e0c21cda3d1c
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 11:43:39 2017 +0100

    Upgrade to Hibernate Search 5.7.0.Beta2 / Hibernate ORM 5.2.1.Final

    This will make it easier to work with SessionFactory if we have to,
    because starting from Hibernate ORM 5.2 SessionFactory extends
    EntityManagerFactory.

commit c903608a10f3c3db7db34ffbc693edcf7499d6a6
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Tue Jan 10 10:14:39 2017 +0100

    Reduce the use of JobSEEnvironment and @PersistenceUnit to a minimum

    That's because:

     * JobSEEnvironment will have to be replaced by something else, see #156 .
     * Injected persistence units do not work when CDI is disabled, so we
       might as well only use it where it is absolutely necessary.

commit 65aa7fec8d2a0e5c35f600cb5bad9ef822a08d45
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 14:48:46 2017 +0100

    i178 Remove "jobContextData" from the job parameters

commit db591e1c02deb1295306c9fdb7fb0bcb7cc85945
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 16:18:48 2017 +0100

    Add missing "static" keywords

commit 94dc13e12b8477b357a4d6fcb3bff3008813e73a
Author: Yoann Rodière <yoann@hibernate.org>
Date:   Wed Jan 11 15:17:29 2017 +0100

    Also run integration tests in travis
21f91fe
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment