lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4365) The Maven build can't directly handle complex inter-module dependencies involving the test-framework modules
Date Thu, 06 Sep 2012 15:31:08 GMT


Uwe Schindler commented on LUCENE-4365:

bq. Yeah some of the crazy analyzers tests (TestRandomChains etc) have this same logic. would
be nice if it was done better.

Unfortunately the Java ClassLoaders do not support listing all classes in a package. To solve
this, the tests use a trick: They ask for the resource URI for the base package path from
the classloader. And then standard recursive directory inspection is used. This needs the
classloader to return a file:// URL, if that is not the case, we throw exception - that's
the one you get?.

But not only those tests are doing this, a lot of tests, that access zip files directly in
classpath (when Random Access is needed, because Classloaders only allow streams) do the same,
they get the reource URI and then open the ZIP file. I think this is not a problem, as the
tests are accessing only their own resources, not those of a foreign mdoule - so JAR files
are not involved.

Maybe Java 8 has a solution to list all classes in a package...
> The Maven build can't directly handle complex inter-module dependencies involving the
test-framework modules
> ------------------------------------------------------------------------------------------------------------
>                 Key: LUCENE-4365
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: general/build
>            Reporter: Steven Rowe
>            Assignee: Steven Rowe
>            Priority: Minor
>         Attachments: LUCENE-4365.patch, lucene.solr.cyclic.dependencies.removed.png,
> The Maven dependency model disallows cyclic dependencies, of which there are now several
in the Ant build (considering test and compile dependencies together, as Maven does).  All
of these cycles involve either the Lucene test-framework or the Solr test-framework.
> The current Maven build works around this problem by incorporating dependencies' sources
into dependent modules' test sources, rather than literally declaring the problematic dependencies
as such. (See SOLR-3780 for a recent example of putting this workaround in place for the Solrj
> But with the factoring out of the Lucene Codecs module, upon which Lucene test-framework
has a compile-time dependency, the complexity of the workarounds required to make it all hang
together is great enough that I want to attempt a (Maven-build-only) module refactoring. 
It should require fewer contortions and be more maintainable.
> The Maven build is currently broken, as of the addition of the Codecs module (LUCENE-4340).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message