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. --Hardy On Mon, 22 Mar 2010 07:25:25 -0400, Steve Ebersole <st...@hibernate.org> wrote: > 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 wrote: >> >>> Ok, locally I have now the following structure >>> >>> pom.xml >>> hibernate-search/ >>> hibernate-search-archetype/ >>> hibernate-search-testing/ >>> hibernate-search-testsuite/ >>> >>> Tests are split out into hibernate-search-testsuite. We can still >>> leave tests which don't extend >>> SearchTestCase in hibernate-search, but there are not many ;-) >>> >>> This setup will allow to add a new infinispan module where the tests >>> can use for example the >>> SearchTestCase of hibernate-search-testing. We can also further split >>> out the jms and jgroups >>> clustering, but that's optional. >>> >>> The only way to keep the main tests in hibernate-search while still >>> publishing a testing module >>> would be some code duplication. >>> >>> I know there are still some reservations about this setup, so I >>> thought I ask once more - >>> commit or not commit? ;-) >>> >>> --Hardy >>> >>> >>> >>> >>> On Wed, 17 Mar 2010 12:38:54 -0300, Hardy >>> Ferentschik<hibern...@ferentschik.de> wrote: >>> >>>> Regarding the test util module (hibernate-search-testing). If we are >>>> planning to split out >>>> the different clustering parts (or for any other later module) we >>>> probably >>>> want to >>>> have all the test base classes in hibernate-search-testing as well (eg >>>> SearchTestCase). >>>> Obviously SearchTestCase depends heavily on core Search classes and an >>>> additional >>>> hibernate-search-util is not going to cut it. If we go the full monty >>>> we >>>> would need >>>> to break out all the test related utility/base classes into >>>> hibernate-search-testing >>>> and then move all tests into hibernate-search-testsuite. This is >>>> effectively how Hibernate >>>> Core is setup and it creates some consistency. I guess Steve had his >>>> reasons after all to >>>> go for the setup we have now ;-) >>>> >>>> I don't think we have to be too worried about people not running the >>>> tests, because they >>>> are in another module. The setup works for Core. Besides, I am a big >>>> sucker for consistency >>>> and I like the idea that Search would mirror the Core setup. Thoughts? >>>> >>>> Regarding the performance tests, I am not sure whether we need a >>>> separate >>>> module for that. >>>> The problem is now that these tests are excluded in the POM >>>> configuration. >>>> I think we just >>>> need a way to run them. Maybe a simple property 'mvn install >>>> -Drun.performance.test=true' >>>> We can then decide if the default should be true or false. >>>> >>>> --Hardy >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
