[jira] [Updated] (LUCENE-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-4753:
--
Fix Version/s: 4.6
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
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
[jira] [Updated] (LUCENE-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-4753:
--
Priority: Critical (was: Major)
Recently on MacOSX, with the default heap size, we get OOMs while running
forbidden-checker. So we should really do this now.
My proposal: Move the forbidden targets into commons-build.xml on Lucene and
Solr. Inside commons-build, also define some properties to make some excludes,
so we can define per module, which patterns/filesets should be checked.
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
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
[jira] [Updated] (LUCENE-4753) Make forbidden API checks per-module
[
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
Patch. I will commit this soon if nobody objects.
There is still room for improvements (e.g. we can now enable servlet-api checks
in some Lucene modules that use servlets, or enable commons-io checks for
lucene modules that use commons-io).
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
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
[jira] [Updated] (LUCENE-4753) Make forbidden API checks per-module
[
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
New patch, removed useless dependency.
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
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
[jira] [Updated] (LUCENE-4753) Make forbidden API checks per-module
[
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
[jira] [Updated] (LUCENE-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-4753:
--
Issue Type: Improvement (was: Bug)
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
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 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
