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
jar
of the test classes. We just have to look at the version control history
to get
it back. I didn't like it initially and somehow preferred the solution
with some duplicated classes. However, if the current setup causes trouble
we
might as well revert to what we had.
I don't think there is a perfect solution for this issue, except maybe to
switch
to gradle ;-)
--Hardy
On Wed, 17 Nov 2010 19:07:45 +0100, Sanne Grinovero
<sanne.grinovero(a)gmail.com> wrote:
Hello,
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
module.
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.
Cheers,
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev