[
https://issues.apache.org/jira/browse/SOLR-10778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-10778.
-----------------------------------
Fix Version/s: 8.6
Resolution: Fixed
All gone. To recap:
* Added a LOT of SuppressWarnings to the code. The result is that Gradle
builds on 9x are clean and WILL FAIL COMPILATIONS if any new warnings are
introduced. Ideally, when people are working on code and see SuppressWarnings
we can remove them and actually fix the root cause.
* Please try to actually fixing the code when you write code that creates new
compile-time warnings rather than just adding SuppressWarnings. I'll be
counting the SuppressWarnings in the weekly BadApple report and nag people.
* There were over 8,000 warnings issued in Solr, about 100 in Lucene. The
Lucene issues have been more thoughtfully dealt with. See: LUCENE-9394
* Ant builds will _not_ fail on compilation due to it being tricky to resolve
some third-party compile-only dependencies in Zookeeper and CaffeineCache.
You'll see a few warnings when building with Ant that are for annotations
nowhere in the Lucene/Solr code.
> Address precommit WARNINGS
> --------------------------
>
> Key: SOLR-10778
> URL: https://issues.apache.org/jira/browse/SOLR-10778
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
> Affects Versions: 4.6
> Reporter: Andrew Musselman
> Assignee: Erick Erickson
> Priority: Minor
> Fix For: 8.6
>
> Attachments: dated-warnings, dated-warnings.log, notclosed.txt
>
>
> During precommit we are seeing lots of warnings. Im turning this into an
> umbrella issue about getting precommit warnings out of the code in general.
> Yes, this will take a while.
> See SOLR-10809 for getting all warnings out of solr/core. I want to
> selectively have precommit fail when "some part" of the code is clean so we
> don't backslide, and solr/core was the finest granularity I could see how to
> change.
> If you read more of the comments here, you can see that there are some
> serious code refactoring that could be done. I'm electing to simply
> SuppressWarnings rather than re-arrange code at this point whenever the code
> is tricky. If anyone goes back in and tries to clean the code up, then can
> remove the annotation(s).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
