[hibernate-dev] Modularization of Search

[Hardy Ferentschik]

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