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 < > [email protected]> 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 > > > > > > > > > > > >
signature.asc
Description: PGP signature
