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/ >> >
