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 <steve(a)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<hibernate(a)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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev