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
