Details
-
Sub-task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
Gus Heck Ask and ye shall receive.
Here's how I'd like to approach this:
- Let's start with solr/core, one subdirectory at a time.
- See
SOLR-14474for 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 first subdirectory of solr/core that I found, feel free to take on something else.