ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Dixit <deepak.di...@hotwaxsystems.com>
Subject Re: Call to action: fixing defects reported by code analysis tools
Date Sat, 08 Jul 2017 06:06:37 GMT
+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.roux@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.brohl@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message