Re: checkstyle improvements

You are correct about me not answering your questions here, as it would add to an already deteriorating S/N ratio regarding the subject of this thread. Met vriendelijke groet, Pierre Smits *Proud* *contributor* (but unfortunately without privileges)* of* Apache OFBiz ,

Re: checkstyle improvements

Yetus has nothing to do with your copy & paste work so responsibility is on your side. You did not answer any of my questions to understand the values you see in the *concrete* example. Michael Am 19.02.20 um 18:36 schrieb Pierre Smits: As always: with good intentions often comes bad

Re: checkstyle improvements

As always: with good intentions often comes bad execution... You shouldn't have had to post that from the ticket as people can follow the reference. Unless you want to drive home the point you're trying to make about the S/N ratio. As for 3rd party tools used, whatever/wherever/whenever, I am

Re: checkstyle improvements

Your copy comments from yetus have a very bad signal/noise ratio [1]. Let's see for https://issues.apache.org/jira/browse/OFBIZ-10001: === +1 overall                                _ / ___| _   _  ___ ___ ___  ___ ___| | \___ \| | | |/ __/ __/ _ \/ __/ __| |  ___) | |_| | (_| (_|  __/\__

Re: checkstyle improvements

What you find cluttering, I regards as helpful to: - fellow contributors - our (potential) adopters - anyone else working on an OFBiz implementation Met vriendelijke groet, Pierre Smits *Proud* *contributor* (but without privileges)* of* Apache OFBiz , since

Re: checkstyle improvements

No, I did not say or mean anything like that. Not sure where you get that from. Please read again, thanks, Michael Am 19.02.20 um 15:51 schrieb Pierre Smits: Michael, You mean like: - *stop* posting comments to tickets to help fellow contributors and the adopters of our product

Re: checkstyle improvements

Michael, You mean like: - *stop* posting comments to tickets to help fellow contributors and the adopters of our product looking to these contributions to help them decide whether or not to invest in an adoption/implementation of (or looking for guidance on issues they experience

Re: checkstyle improvements

+1 Gil Pierre, can you please stop cluttering the issues with the copy/pasted yetus artifacts from your local environment? At least until we decided to use it and have a setup on the official infrastructure. Thanks, Michael Am 14.02.20 um 16:34 schrieb Gil Portenseigne: Hello Pierre,

Re: checkstyle improvements

Hi Gil, all, I agree. Something like that should not be adopted and incorporated in our vetting processes without a Proof of Concept. Having said that, preliminary results in a local setup look promising. Met vriendelijke groet, Pierre Op vr 14 feb. 2020 16:34 schreef Gil Portenseigne <

Re: checkstyle improvements

Inline, > > I'm kinda prefer the "opposite approach", but we need to discuss if this > > improvement is worth the history lost. > > > > In the example you chose, i see no issue capitalizing module, > > resource and other. Updating the rule offer the ability to write a > > constant like : MoDuLe

Re: checkstyle improvements

Hello Pierre, It is interesting but i guess that will be the next step. Thanks On Fri, Feb 14, 2020 at 09:04:49AM +0100, Pierre Smits wrote: > It seems many projects (including those Apache projects in the Hadoop > sphere) use the works of the Apache Yetus (see [1]) project to do > pre-commit

Re: checkstyle improvements

It seems many projects (including those Apache projects in the Hadoop sphere) use the works of the Apache Yetus (see [1]) project to do pre-commit checks (including IIUC checkstyle, in an automate way) on patch files attached to JIRA tickets and Pull Requests in Github against the latest commit in

Re: checkstyle improvements

Hi Gil, thanks for your thoughts. Inline... Am 13.02.20 um 21:12 schrieb Gil Portenseigne: Hello Michael, Adapting checkstyle configuration is less impacting to our codebase but make us stay different from the java standard. That is the easier path, that will not affect code history. But

Re: checkstyle improvements

Hello Michael, Adapting checkstyle configuration is less impacting to our codebase but make us stay different from the java standard. That is the easier path, that will not affect code history. But about getting nearer from the java standard is IMO a nice to have, to make pure java developer

Re: checkstyle improvements

Hi *, and others (real people included), The project's representations in SonarCloud.io (as a free service via the ASF) gives us up-to-date information on a variety of issues related to the various types of code (java, groovy, js, xml, etc.), like: - bugs - security hotspots - code

Re: checkstyle improvements

Thanks for your feedback, Dan. Engaging new contributors was one of the positive effects I had in mind too. If we'd do refactorings per class/package, it should be good to handle. We had good experience during the FindBugs initiative [1]. Thanks, Michael Brohl ecomify GmbH - www.ecomify.de

Re: checkstyle improvements

Inline... Le 13/02/2020 à 17:44, Michael Brohl a écrit : Hi *, checkstyle currently reports a huge amount of errors. We currently have an error count setup in the configuration to prevent the build from failing because of the present errors. Some thoughts/questions to the community: *

Re: checkstyle improvements

Hi Michael, Improving the checkstyle/findbugs metrics could be a good theme for the February Community Days as these sorts of fixes are often low risk and you get a lot of help from your IDE. These sorts of tasks are often a good way for new developers to get involved as they don't require

checkstyle improvements

Hi *, checkstyle currently reports a huge amount of errors. We currently have an error count setup in the configuration to prevent the build from failing because of the present errors. Some thoughts/questions to the community: * should we take an approach to fine-tune the  configuration so