synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hubert, Eric" <>
Subject RE: Offer to support Synapse development
Date Mon, 09 Mar 2009 09:10:00 GMT
Hi Ruwan,


yes you are able to modify the rule sets. Starting with default rulesets on grown code is
always problematic as you might get swamped with violations of different priorities. Even
though you can filter by priorities it maybe to much what you get. Besides this Findbugs and
PMD may detect false positives under some situations. Nevertheless the output is very valuable.
You just should not concentrate to much on absolute values. PMD and Findbugs does not need
much configuration. Checkstyle should get a custom ruleset according to the projects needs.
Otherwise it may really produce a lot of useless output.


Of course I would be willing to help you to get the configuration right. I’m sure it will
further improve the code quality in the long run. To get something started we would not need
to setup a doc job for the whole project. I think we could also start with a small Maven module
like experimental or handler before jumping on the big ones like transport or core. What do
you think?


Yes I’m aware of the ASF model of becoming a committer. This is a very solid and useful
model. To be honest, sometimes I whish someone would establish the same system in the business
world. ;-)

I will continue to focus on small individual patches.






From: Ruwan Linton [] 
Sent: Monday, March 09, 2009 12:05 AM
Subject: Re: Offer to support Synapse development


Hi Eric,

It is really nice to see you getting on to the code... 

We have integrated the FindBugs, Checkstyle and PMD through the respective maven plugins and
found that they were by default giving a set of issues but after a going through those I have
realized most of them are not really issues, but of couse we have found a set of good issues
that we had as well. I am sure that we can configure the level of error checking but I didn't
tried to go along that path (well, I would say the time factor stopped me in going that line).
Even though we tried this we never get this committed into the svn and got it to run continuously.

I think we better integrate these with correct configurations to get best results and if you
could help us getting there that would be of utmost help.

I think you will have to go through the JIRA and patches model for the contributions for the
moment until you become a committer, well that is how generally apache operates (you may already
know this), and I would prefer to have small patches on one concern than a patch touching
most of the files.

Thanks for the contribution, and it is very valuable for the evolution of this project into
a success product.


On Mon, Mar 9, 2009 at 3:55 AM, Hubert, Eric <> wrote:

Hi Synapse-Devs,

Since more than a year I've been actively following the Synapse users and dev mailings lists.
Some of you may have also noticed my efforts to improve Synapse from a user's perspective
by reporting bugs and submitting feature requests including implementation ideas and minor
code contributions.
I would like to extend this support in the direction of active code development.
As a starting point I checked out Synapse trunk, imported the projects into Eclipse and activated
my normal development toolset (Findbugs, PMD, Checkstyle, EclEmma). Well by having a look
at the number of potential code problems I think there is some room for improvements (as always).

I have seen you guys are using the great Hudson project as your CI environment:
Have you ever considered setting up a doc job for Synapse using the following plugins:

From my personal experiences I can say it's really worth to use it, especially to always have
the trends of those metrics available. You will find some examples on the pages presented

My personal interests regarding Synapse concentrate on the http transports, Hessian application
protocol usage, server management, monitoring, the improvement of error logs for faster problem
recognition, full JDK 6 compatibility, and the separation of implementation and API supporting
custom development of mediators.
Besides this I'm willing to contribute also in other areas, but those are the ones my focus
is on.

The only question is where to start? I don't think it makes much sense to provide dozens of
small code fixes in a great number of patches (per class or package). Too much work during
review. A big patch touching too much files is even worse. Small and independent changes are
important for a suitable review process.

Thus I think it is best to start with small, independent features provided as a patch. As
the very first start I would like to contribute a small enhancement to the Hessian message
builder to detect fault messages.

So I created a new JIRA for it:

I tried to follow the conventions I have found. It would be nice if someone could review the
patch and provide feedback. If you find any problems, I'll correct them.


Ruwan Linton - "Oxygenating the Web Services Platform"

View raw message