[ https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated LUCENE-4753: ---------------------------------- Attachment: LUCENE-4753.patch Final patch. Will commit in a moment. > Make forbidden API checks per-module > ------------------------------------ > > Key: LUCENE-4753 > URL: https://issues.apache.org/jira/browse/LUCENE-4753 > 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 > 'org.apache.lucene.analysis.uima.ae.AEProviderFactory' cannot be loaded. > Please fix the classpath! > [forbidden-apis] WARNING: The referenced class > 'org.apache.lucene.analysis.uima.ae.AEProviderFactory' cannot be loaded. > Please fix the classpath! > [forbidden-apis] WARNING: The referenced class > 'org.apache.lucene.analysis.uima.ae.AEProvider' 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 (v6.1#6144) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org