L.S.,

The Sonar guys have been so kind to set up reports:
- for ServiceMix Components on
http://nemo.sonar.codehaus.org/project/index/org.apache.servicemix:all-components
- for ServiceMix 4 on
http://nemo.sonar.codehaus.org/project/index/org.apache.servicemix:all

Haven't really looked at the reports in detail, but at first glance it
looks like we could do with a few extra unit tests here and there.
For the other reports, not everything is relevant but some of the
things (like e.g. unused imports) should be very easy to fix I guess.

Regards,

Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



2009/4/18 Chris Custine <[email protected]>:
> Sounds great to me Gert.  I really like the idea of sending a summary email
> to dev@ list maybe on a weekly basis in addition to the web summary.  As
> long as I don't have to convert someones tabs to spaces, or properly indent
> someone else's code to get my code to build, I will be happy  :-D
>
> --
> Chris Custine
> FUSESource :: http://fusesource.com
> My Blog :: http://blog.organicelement.com
> Apache ServiceMix :: http://servicemix.apache.org
> Apache Directory Server :: http://directory.apache.org
>
>
> On Thu, Apr 16, 2009 at 9:36 AM, Gert Vanthienen
> <[email protected]>wrote:
>
>> Chris,
>>
>> To avoid breaking each other's build, I'd make it available in on a
>> public server somewhere (hudson or sonar) for people to consult it.
>> We can always send an occasional mail to the dev@ list if our metrics
>> are bad to get people's attention.
>>
>> Personally, I'd avoid adding it again in the default build.  Adding it
>> to Sonar would be the easy way to go, because it takes no work
>> whatsoever on our side.  Adding it in a build profile is a bit more
>> work, but it would allow people to run things themselves it they
>> really want to.  For me, I'd just say we go for Sonar first and add
>> more custom metrics to Hudson if we want those or if we want to be
>> able to run them ourselves.
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> Open Source SOA: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>>
>>
>> 2009/4/16 Chris Custine <[email protected]>:
>> > +1
>> >
>> > The problem before was that this was all enabled by default so it ran on
>> > every local build.  So then if someone committed code and disabled
>> > checkstyle but had syntax or style errors, then everyone else had
>> failures
>> > and would have to fix the code themselves usually.
>> >
>> > Are you proposing that we disable some of the strict style checks, or are
>> > you saying that we just have them available on the CI builds for
>> reference
>> > and periodic fixing?
>> >
>> > Chris
>> > --
>> > Chris Custine
>> > FUSESource :: http://fusesource.com
>> > My Blog :: http://blog.organicelement.com
>> > Apache ServiceMix :: http://servicemix.apache.org
>> > Apache Directory Server :: http://directory.apache.org
>> >
>> >
>> > On Thu, Apr 16, 2009 at 2:31 AM, Gert Vanthienen
>> > <[email protected]>wrote:
>> >
>> >> L.S.,
>> >>
>> >> For a long time, we've had CheckStyle/PMD enabled on ServiceMix 3 and
>> >> the components.  The problem with this was that it was interfering
>> >> with day-to-day development work: builds taking longer, IDEs need to
>> >> be configured properly to apply the code conventions correctly, ...
>> >>
>> >> I'd like to propose to setup CI builds that do
>> >> Cobertura/CheckStyle/PMD/... checks so we at least have some metrics
>> >> on code quality.  I know metrics are not absolute, but they can at
>> >> least help us identify which areas of the code need some work.  One
>> >> option would be to ask the Sonar guys if they could add us to their
>> >> public instance (http://nemo.sonar.codehaus.org/), the other solution
>> >> would be to add it to a CI profile in our own POMs that we can run on
>> >> Hudson.
>> >>
>> >> Regards,
>> >>
>> >> Gert Vanthienen
>> >> ------------------------
>> >> Open Source SOA: http://fusesource.com
>> >> Blog: http://gertvanthienen.blogspot.com/
>> >>
>> >
>>
>

Reply via email to