[hibernate-dev] Search test module
sanne.grinovero at gmail.com
Thu Nov 18 12:01:15 EST 2010
To keep the happy end on the mailing list:
while we might have gradle in the future, as a current solution
I fixed the test classes (clones where actually different), and kept
the module but removed all classes.
The parent pom.xml now uses the maven-jar-plugin plugin to also
create the "test" artifacts, and the module which is now empty
takes this dependency and the others it was already providing,
so it should work the same in practice for people using it
as it provides the same classes and dependencies.
HSEARCH-635 - Hardy is reviewing it.
2010/11/18 Hardy Ferentschik <hibernate at ferentschik.de>:
> I was not aware that the current setup does not work in Eclipse :(
> On the other hand, we haven't had an additional module yet within the
> project depending on the testing module.
> The duplication of classes is there because of the cycle you mentioned.
> It is really a chicken and hen problem. The only solution to completely
> remove the duplicates would be moving the tests into a testing module.
> I also don't like this option.
> The other option would be to ditch the additional hibernate-search-testing
> module and go back to the pom "hack" we had initially which was creating a
> of the test classes. We just have to look at the version control history to
> it back. I didn't like it initially and somehow preferred the solution
> with some duplicated classes. However, if the current setup causes trouble
> might as well revert to what we had.
> I don't think there is a perfect solution for this issue, except maybe to
> to gradle ;-)
> On Wed, 17 Nov 2010 19:07:45 +0100, Sanne Grinovero
> <sanne.grinovero at gmail.com> wrote:
>> I'm in need to use some of the test classes from Hibernate Search
>> (core module) in the tests for the new Infinispan module;
>> I was initially depending on the "hibernate-search-testing" Maven
>> module, which was recently split from our core test classes,
>> but then I started having seriously weird issues, finally finding out
>> that classes which were moved to the new module where
>> never removed from the old place;
>> in practice with eclipse's (totally broken) merging of classpaths I
>> was having both copies on classpath and picking the wrong
>> versions: this is because eclipse does merge the main and the test
>> classpaths (it has no notion of the different scopes),
>> and the new Infinispan module obviously does need to depend to the core
>> So I started cleaning up, deleting duplicate files from the core tests
>> to make sure I was going to use the ones provided
>> by hibernate-search-testing; this resulted in another blocking issue:
>> "A cycle was detected in the build path of project",
>> i.e. Eclipse now refuses to build anything, as core Search depends on
>> another artifact to run its tests.
>>> From what I remember from the discussion when we created this module,
>> we followed this way because it was similar
>> to what core did; I'm now stuck and would like to use the same
>> approach used by Infinispan: it creates Maven
>> artifacts for the tests of the same module, <type>test-jar</type>.
>> This was the other alternative we discussed at the time,
>> as far as I remember we decided to go for the current configuration
>> because of consistency with core.
>> The only alternative I see it so move all tests into the separate
>> project, but don't really like that;
>> final alternative is for me to ditch eclipse, but I'd rather keep
>> options open for everyone and
>> I'm not sure how far you tested this same things on IDEA either?
>> Maybe you could try removing classes such as
>> org.hibernate.search.test.SearchTestCase from the core module
>> and see how far you get in IDEA, but I wouldn't expect a great
>> experience either.
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
More information about the hibernate-dev