Hello,
Sorry, I've been a bit out of this particular problem for a long time, so if I
ask already answers questions forgive me.
Thanks for all the work, sorry it take so long on our part for each review :(
Here are some comments on the patch:
- your code rules don't seem to match Hibernate's in
Anticipating Ales' work on the optimization between HEM and the micro container
( http://opensource.atlassian.com/projects/hibernate/browse/HHH-4191 ),
I've added a way to pass an instance of Scanner to the persistence unit:
- an actual instance (recommended)
- the class name of the instance to
On Hibernate EntityManager:
- AvailableSettings#ALIAS_SPECIFIC_LOCK_MODE (org.hibernate.lockMode)
- AvailableSettings#FLUSH_MODE (org.hibernate.flushMode)
are the only two properties starting with org. instead of hibernate. for the
rest of the properties.
It would make sense to align them to "h
I don't like it too much either. As Steve was saying, there are pro and
cons
and it is only required, because maven 'forces' you down this path.
For now I will just commit hibernate-search-testing (effectively
duplicating
the test utility classes). We see how this goes and take it from there.
Honestly, had Maven not forced me to I would not have for Core either.
On 03/22/2010 05:19 AM, Emmanuel Bernard wrote:
> If you ask me, I think moving core tests away from the core module(s) is not
> the right thing to do for hibernate search.
>
> On 20 mars 2010, at 20:35, Hardy Ferentschik wrot
If you ask me, I think moving core tests away from the core module(s) is not
the right thing to do for hibernate search.
On 20 mars 2010, at 20:35, Hardy Ferentschik wrote:
> Ok, locally I have now the following structure
>
> pom.xml
> hibernate-search/
> hibernate-search-archetype/
> hibernate
