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 < gil.portensei...@nereide.fr>: > 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 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 the branch. This may be helpful to lessen the burden on > > the contributor. When configured correctly, the test results appear in > the > > ticket. Apache HBASE is such a project using Yetus, See as an example [2] > > where test results are included through comments of 'Hadoop QA'. > > > > Maybe we should consider this for our project? > > > > > > [1] https://yetus.apache.org > > [2] > > > https://issues.apache.org/jira/browse/HBASE-14498?jql=project%20%3D%20HBASE%20AND%20status%20%3D%20%22Patch%20Available%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > > > > Best regards, > > > > Pierre Smits > > *Proud* *contributor* (but without privileges)* of* Apache OFBiz > > <https://ofbiz.apache.org/>, since 2008 > > > > *Apache Trafodion <https://trafodion.apache.org>, Vice President* > > *Apache Directory <https://directory.apache.org>, PMC Member* > > Apache Incubator <https://incubator.apache.org>, committer > > Apache Steve <https://steve.apache.org>, committer > > > > > > On Thu, Feb 13, 2020 at 9:13 PM Gil Portenseigne < > > gil.portensei...@nereide.fr> wrote: > > > > > 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 feel better discovering OFBiz. > > > 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 :-). > > > > > > Lots of errors are about line that are 120+ length, missing or uneeded > > > space etc. > > > > > > So that will lead to loads of unrisky modifications. With the usage of > > > IDE with checkstyle plugin this can be done nicely. > > > I check that over the near thousand of java file concerned more than > 80% > > > have less than 50 issue... So we can focus our effort onto the big > files > > > using a branch to test the idea and ease the issue. > > > > > > And like Daniel said, it is a good subject for a community week effort. > > > > > > I'd really like to be able to efficiently use this feature, in one way > > > or the other, so thank you for starting this discussion. > > > > > > Regards, > > > > > > Gil > > > > > > > > > On Thu, Feb 13, 2020 at 05:44:40PM +0100, Michael Brohl wrote: > > > > 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 that > it > > > > better fits the project style? > > > > > > > > As an example, constants are currently not allowed to be named > "module", > > > > "resource" etc. which is a common pattern in our code. Changing from > > > > ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$ to > ^[a-zA-Z][a-zA-Z0-9]*(_[a-zA-Z0-9]+)*$ > > > > would allow the common naming. > > > > > > > > The opposite approach would be to rename those to fit the default > > > settings. > > > > > > > > * should we start an initiative to remove the valid errors like we > did > > > with > > > > the FindBugs initiative some time ago? > > > > > > > > > > > > Thanks for your feedback, > > > > > > > > Michael Brohl > > > > > > > > ecomify GmbH - www.ecomify.de > > > > > > > > > > > > > > > > > >
