Hi Gert,
thanks for the links, it's interesting. The reports provide some way to
improve code (adding some unit tests, etc).
Regards
JB
Gert Vanthienen wrote:
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/
