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
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
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
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
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
Hello,
while writing tests for Infinispan I would like to be able to depend
on Hibernate Search's testsuite, as it contains several helpers which
I would use.
This happened me on other projects too, quite always if Lucene is involved.
Would you be ok in publishing the maven artifacts of the testsu
