[
https://issues.apache.org/jira/browse/SOLR-15503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17371092#comment-17371092
]
Dawid Weiss commented on SOLR-15503:
------------------------------------
Hi Mike. I think this should be implemented as a separate task/ file (separate
aspect under gradle/). This way it's easier to maintain. Implementation-wise I
think the simplest solution should work for starters - add the task to the root
project and scan all **/*.java files underneath, regexp the suppressions and
count them. The threshold can be part of the task's definition file?
Gradle has support for processing stuff in an incremental way but I never had
to look into it. [1] Seems like you could do it nicely with the "input changes"
API they have - store an auxiliary data structure (counts) maintained per-java
file under the build folder and keep it in sync with the sources incrementally.
The task would just sum up the suppressions from that file.
I'm sorry to be of little help but I've had very little time for open source
work recently.
[1]
https://docs.gradle.org/current/userguide/custom_tasks.html#incremental_tasks
> Record current number of warnings and fail the build if that number is
> exceeded
> -------------------------------------------------------------------------------
>
> Key: SOLR-15503
> URL: https://issues.apache.org/jira/browse/SOLR-15503
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Mike Drob
> Priority: Major
>
> As part of the warning elimination/reduction work I'm doing in SOLR-15385,
> I'd like to add some precommit validation to check if the current number of
> suppressions exceed the known amount. We can then continue to ratchet this
> down, although I know we will never reach zero.
> I was thinking about doing this inside of validateSourcePatterns, but I'm not
> sure of how to do this in an incremental way. Essentially, I want to run
> {{git grep SuppressWarn | wc -l}} and compare that output to some saved
> value, if higher then fail, if lower then suggest that the saved number needs
> to be adjusted. Also, we can be more specific, like have separate thresholds
> for different kinds of suppression annotations, so that we don't just trade
> one for another blindly.
> [~dawid.weiss] - any suggestions are appreciated. Thanks!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
