Hi Ted... I wouldn't say there's no one interested in fixing the errors
:) I offered to do it some time ago, and I'm still willing (and my time
has freed up again, so able as well!)
I just started going through them... my plan was to do one package in
Core and see if anyone was willing to commit them.
I'm seeing two interesting issues though, and they seem to account for
the vast majority of the complaints...
* There seems to be quite a few places where methods throw runtime
exceptions but do not declare them as thrown, yet there are @throws
clauses for them in the javadoc header. How does everyone want to
handle them? I'd be inclined to declare them as thrown... anyone have
any thoughts? Would that break anything that I'm not thinking of? (if
my basic Java knowledge memory is accurate, you still don't have to
catch a runtime exception, even if the called method declares it as
thrown, right?)
* There are a whole bunch of these types of issues:
"Variable xxxx must be private and have accessor methods."
All of them that I've looked at thus far are protected fields. Looking
at that Checkstyle rule, there is an "allowProtected/Package" setting,
which sounds like what we'd want to change to get rid of these... I
doubt very much we actually want to make these fields private :) Any
thoughts on that?
If we dealt with these two things as described here, I could probably
have all but a handful of the issues resolved in the o.a.s.action
package tonight, then if someone is willing to commit them, I'd be happy
to continue on with the rest of the SAF1 codebase.
Frank
Ted Husted wrote:
Yes, as to Action1, the vast majority of the style errors are a fair
cop and reflect things we shouldn't be doing.
Of course, as far as Action 1 is concerned, it's a fair question of
whether the checkstyle report adds any value. No one appears
interested in fixing the errors, and so there are still so many errors
that new ones go unnoticed.
I notice that as to Action2, the check style plugin is commented out.
I tried enabling it on my working copy, but then it wouldn't build.
: reference not found: ConversionErrorInterceptor
C:/projects/Apache/struts-current/action2/core/src/main/java/org/apache/struts/action2/dispatcher/VelocityResult.java:80:
warning - Tag @link: reference not found: JspFactory
at
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(Abs
tractJavadocMojo.java:845)
at
org.apache.maven.plugin.javadoc.JavadocReport.generate(JavadocReport.
java:104)
at
org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.
java:802)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:301)
... 18 more
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 28 seconds
[INFO] Finished at: Sun Jun 11 20:58:44 EDT 2006
[INFO] Final Memory: 20M/35M
[INFO]
------------------------------------------------------------------------
Do we know what is the problem with running checkstyle with Action2?
-Ted.
On 6/11/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
You can blame whoever wrote the code. ;-) The Checkstyle rules for Struts
have been in place for _years_, and it's been trivial to run a Checkstyle
report for almost as long - even before we had 'ant release'. The
original
rules were based on the Sun / Craig coding conventions, so you shouldn't
have a problem with them the way they are now. ;-) I am not in favour of
changing them to reflect the mess the code base has got into. That's like
changing the law just because people keep breaking it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
