Yeah, conceptually precommit seems right. OTOH, “anything that uses javac.args” (or gradle/defaults-java.gradle) is easy (I think at least) IOW including this in the compile-time flags wherever it’s used. This looks to be trivial and would include compilation, and by adding it to javac.args it gets in both I think (one of the several things I need to check).
Not everyone runs precommit. Everyone has to run compile to do anything. I agree that it’d be a pain for our compilations to fail when developing, one option is to provide an easy way to disable that fail. However, that would still be easy to forget to undo and then check in. Paying attention to the “inspections” in IntelliJ, for instance, makes it easy to write it right the first time. You don’t even have to do anything special, warnings are highlighted. I’m not doctrinaire about this, although I’ll push back if people insist on not having the fails only during compilation _and_ it’s complicated to do it in precommit (check -x test in Gradle). I’m gathering preferences at this point, I haven’t really looked at what it would take to actually do it yet so my opinion may change... > On Jun 18, 2020, at 4:47 PM, Michael Sokolov <msoko...@gmail.com> wrote: > > Which target are you proposing to have fail? precommit seems like the > right place to me .. > > On Thu, Jun 18, 2020 at 3:49 PM Erick Erickson (Jira) <j...@apache.org> wrote: >> >> Erick Erickson created LUCENE-9411: >> -------------------------------------- >> >> Summary: Fail complation on warnings >> Key: LUCENE-9411 >> URL: https://issues.apache.org/jira/browse/LUCENE-9411 >> Project: Lucene - Core >> Issue Type: Improvement >> Components: general/build >> Reporter: Erick Erickson >> Assignee: Erick Erickson >> >> >> Moving this over here from SOLR-11973 since it's part of the build system >> and affects Lucene as well as Solr. You might want to see the discussion >> there. >> >> We have a clean compile for both Solr and Lucene, no rawtypes, unchecked, >> try, etc. warnings. There are some peculiar warnings (things like >> SuppressFBWarnings, i.e. FindBugs) that I'm not sure about at all, but let's >> assume those are not a problem. Now I'd like to start failing the >> compilation if people write new code that generates warnings. >> >> From what I can tell, just adding the flag is easy in both the Gradle and >> Ant builds. I still have to prove out that adding -Werrors does what I >> expect, i.e. succeeds now and fails when I introduce warnings. >> >> But let's assume that works. Are there objections to this idea generally? I >> hope to have some data by next Monday. >> >> FWIW, the Lucene code base had far fewer issues than Solr, but >> common-build.xml is in Lucene. >> >> >> >> >> >> -- >> 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 >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
