[jira] [Commented] (LUCENE-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818976#comment-13818976
]
Markus Jelsma commented on LUCENE-4753:
---
I usually update both but perhaps i didn't this time or i didn't get all
commits, the latter sometimes happens and then i have to update twice.
It's fixed now.
> 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] [Commented] (LUCENE-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818970#comment-13818970
]
Uwe Schindler commented on LUCENE-4753:
---
It is still strange, because the whole change was one single commit. So you
would have either nothing or all of the changes. From your error message, it
looks as you may have only updated the lucene folder and not solr. Because this
old target was only existent in lucene/common-build.xml; if this file was
updated, solr would no longer find it with the old name.
> 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] [Commented] (LUCENE-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818947#comment-13818947
]
Markus Jelsma commented on LUCENE-4753:
---
ant example from /solr. I svn upped my checkout not long ago and got no updated
build.xml. I upped again and i finally received your commit. Svn must be behind.
Thanks
> 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] [Commented] (LUCENE-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818933#comment-13818933
]
Uwe Schindler commented on LUCENE-4753:
---
Hi,
which build target did you call from where? This outdated target
"install-forbidden-apis" no longer exists (it was renamed). I looks like you
have a checkout with mixed svn revisions or you have changed some build.xml
files yourself and they conflicted.
Be sure to:
# revert all changes (make sure you save your changes in a diff before doing
this)
# update your checkout from the root folder (where lucene, dev-tools, and solr
subfolders are visible). Updating only solr or lucene subfolder leads to
inconsistency as dependencies inside ANT no longer work
# if nothing helps, use a fresh checkout and try again. You can apply the patch
from step 1 to restore your changes.
Jenkins already verified that everything is fine. I cannot find any problems,
too: I can call "ant compile/test/check-forbidden-apis/..." from everywhere and
it works.
> 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] [Commented] (LUCENE-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818926#comment-13818926
]
Markus Jelsma commented on LUCENE-4753:
---
Hi Uwe, i can't compile anymore since something was changed to build.xml
{code}
BUILD FAILED
Target "install-forbidden-apis" does not exist in the project "solr". It is
used from target "check-forbidden-apis".
Total time: 0 seconds
{code}
> 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] [Commented] (LUCENE-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818616#comment-13818616
]
Uwe Schindler commented on LUCENE-4753:
---
FYI: I opened [https://code.google.com/p/forbidden-apis/issues/detail?id=20] to
improve the memory usage of forbidden-apis.
> 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] [Commented] (LUCENE-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818609#comment-13818609
]
ASF subversion and git services commented on LUCENE-4753:
-
Commit 1540575 from [~thetaphi] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1540575 ]
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: 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] [Commented] (LUCENE-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818603#comment-13818603
]
ASF subversion and git services commented on LUCENE-4753:
-
Commit 1540573 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1540573 ]
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: 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] [Commented] (LUCENE-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818499#comment-13818499
]
Uwe Schindler commented on LUCENE-4753:
---
The Maven builds are already per module! So we should get the file patterns and
targets also synchronized with the definitions in the maven POMs - I have to
say: in this case, the maven build is better than our ANT build :-( Thanks
[~steve_rowe]!!!
> 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
