[
https://issues.apache.org/jira/browse/LUCENE-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449739#comment-13449739
]
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: https://issues.apache.org/jira/browse/LUCENE-4365
> 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,
> lucene.solr.dependency.cycles.png.jpg
>
>
> 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 module.)
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
