Michael: If you’d like to have a go at it, please feel free. The easiest way I’ve found is, in master, execute the “assemble” task from the Gradle window in IntelliJ (no clue about Eclipse, but I suspect there’s something similar). Since Lucene has < 100 warnings, you don’t even have to fiddle with changing maxwarns in defaults-java.gradle.
Then the “Run” window lets you click on the warning and go right to the Lucene code. If you do decide to tackle this, please open up a JIRA and link it to SOLR-10778 or make a subtask on SOLR-10778 and have at it. I think with Lucene it's feasible to actually try to address at least some of the warnings rather than the rather mindless “SuppressWarnings” I’m doing with Solr. Up to you of course. Let me know if you start on this. I’ve got another week or so before I’m through Solr at least. Erick > On Jun 7, 2020, at 9:23 AM, Michael Sokolov <[email protected]> wrote: > > I'm all for it. Warnings can be useful if we pay attention to them, which > means cleaning up the ones we don't want to pay attention to, addressing > others as they arise, etc. I would be +1 to a warning free build, and I will > help if you break off a piece, thanks for kicking this off > > On Sun, Jun 7, 2020, 8:57 AM Erick Erickson <[email protected]> wrote: > There are about 100 compile-time warnings in Lucene, not including > deprecations. I’m trying to get all the warnings out or suppressed so we can > stop backsliding by turning up compilation errors to include selected > warnings. > > But I don’t want to muck with Lucene without some consensus on whether this > idea is A Good Thing. So for you folks who work in Lucene a lot, would this > be valuable? Or should I just ignore Lucene? > > I want to emphasize that all I’m really doing at this point is adding > bunches of SuppressWarnings and a few safe changes, things like removing > redundant casts and the like. There are just too many warnings in the code > base to try to do all at once, and it’s usually a bad idea to make wholesale > code changes when the code is working. > > A separate question is whether to enable compile-time errors on warnings > (probably master only) that we can save for later. > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
