lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4753) Make forbidden API checks per-module
Date Sun, 10 Nov 2013 23:01:17 GMT


ASF subversion and git services commented on LUCENE-4753:

Commit 1540575 from [~thetaphi] in branch 'dev/branches/branch_4x'
[ ]

Merged revision(s) 1540573 from lucene/dev/trunk:
LUCENE-4753: Run forbidden-apis Ant task per module. This allows more improvements and prevents
OOMs after the number of class files raised recently

> Make forbidden API checks per-module
> ------------------------------------
>                 Key: LUCENE-4753
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: general/build
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>            Priority: Critical
>             Fix For: 4.6
>         Attachments: LUCENE-4753.patch, LUCENE-4753.patch, LUCENE-4753.patch
> After the forbidden API checker was released separately from Lucene as a Google Code
project (forked and improved), including Maven support, the checks on Lucene should be changed
to work per-module.
> The reason for this is: The improved checker is more picky about e.g. extending classes
that are forbidden or overriding methods and calling super.method() if they are on the forbidden
signatures list. For these checks, it is not enough to have the class files and the rt.jar,
you need the whole classpath. The forbidden APIs 1.0 now by default complains if classes are
missing from the classpath.
> It is very hard with the module architecture of Lucene/Solr, to make a uber-classpath,
instead the checks should be done per module, so the default compile/test classpath of the
module can be used and no crazy path statements with **/*.jar are needed. This needs some
refactoring in the exclusion lists, but the Lucene checks could be done by a macro in common-build,
that allows custom exclusion lists for specific modules.
> Currently, the "strict" checking is disabled for Solr, so the checker only complains
about missing classes but does not fail the build:
> {noformat}
> -check-forbidden-java-apis:
> [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.6
> [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.6
> [forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.1
> [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr3\lucene\tools\forbiddenApis\executors.txt
> [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr3\lucene\tools\forbiddenApis\servlet-api.txt
> [forbidden-apis] Loading classes to check...
> [forbidden-apis] Scanning for API signatures and dependencies...
> [forbidden-apis] WARNING: The referenced class ''
cannot be loaded. Please fix the classpath!
> [forbidden-apis] WARNING: The referenced class ''
cannot be loaded. Please fix the classpath!
> [forbidden-apis] WARNING: The referenced class ''
cannot be loaded. Please fix the classpath!
> [forbidden-apis] WARNING: The referenced class 'org.apache.lucene.collation.ICUCollationKeyAnalyzer'
cannot be loaded. Please fix the classpath!
> [forbidden-apis] Scanned 2177 (and 1222 related) class file(s) for forbidden API invocations
(in 1.80s), 0 error(s).
> {noformat}
> I added almost all missing jars, but those do not seem to be in the solr part of the
source tree (i think they are only copied when building artifacts). With making the whole
thing per module, we can use the default classpath of the module which makes it much easier.

This message was sent by Atlassian JIRA

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

View raw message