+1 nice initiative Michael!! Thanks & Regards -- Deepak Dixit www.hotwaxsystems.com www.hotwax.co
On Fri, Jul 7, 2017 at 7:05 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 07/07/2017 à 15:12, Michael Brohl a écrit : > >> Avoiding duplicate errors should be managed through Jira. If someone >> wants to work on a class or package, he should file a Jira first so that >> everyone can see that this is being worked on. >> > Agreed, having one wiki page as reference could also help > >> The Jenkins FindBugs plugin/publisher has a very good output with >> different filters and bug classification while the standard FindBugs html >> report is usable but far from clear. The advantage is that it is only one >> html file. >> > Then we can create a wiki page an include it in, right? > > Jacques > > >> Michael Brohl >> ecomify GmbH >> www.ecomify.de >> >> >> Am 07.07.17 um 14:14 schrieb Jacques Le Roux: >> >>> I agree with Michael at OFBIZ-9450 that having "the results available >>> to the public so that the community can always access the latest bug >>> statistics." should reduce duplicated efforts. >>> >>> If we can produce the report in HTML format, then we can create a page >>> in wiki and include the report in this page from any URL. I guess any URL >>> will fit, else if we need more security (should not be needed, only >>> authenticated authors can change a wiki page) we can have it in the svn >>> repo or a Jira link, etc. >>> >>> Jacques >>> >>> >>> Le 07/07/2017 à 12:47, Taher Alkhateeb a écrit : >>> >>>> Fantastic initiative Michael, +1 >>>> >>>> I think a simple attachment in jira or a wiki page will suffice. A >>>> one-time scan would provide more than enough information for everyone >>>> who needs to work on stuff. We can run it again in the future when >>>> enough bugs have been tackled. >>>> >>>> On Fri, Jul 7, 2017 at 1:43 PM, Michael Brohl <michael.br...@ecomify.de> >>>> wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> we started the first activities in Jira [1]. >>>>> >>>>> We have set up an OFBiz build on our Jenkins server who automatically >>>>> does a >>>>> FindBugs code analysis after each commit >>>>> >>>>> I'm thinking about publishing the results on a web server. This should >>>>> help >>>>> to engage contributors to work on the bugs without the need to do the >>>>> analysis themselves (quick jump in). >>>>> >>>>> Are there any objections to do this? >>>>> >>>>> Do we have a webspace for this which I can use or would it be >>>>> appropriate to >>>>> publish results on one of our servers? >>>>> >>>>> There are even projects which publish the metrics on their website [2]. >>>>> >>>>> Best regards, >>>>> >>>>> Michael Brohl >>>>> ecomify GmbH >>>>> www.ecomify.de >>>>> >>>>> [1] https://issues.apache.org/jira/browse/OFBIZ-9450 >>>>> >>>>> [2] >>>>> http://db.apache.org/torque/torque-3.3/releases/torque-3.3/ >>>>> generator/maven-reports.html >>>>> >>>>> >>>>> Am 29.06.17 um 12:16 schrieb Michael Brohl: >>>>> >>>>> Hi all, >>>>>> >>>>>> just wanted to bring this back in mind in case there are people >>>>>> interested >>>>>> in helping out with this. >>>>>> >>>>>> Every support is well appreciated, thank you! >>>>>> >>>>>> Regards, >>>>>> >>>>>> Michael Brohl >>>>>> ecomify GmbH >>>>>> www.ecomify.de >>>>>> >>>>>> >>>>>> Am 13.12.16 um 18:35 schrieb Jacopo Cappellato: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> thanks to Gradle we have now an easy way to run source code analysis >>>>>>> tools >>>>>>> on our codebase. >>>>>>> Tools like PMD and FindBugs generate useful reports containing >>>>>>> pointers >>>>>>> to >>>>>>> code that may need to be improved or fixed. >>>>>>> In fact I have executed them on trunk and I got reports with >>>>>>> thousands of >>>>>>> "rule violations": some of them are probably false positives but >>>>>>> others >>>>>>> really represent code that can be improved, simplified or, in some >>>>>>> cases, >>>>>>> fixed. >>>>>>> >>>>>>> I think that it would be great if this community will work together >>>>>>> to >>>>>>> fix >>>>>>> as many defects as possible: it may lead to a cleaner codebase, may >>>>>>> increase the confidence of potential adopters that use these tools >>>>>>> to get >>>>>>> some insight on our code quality, and may make it easier for new >>>>>>> contributors to help the project. >>>>>>> >>>>>>> So here are the steps to quickly start the process: >>>>>>> >>>>>>> 1) get a clean checkout of the trunk >>>>>>> >>>>>>> svn co http://svn.apache.org/repos/asf/ofbiz/trunk >>>>>>> >>>>>>> 2) edit the build.gradle file to enable the PMD or FindBugs plugins. >>>>>>> For PMD you can add the following line to the file, after the other >>>>>>> "apply >>>>>>> plugin" commands: >>>>>>> >>>>>>> apply plugin: 'pmd' >>>>>>> >>>>>>> For FindBugs add the following lines: >>>>>>> >>>>>>> apply plugin: 'findbugs' >>>>>>> tasks.withType(FindBugs) { >>>>>>> reports { >>>>>>> xml.enabled false >>>>>>> html.enabled true >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> Apply only pmd or findbugs, not both: the two tools provide different >>>>>>> analysis with plenty of defects but the two tools will spot the same >>>>>>> ones >>>>>>> in most cases, so please choose the tool of your preference and then >>>>>>> start >>>>>>> fixing the code. >>>>>>> >>>>>>> 3) run the analysis with the command: >>>>>>> ./gradlew check >>>>>>> >>>>>>> 4) review the report; >>>>>>> for PMD the report is: >>>>>>> build/reports/pmd/main.html >>>>>>> for FindBugs the report is: >>>>>>> build/reports/findbugs/main.html >>>>>>> >>>>>>> 5) fix some bugs and test; then go back to #3 >>>>>>> >>>>>>> 6) create a patch and submit it to Jira, mentioning that it fixes >>>>>>> defects >>>>>>> reported by PMD/FindBugs >>>>>>> >>>>>>> Feel free to ask here any question! >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> >>>>>> >>>>> >>> >> >> >
