[
https://issues.apache.org/jira/browse/LUCENE-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14502454#comment-14502454
]
Uwe Schindler commented on LUCENE-6420:
---------------------------------------
bq. lucene/test-framework/pom.xml.template and
solr/core/src/test/pom.xml.template aren't modified, but likely should be - I
think the specializations there can be removed.
They cannot be completely removed:
- test-frameworks executes test-checks on the standard src/mainfolder (this is
also special in Ant build). But the solution is much easier here: It just
inherits the shared execution, but changes the goal to "check" instead of
"testCheck". The config is inherited, so it executes the test configuration on
the src/main folder (like in Ant)
- solr/core/src/test/pom.xml is special, because it still excludes the
imported-commons-csv tests. I simplified this by also inheriting the config,
just adding the exclude. This is similar to what Ant does.
bq. lucene/benchmark/pom.xml.template and lucene/demo/pom.xml.template should
probably have lucene.txt added to their <signaturesFiles>.
- I solved this in a similar way by inheriting the parent configuration and
just "overriding" the bundledSignatures config (without jdk-system-out).
bq. Also, if I understand how things are setup, the new annotation suppresses
all forms of forbiddenapi checking, as compared to the previous configuration,
where there were multiple executions, and exceptions were targetted at a
particular check (e.g. sysout), but didn't prevent other checks from running.
In the maven build this represents a loss of coverage everywhere the
annoatations are used, doesn't it? Not sure about the Ant build.
Yes and No :-) You are right, we miss some coverage (also in Ant build), but we
get more coverage on the other side, because we can exclude in a more
fine-granular way (on method level). I thought about this already, one solution
might be (but lets keep this for later): For the very common sysout-stuff, we
can add a separate {{@SuppressForbiddenSysout}} so we can scan in 2 executions.
We should discuss this in a separate issue. I did not want to add too many
annotations yet.
On the other hand, because we can now work more fine-granular, I would suggest
to refactor the code a bit and move the "violations" to separate methods (like
I did in the DocSetPerf tester) and only exclude those, so we don't have to
exclude the whole method. For the command line tools, we might add a private
method to the class containing the main method called "printout(String)" that
is suppressed.
> Update forbiddenapis to 1.8
> ---------------------------
>
> Key: LUCENE-6420
> URL: https://issues.apache.org/jira/browse/LUCENE-6420
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6420-anno.patch, LUCENE-6420-anno.patch,
> LUCENE-6420-anno.patch, LUCENE-6420.patch
>
>
> Update forbidden-apis plugin to 1.8:
> - Initial support for Java 9 including JIGSAW
> - Errors are now reported sorted by line numbers and correctly grouped
> (synthetic methods/lambdas)
> - Package-level forbids: Deny all classes from a package: org.hatedpkg.**
> (also other globs work)
> - In addition to file-level excludes, forbiddenapis now supports fine
> granular excludes using Java annotations. You can use the one shipped, but
> define your own, e.g. inside Lucene and pass its name to forbidden (e.g.
> using a glob: **.SuppressForbidden would any annotation in any package to
> suppress errors). Annotation need to be on class level, no runtime annotation
> required.
> This will for now only update the dependency and remove the additional forbid
> by [~shalinmangar] for MessageFormat (which is now shipped with forbidden).
> But we should review and for example suppress forbidden failures in command
> line tools using @SuppressForbidden (or similar annotation). The discussion
> is open, I can make a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
