You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Erick Erickson (Jira)" <ji...@apache.org> on 2020/05/28 00:32:00 UTC

[jira] [Updated] (SOLR-14480) Fix or suppress warnings in solr/cloud/api

     [ https://issues.apache.org/jira/browse/SOLR-14480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erick Erickson updated SOLR-14480:
----------------------------------
    Summary: Fix or suppress warnings in solr/cloud/api  (was: Fix or suppress warnings in solr/api)

> Fix or suppress warnings in solr/cloud/api
> ------------------------------------------
>
>                 Key: SOLR-14480
>                 URL: https://issues.apache.org/jira/browse/SOLR-14480
>             Project: Solr
>          Issue Type: Sub-task
>          Components: Build
>            Reporter: Erick Erickson
>            Assignee: Atri Sharma
>            Priority: Major
>
> [~atri] Here's one for you!
> Here's how I'd like to approach this:
>  * Let's start with solr/core, one subdirectory at a time.
>  * See SOLR-14474 for how we want to address auxiliary classes, especially the question to move them to their own file or nest them. It'll be fuzzy until we get some more experience.
>  * Let's just clean everything up _except_ deprecations. My thinking here is that there will be a bunch of code changes that we can/should backport to 8x to clean up the warnings. Deprecations will be (probably) 9.0 only so there'll be fewer problems with maintaining the two branches if we leave deprecations out of the mix for the present.
>  * Err on the side of adding @SuppressWarnings rather than code changes for this phase. If it's reasonably safe to change the code (say by adding <?>) do so, but substantive changes are too likely to have unintended consequences. I'd like to reach a consensus on what changes are "safe", that'll probably be an ongoing discussion as we run into them for a while.
>  * I expect there'll be a certain amount of stepping on each other's toes, no doubt to clean some things up in one of the subdirectories we'll have to change something in an ancestor directory, but we can deal with those as they come up, probably that'll just mean merging the current master with the fork we're working on...
> Let me know what you think or if you'd like to change the approach.
> Oh, and all I did here was take the second subdirectory of solr/core that I found, feel free to take on something else.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org