My problem with that is that we don't spend as much energy as we do for the
core product on API stability. We should clearly mark these as non stable APIs.
Aside from that, feel free to go. Maybe we should split the helper bits in a
dedicated submodule once we have a multi module Hibernate Search
you're right, but how should I "mark these as non stable APIs" ?
These artifacts are not included in the main jar, so if somebody wants
to depend on them they are supposed to know what they're doing.
I've created HSEARCH-467 and the pom change is committed - I'll keep
it open to apply some warning
Just giving everyone the heads up that I an planning to do the Search build
refactoring, starting probably later today or latest tomorrow.
I don't think that it will be hard to merge any outstanding changes you
have
into the new layout, but in case you think you need more time to check
somethi
IMO the best approach is a separate module for the test
helper/infrastructure bits. This is what we do in core with the
hibernate-test module as opposed to the hibernate-testsuite module.
To me it makes the intent clearer. If I see including a testuite
(test-jar artifact) I immediately think
Hi there,
Emmanuel and I had a discussion regarding a use case given in
http://opensource.atlassian.com/projects/hibernate/browse/HV-264
What if you have a list of strings and want to make sure that each string
is a valid email. Something like this (@Valid is
not helping here either):
@Email
I agree. A separate module is the best approach. I will go for that
approach.
On Mon, 15 Mar 2010 11:35:02 -0300, Steve Ebersole
wrote:
> IMO the best approach is a separate module for the test
> helper/infrastructure bits. This is what we do in core with the
> hibernate-test module as oppo
