Great, thanks! Half the battle is often knowing it's possible.... On Thu, Feb 1, 2018 at 10:48 AM, Robert Muir <rcm...@gmail.com> wrote: > Yes it is important to do it incrementally. > > You can override ant properties in specific modules, by defining them > to be something stricter before importing them from somewhere else. > For example, analysis/icu has no warnings, so override the default > javac.args at the very top, before it "imports" the rest of the build. > > diff --git a/lucene/analysis/icu/build.xml b/lucene/analysis/icu/build.xml > <property name="rat.additional-includes" value="src/tools/**"/> > + <property name="javac.args" value="-Xlint -Xlint:-deprecation > -Xlint:-serial -Werror"/> > <import file="../analysis-module-build.xml"/> > > Now the build will fail if someone introduces a warning into that > module. and you can move on to the next one. > Quick and dirty explanation but you get the idea... > > > On Thu, Feb 1, 2018 at 1:34 PM, Erick Erickson <erickerick...@gmail.com> > wrote: >> You've seen a couple of JIRAs about cleaning up precommit lint >> warnings, and Robert mentioned compiler warnings which I totally agree >> with. >> >> It's just a _lot_ of code to wade through, and it'll be depressing to >> fix up something and have similar stuff creep back in. It'll take >> quite some time to clean them _all_ up, so there'll be quite a window >> for backsliding. >> >> Is there a way to have precommit and build fail for specific parts of >> the code? Let's claim we fix up all the precommit warnings in >> .../solr/core. It'd feel a lot more like progress if we could then >> have any _future_ precommit lint warnings in .../solr/core fail >> precommit even if, say, .../solr/contrib still had a bunch. >> >> Ditto for compiler warnings etc. As you can tell, I'm looking for help >> ;) Or even better "it's already in place if you'd just look".... >> >> How this plays with different versions of Java I don't quite know. We >> may run into some stuff with Java 9 that weren't reported in Java 8 >> and the like so I suspect turning failures on and off based on the JDK >> might be necessary. >> >> Erick >> >> --------------------------------------------------------------------- >> 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 >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
