I agree with uwe. Start with javac, use -Werror flag and fix those first. Stupid warnings like serialization are already disabled for javac in the build. On Mar 16, 2014 4:48 PM, "Uwe Schindler" <u...@thetaphi.de> wrote:
> Hi, > > > Just because some tool expresses distaste, doesn't imply that everyone > here > > agrees that it's a problem we should fix. > > Yes that is my biggest problem. Lots of warnings by Eclipse are just > bullshit because of the code style in Lucene and for example the way we do > things - e.g., it complains about missing close() all the time, just > because we use IOUtils.closeWhileHandlingExceptions() for that. > > > In my experience, the default Sonar rulesets contain many things that > people > > here are prone to disagree with. Start with serialVersionUID: > > do we care? Why would we care? In what cases to we really believe that a > > sane person would be using Java serialization with a Lucene/Solr class? > > We officially don't support serialization, so all warnings are useless. > It's just Eclipse that complains for no reason. > > > Sonar can also be a bit cranky; it arranges for various tools to run via > > mechanisms that sometimes conflict with the ways you might run them > > yourself. > > > > So I'd suggest a process like: > > > > 1. Someone proposes a set of (e.g.) checkstyle rules to live by. > > 2. That ruleset is refined by experiment. > > 3. We make violations fail the build. > > > > Then lather, rinse, repeat for other tools. > > Yes I agree. I am strongly against PMD or CheckStyle without our own > rules. Forbiddeen-apis was invented because of the brokenness of PMD and > CheckStyle to detect default Locale/Charset/Timezone violations (and also > because those tools are slow). > We should better fix out Eclipse Project generate to hide the warnings > that are just wrong. > > I would prefer: Before we fix warnings by 3rd party tools like Eclipse, we > should first fix only the warnings emitted by Javac. The others are just > unimportant to me and I don't want to fix those which are just wrong for > our code style. > > We already have ECJ in our build (to lint javadocs), we can make some > Eclipse warnings fatal through the ecj config file in our SVN, to fail > build on some warnings. I disagree with using PMD or Checkstyle, those > tools are uncomplete and broken, sorry. > > Uwe > > > Once we have rulesets we agree are worth enforcing, we can look to Sonar > > for a pretty way to visualize their results if we like. > > > > --------------------------------------------------------------------- > > 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 > >
