You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Hubert, Eric" <Er...@foxmobile.com> on 2009/03/08 23:25:27 UTC
Offer to support Synapse development
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: http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/modules
Have you ever considered setting up a doc job for Synapse using the following plugins:
http://wiki.hudson-ci.org/display/HUDSON/FindBugs+Plugin
http://wiki.hudson-ci.org/display/HUDSON/PMD+Plugin
http://wiki.hudson-ci.org/display/HUDSON/Checkstyle+Plugin
http://wiki.hudson-ci.org/display/HUDSON/Cobertura+Plugin
http://wiki.hudson-ci.org/display/HUDSON/DRY+Plugin
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 above.
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:
https://issues.apache.org/jira/browse/SYNAPSE-514
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.
Regards,
Eric
RE: Offer to support Synapse development
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Hi,
I don't know too much about the corresponding Maven2 plugins and in
which phase of the lifecycle they normally operate, but I have a very
knowledgeable colleague who also did our Hudson setup. So I can easily
get all the needed information. I agree that it does not make sense to
run those reports with every build. It takes time and consumes
resources. In Hudson we do have a special documentation job accompanying
each build job which by default runs only once a day. From my
perspective this is totally sufficient to collect quality metrics and
let tools check for bad practice and bug patterns.
The integration in Hudson is therefore useful, as it offers a very
convenient way to obtain those reports and also important check the
trend conveniently. The tricky part is the selection/configuration of
rules/rulesets to apply. My suggestion: start with a rather small set
and increase it incrementally. The same configuration as used in CI
should be used inside the IDE with the respective plugins. Most
favourite IDEs have nowadays rather sufficient support for those tools.
Regards,
Eric
________________________________
From: Ruwan Linton [mailto:ruwan.linton@gmail.com]
Sent: Sunday, March 15, 2009 10:33 PM
To: dev@synapse.apache.org
Subject: Re: Offer to support Synapse development
I too agree with Eric here, though they seem to be doing the same thing,
each of these have it's own focuses and I would like to see all three
reports. Thanks Eric for the nice explanation.
So, how are we planning to execute this? Are we going to use the
respective maven plugins, if so I would suggest using a different
profile for these reports without affecting the normal build flow.
AFAIK, these reports are generated at the reporting phase of the maven
execution, but of course FindBugs and PMD comes at the compile phase to
collect the information to be presented in the report.
Thanks,
Ruwan
On Mon, Mar 16, 2009 at 2:31 AM, Hubert, Eric
<Er...@foxmobile.com> wrote:
> Cool!
>
> Now, probably it doesn't make sense to use both PMD and findbugs,
> especially if we use annotations to suppress specific warnings. Do you
> have an idea which one is better?
>From my personal experiences this is not true. It makes sense to use
both of them in parallel, because although there is in fact some
overlapping, they have strength and weaknesses in different areas. It is
possible to configure them in a way to reduce the overlapping (not
suppressing rules in code, but exclude some rules from the applied
ruleset of each tool). Overall PMD is a bit more useful in CI where
Findbugs can also help if executed on demand.
Findbugs detects bugs, which PMD can't (bytecode versus source code
analysis). Number of false positives is higher for Findbugs.
A while back a colleague prepared a presentation. One picture was quite
useful to demonstrate the different focus of those tools. I attached it
to the mail. Hope it comes through...
Actually we ended up integrating Checkstyle, PMD and Findbugs in CI.
Additionally to the picture here some of my experiences regarding the
strength/weaknesses of the tools:
Checkstyle
----------
Focus: CONVENTIONS
Naming, code format, consistence code/JavaDoc, design suggestions
Pro:
+ good for big, distributed teams to achieve style consistency
+ some design metrics are pretty useful to improve the code (decrease
complexity)
Contra:
- configuration always necessary
- if used in conjunction with code formatter, rules need to be adjusted
to avoid conflicts
- if a project has been setup without checkstyle right from the
beginning, IDE integration can be painful due to too many violations
"for peanuts" (whitespace problems, tab instead of space etc.); rules
should then be applied stepwise
PMD
---
Focus: AVOID BAD PRACTICES
Identifies useless control flow, find missing freeing of resources,
suggestions for performance improvements, identifies redundant checks
etc.
Pro:
+ very good explanation of each violation (including reasoning and hints
to do it better
+ grouping of rules to rulesets
+ highly customizable (rules in editable xml)
+ extendable (Java/XML knowledge needed)
Contra:
- depending on the ruleset, PMD can also output a great number of
warnings
Findbugs
--------
Focus: FIND POTENTIAL BUGS
Pro:
+ identifies real bugs (NPE, Death Store, multithreading problems due to
wrong synchronization)
Contra:
- number of false positives (problems with compile optimizations,
dependency injection etc.)
Very interesting is also what's going on in the sonar open source
project:
http://sonar.codehaus.org/
Here you can find something in action:
http://nemo.sonar.codehaus.org/
They also think that all the above tools are valuable and try to
integrate their results.
They have also a Hudson plugin available, but I did not find time to
investigate:
http://sonar.codehaus.org/a-new-hudson-plugin-for-a-closer-integration-w
ith-sonar/
Regards,
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
--
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB;
http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: Offer to support Synapse development
Posted by Ruwan Linton <ru...@gmail.com>.
I too agree with Eric here, though they seem to be doing the same thing,
each of these have it's own focuses and I would like to see all three
reports. Thanks Eric for the nice explanation.
So, how are we planning to execute this? Are we going to use the respective
maven plugins, if so I would suggest using a different profile for these
reports without affecting the normal build flow. AFAIK, these reports are
generated at the reporting phase of the maven execution, but of course
FindBugs and PMD comes at the compile phase to collect the information to be
presented in the report.
Thanks,
Ruwan
On Mon, Mar 16, 2009 at 2:31 AM, Hubert, Eric <Er...@foxmobile.com>wrote:
> > Cool!
> >
> > Now, probably it doesn't make sense to use both PMD and findbugs,
> > especially if we use annotations to suppress specific warnings. Do you
> > have an idea which one is better?
>
> From my personal experiences this is not true. It makes sense to use both
> of them in parallel, because although there is in fact some overlapping,
> they have strength and weaknesses in different areas. It is possible to
> configure them in a way to reduce the overlapping (not suppressing rules in
> code, but exclude some rules from the applied ruleset of each tool). Overall
> PMD is a bit more useful in CI where Findbugs can also help if executed on
> demand.
> Findbugs detects bugs, which PMD can't (bytecode versus source code
> analysis). Number of false positives is higher for Findbugs.
>
> A while back a colleague prepared a presentation. One picture was quite
> useful to demonstrate the different focus of those tools. I attached it to
> the mail. Hope it comes through...
> Actually we ended up integrating Checkstyle, PMD and Findbugs in CI.
>
> Additionally to the picture here some of my experiences regarding the
> strength/weaknesses of the tools:
>
> Checkstyle
> ----------
> Focus: CONVENTIONS
> Naming, code format, consistence code/JavaDoc, design suggestions
>
> Pro:
> + good for big, distributed teams to achieve style consistency
> + some design metrics are pretty useful to improve the code (decrease
> complexity)
>
> Contra:
> - configuration always necessary
> - if used in conjunction with code formatter, rules need to be adjusted to
> avoid conflicts
> - if a project has been setup without checkstyle right from the beginning,
> IDE integration can be painful due to too many violations "for peanuts"
> (whitespace problems, tab instead of space etc.); rules should then be
> applied stepwise
>
>
> PMD
> ---
> Focus: AVOID BAD PRACTICES
> Identifies useless control flow, find missing freeing of resources,
> suggestions for performance improvements, identifies redundant checks etc.
>
> Pro:
> + very good explanation of each violation (including reasoning and hints to
> do it better
> + grouping of rules to rulesets
> + highly customizable (rules in editable xml)
> + extendable (Java/XML knowledge needed)
>
> Contra:
> - depending on the ruleset, PMD can also output a great number of warnings
>
>
> Findbugs
> --------
> Focus: FIND POTENTIAL BUGS
>
> Pro:
> + identifies real bugs (NPE, Death Store, multithreading problems due to
> wrong synchronization)
>
> Contra:
> - number of false positives (problems with compile optimizations,
> dependency injection etc.)
>
>
> Very interesting is also what's going on in the sonar open source project:
> http://sonar.codehaus.org/
>
> Here you can find something in action:
> http://nemo.sonar.codehaus.org/
>
> They also think that all the above tools are valuable and try to integrate
> their results.
>
> They have also a Hudson plugin available, but I did not find time to
> investigate:
>
> http://sonar.codehaus.org/a-new-hudson-plugin-for-a-closer-integration-with-sonar/
>
>
> Regards,
> Eric
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
--
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
RE: Offer to support Synapse development
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
> Cool!
>
> Now, probably it doesn't make sense to use both PMD and findbugs,
> especially if we use annotations to suppress specific warnings. Do you
> have an idea which one is better?
From my personal experiences this is not true. It makes sense to use both of them in parallel, because although there is in fact some overlapping, they have strength and weaknesses in different areas. It is possible to configure them in a way to reduce the overlapping (not suppressing rules in code, but exclude some rules from the applied ruleset of each tool). Overall PMD is a bit more useful in CI where Findbugs can also help if executed on demand.
Findbugs detects bugs, which PMD can't (bytecode versus source code analysis). Number of false positives is higher for Findbugs.
A while back a colleague prepared a presentation. One picture was quite useful to demonstrate the different focus of those tools. I attached it to the mail. Hope it comes through...
Actually we ended up integrating Checkstyle, PMD and Findbugs in CI.
Additionally to the picture here some of my experiences regarding the strength/weaknesses of the tools:
Checkstyle
----------
Focus: CONVENTIONS
Naming, code format, consistence code/JavaDoc, design suggestions
Pro:
+ good for big, distributed teams to achieve style consistency
+ some design metrics are pretty useful to improve the code (decrease complexity)
Contra:
- configuration always necessary
- if used in conjunction with code formatter, rules need to be adjusted to avoid conflicts
- if a project has been setup without checkstyle right from the beginning, IDE integration can be painful due to too many violations "for peanuts" (whitespace problems, tab instead of space etc.); rules should then be applied stepwise
PMD
---
Focus: AVOID BAD PRACTICES
Identifies useless control flow, find missing freeing of resources, suggestions for performance improvements, identifies redundant checks etc.
Pro:
+ very good explanation of each violation (including reasoning and hints to do it better
+ grouping of rules to rulesets
+ highly customizable (rules in editable xml)
+ extendable (Java/XML knowledge needed)
Contra:
- depending on the ruleset, PMD can also output a great number of warnings
Findbugs
--------
Focus: FIND POTENTIAL BUGS
Pro:
+ identifies real bugs (NPE, Death Store, multithreading problems due to wrong synchronization)
Contra:
- number of false positives (problems with compile optimizations, dependency injection etc.)
Very interesting is also what's going on in the sonar open source project:
http://sonar.codehaus.org/
Here you can find something in action:
http://nemo.sonar.codehaus.org/
They also think that all the above tools are valuable and try to integrate their results.
They have also a Hudson plugin available, but I did not find time to investigate:
http://sonar.codehaus.org/a-new-hudson-plugin-for-a-closer-integration-with-sonar/
Regards,
Eric
Re: Offer to support Synapse development
Posted by Andreas Veithen <an...@gmail.com>.
Cool!
Now, probably it doesn't make sense to use both PMD and findbugs,
especially if we use annotations to suppress specific warnings. Do you
have an idea which one is better?
Andreas
On Sat, Mar 14, 2009 at 17:11, Hubert, Eric <Er...@foxmobile.com> wrote:
> Hi Andreas,
>
>> Is it possible to tell Findbugs and/or PMD to ignore specific false
>> positives using annotations (either Javadoc style or Java 5)?
> Sorry, I completely forgot to answer this question. In addition to specifying a specific ruleset it is possible to deactivate a rule in a specific context. This should be accompanied with a comment, of course.
>
> As PMD works on the source code it is possible to use the normal @SuppressWarnings annotation in the following format
> @SuppressWarnings("PMD.rulename")
>
> If you are working with Eclipse, you then have to ignore a warning of an unknown suppression, or something like that (Eclipse compiler setting).
> PMD recognizes this suppression.
>
> Also see:
> http://pmd.sourceforge.net/suppressing.html
>
>
> For Findbugs this can obviously not work, as Findbugs operates on the bytecode and the java.lang.SuppressWarnings annotation has source not runtime rentention.
> Therefore Findbugs defines its own Annotation:
> @edu.umd.cs.findbugs.annotations.SuppressWarnings(value="rulename")
>
> Also see:
> http://findbugs.sourceforge.net/manual/annotations.html
>
>
> Regards,
> Eric
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
RE: Offer to support Synapse development
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Hi Andreas,
> Is it possible to tell Findbugs and/or PMD to ignore specific false
> positives using annotations (either Javadoc style or Java 5)?
Sorry, I completely forgot to answer this question. In addition to specifying a specific ruleset it is possible to deactivate a rule in a specific context. This should be accompanied with a comment, of course.
As PMD works on the source code it is possible to use the normal @SuppressWarnings annotation in the following format
@SuppressWarnings("PMD.rulename")
If you are working with Eclipse, you then have to ignore a warning of an unknown suppression, or something like that (Eclipse compiler setting).
PMD recognizes this suppression.
Also see:
http://pmd.sourceforge.net/suppressing.html
For Findbugs this can obviously not work, as Findbugs operates on the bytecode and the java.lang.SuppressWarnings annotation has source not runtime rentention.
Therefore Findbugs defines its own Annotation:
@edu.umd.cs.findbugs.annotations.SuppressWarnings(value="rulename")
Also see:
http://findbugs.sourceforge.net/manual/annotations.html
Regards,
Eric
Re: Offer to support Synapse development
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, Mar 9, 2009 at 10:10, Hubert, Eric <Er...@foxmobile.com> wrote:
> 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.
>
Is it possible to tell Findbugs and/or PMD to ignore specific false
positives using annotations (either Javadoc style or Java 5)?
>
> 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?
>
One quick win would be to set up one of these tools to check that
every Java file has the correct license header.
>
> 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.
>
>
>
> Thanks,
>
> Eric
>
>
>
> ________________________________
>
> From: Ruwan Linton [mailto:ruwan.linton@gmail.com]
> Sent: Monday, March 09, 2009 12:05 AM
> To: dev@synapse.apache.org
> 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.
>
> Thanks,
> Ruwan
>
> On Mon, Mar 9, 2009 at 3:55 AM, Hubert, Eric <Er...@foxmobile.com>
> 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:
> http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/modules
> Have you ever considered setting up a doc job for Synapse using the
> following plugins:
> http://wiki.hudson-ci.org/display/HUDSON/FindBugs+Plugin
> http://wiki.hudson-ci.org/display/HUDSON/PMD+Plugin
> http://wiki.hudson-ci.org/display/HUDSON/Checkstyle+Plugin
> http://wiki.hudson-ci.org/display/HUDSON/Cobertura+Plugin
> http://wiki.hudson-ci.org/display/HUDSON/DRY+Plugin
>
> 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 above.
>
> 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:
> https://issues.apache.org/jira/browse/SYNAPSE-514
>
> 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.
>
> Regards,
> Eric
>
>
> --
> Ruwan Linton
> http://wso2.org - "Oxygenating the Web Services Platform"
> http://ruwansblog.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Offer to support Synapse development
Posted by Ruwan Linton <ru...@gmail.com>.
On Mon, Mar 9, 2009 at 2:40 PM, Hubert, Eric <Er...@foxmobile.com>wrote:
> 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?
>
Hi Eric,
+1 and I think we could easily get started with synapse-utils module...
Thanks,
Ruwan
>
>
> 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.
>
>
>
> Thanks,
>
> Eric
>
>
> ------------------------------
>
> *From:* Ruwan Linton [mailto:ruwan.linton@gmail.com]
> *Sent:* Monday, March 09, 2009 12:05 AM
> *To:* dev@synapse.apache.org
> *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.
>
> Thanks,
> Ruwan
>
> On Mon, Mar 9, 2009 at 3:55 AM, Hubert, Eric <Er...@foxmobile.com>
> 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:
> http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/modules
> Have you ever considered setting up a doc job for Synapse using the
> following plugins:
> http://wiki.hudson-ci.org/display/HUDSON/FindBugs+Plugin
> http://wiki.hudson-ci.org/display/HUDSON/PMD+Plugin
> http://wiki.hudson-ci.org/display/HUDSON/Checkstyle+Plugin
> http://wiki.hudson-ci.org/display/HUDSON/Cobertura+Plugin
> http://wiki.hudson-ci.org/display/HUDSON/DRY+Plugin
>
> 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 above.
>
> 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:
> https://issues.apache.org/jira/browse/SYNAPSE-514
>
> 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.
>
> Regards,
> Eric
>
>
>
>
> --
> Ruwan Linton
> http://wso2.org - "Oxygenating the Web Services Platform"
> http://ruwansblog.blogspot.com/
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
RE: Offer to support Synapse development
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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.
Thanks,
Eric
________________________________
From: Ruwan Linton [mailto:ruwan.linton@gmail.com]
Sent: Monday, March 09, 2009 12:05 AM
To: dev@synapse.apache.org
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.
Thanks,
Ruwan
On Mon, Mar 9, 2009 at 3:55 AM, Hubert, Eric <Er...@foxmobile.com> 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: http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/modules
Have you ever considered setting up a doc job for Synapse using the following plugins:
http://wiki.hudson-ci.org/display/HUDSON/FindBugs+Plugin
http://wiki.hudson-ci.org/display/HUDSON/PMD+Plugin
http://wiki.hudson-ci.org/display/HUDSON/Checkstyle+Plugin
http://wiki.hudson-ci.org/display/HUDSON/Cobertura+Plugin
http://wiki.hudson-ci.org/display/HUDSON/DRY+Plugin
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 above.
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:
https://issues.apache.org/jira/browse/SYNAPSE-514
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.
Regards,
Eric
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
Re: Offer to support Synapse development
Posted by Ruwan Linton <ru...@gmail.com>.
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.
Thanks,
Ruwan
On Mon, Mar 9, 2009 at 3:55 AM, Hubert, Eric <Er...@foxmobile.com>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:
> http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/modules
> Have you ever considered setting up a doc job for Synapse using the
> following plugins:
> http://wiki.hudson-ci.org/display/HUDSON/FindBugs+Plugin
> http://wiki.hudson-ci.org/display/HUDSON/PMD+Plugin
> http://wiki.hudson-ci.org/display/HUDSON/Checkstyle+Plugin
> http://wiki.hudson-ci.org/display/HUDSON/Cobertura+Plugin
> http://wiki.hudson-ci.org/display/HUDSON/DRY+Plugin
>
> 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 above.
>
> 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:
> https://issues.apache.org/jira/browse/SYNAPSE-514
>
> 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.
>
> Regards,
> Eric
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
RE: Offer to support Synapse development
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Hi all,
> This is great news.. I truly appreciate all your help in the past to
> improve the NIO transport, endpoints and JMX support
Thanks for the positive feedback!
> Do you have any specific JDK 6 stuff in mind? The main issue I see is
> with the BSF mediator.. but I would still like to continue the JDK 1.5
> support going forward
Sorry for being not precise enough. I also would like to keep Java 5 compatibility. So it is not about introduction new fancy Java 6 features in the code. It's basically about being able to
a) run Synapse in production using Java 6
(I don't think there is any issue other than the BSF mediator)
b) build Synapse and run tests using Java 6 runtime environment
(maybe here it is also only the BSFMediator test which fails;
I did not try so far)
Regards,
Eric
Re: Offer to support Synapse development
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Eric
> 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.
>
This is great news.. I truly appreciate all your help in the past to
improve the NIO transport, endpoints and JMX support
> 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.
>
Do you have any specific JDK 6 stuff in mind? The main issue I see is
with the BSF mediator.. but I would still like to continue the JDK 1.5
support going forward
cheers
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org