[
https://issues.apache.org/jira/browse/SOLR-11973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17134248#comment-17134248
]
Erick Erickson commented on SOLR-11973:
---------------------------------------
We're getting perilously close to having warning-free compilations on master.
Once that's accomplished, I intend to see if we can fail compilation on
warnings. We'll still be able to get around that by adding SuppressWarnings.
I'll warn you in advance that I've enhanced the BadApple report to flag files
that have increases in that annotation week-to-week and I'll nag people about
adding them rather than addressing the cause.
Deprecations are _not_ included in this, that's another topic entirely. This is
all the annoying "rawtypes", "unchecked", "try", blah blah blah.
So before I go there, I'd like some consensus about whether this is A Good Idea
or not.
My take is that yes it is. We've ignored this kind of thing for years. the
result is that there were over 5,000 such warnings in the code when I started.
Some of this is legacy in the sense that some of the code was written on old
versions of Java. Some of it is by example (hey, I see over here that something
like "List<String> = new ArrayList();" is used, so I guess that's OK). Some of
it is because nobody (including me) has actually paid any attention to warnings
for years.
It's far too vast a job to correct these all at once. And it's always
questionable whether or not to rewrite lots of code for this kind of thing
unless you're fixing something functional. The idea here is to get better going
forward; "progress not perfection".
So, if we start failing compilations for new/changed code that generates
warnings, I believe the code quality will improve. Plus it'll make people learn
about generics ;). We need all the help from the compiler we can get.
So my questions:
1> do people strenuously object or not? If you object, how do you propose
getting better? What we've been doing clearly hasn't worked.
2> Should this be master-only or include 8x? If the latter, we'll need to run a
separate pass on 8x to pick up any differences. So far, we've only been
insuring that master is warning free, and backporting to 8x without checking
whether there were still warnings reported when it was safe. Backporting when
it's safe has been largely to keep the code lines in sync so it wouldn't
interfere with other work unnecessarily. I propose failing only on master.
3> Gradle-only or both Gradle and Ant? I propose both if it's easy.
4> Solr and Lucene both? I propose both.
Timeframe: Master should be warning-free sometime next week. I'd like to
immediately implement any decisions here when that's true.
> Selectively fail on precommit WARN messages
> -------------------------------------------
>
> Key: SOLR-11973
> URL: https://issues.apache.org/jira/browse/SOLR-11973
> Project: Solr
> Issue Type: Improvement
> Components: Build
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Minor
>
> Not quite sure whether this qualifies as something for Solr or Lucene....
> I'm working gradually on getting precommit lint warnings out of the code
> base. I'd like to selectively fail a subtree once it's clean. I played around
> a bit with Robert's suggestions on the dev list but couldn't quite get it to
> work, then decided I needed to focus on one thing at a time.
> See SOLR-10809 for the first clean directory Real Soon Now.
> Bonus points would be working out how to fail on deprecation warnings when
> building Solr too, although that's farther off in the future.
> Assigning to myself, but anyone who knows the build ins and outs _please_
> feel free to take it!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
