codenarc-developer — CodeNarc Developers

Re: [Codenarc-developer] FW: [ codenarc-Feature Requests-3283605 ] new rule: avoid Direct Connection Management

[Hamlet D'A. <ham...@gm...>]

It was a rule ported from the Klocwork project. They call all their
rules "security" rules. If you use a non-pooled DirectConnection then
I suppose you are more at-risk for denial of service. Maybe?

We can move it anywhere we want though.



On Mon, Apr 11, 2011 at 1:32 AM, Chris Mair <chr...@ea...> wrote:
> Hamlet,
>
> I love the new DirectConnectionManagement rule. Great idea. What is the reasoning for making that a "security" rule?
>
> Chris
> -----Original Message-----
> From: SourceForge.net [mailto:no...@so...]
> Sent: Sunday, April 10, 2011 10:38 AM
> To: chr...@ea...
> Subject: [ codenarc-Feature Requests-3283605 ] new rule: avoid Direct Connection Management
>
> Feature Requests item #3283605, was opened at 2011-04-10 09:37 Message generated for change (Comment added) made by hamletdrc You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=1126575&aid=3283605&group_id=250145
>
> Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update.
> Category: None
> Group: None
>>Status: Closed
> Priority: 5
> Private: No
> Submitted By: Hamlet D'Arcy (hamletdrc)
>>Assigned to: Hamlet D'Arcy (hamletdrc)
> Summary: new rule: avoid Direct Connection Management
>
> Initial Comment:
> * DirectConnectionManagement Rule
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  <New in CodeNarc 0.14>
>  The J2EE standard requires that applications use the container's resource management facilities to obtain connections
>  to resources. Every major web application container provides pooled database connection management as part of its
>  resource management framework. Duplicating this functionality in an application is difficult and error prone, which
>  is part of the reason it is forbidden under the J2EE standard.
>
>  For more information see: https://www.fortify.com/vulncat/en/vulncat/java/j2ee_badpractices_getconnection.html
>
>  Example of violations:
>
> -------------------------------------------------------------------------------
>    DriverManager.getConnection()
>    java.sql.DriverManager.getConnection()
> -------------------------------------------------------------------------------
>
>
> ----------------------------------------------------------------------
>
>>Comment By: Hamlet D'Arcy (hamletdrc)
> Date: 2011-04-10 09:38
>
> Message:
> fixed in 0.14
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=1126575&aid=3283605&group_id=250145
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>



-- 
Hamlet D'Arcy
ham...@gm...

[Codenarc-developer] FW: [ codenarc-Feature Requests-3283605 ] new rule: avoid Direct Connection Management

[Chris M. <chr...@ea...>]

Hamlet,

I love the new DirectConnectionManagement rule. Great idea. What is the reasoning for making that a "security" rule?

Chris
-----Original Message-----
From: SourceForge.net [mailto:no...@so...] 
Sent: Sunday, April 10, 2011 10:38 AM
To: chr...@ea...
Subject: [ codenarc-Feature Requests-3283605 ] new rule: avoid Direct Connection Management

Feature Requests item #3283605, was opened at 2011-04-10 09:37 Message generated for change (Comment added) made by hamletdrc You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126575&aid=3283605&group_id=250145

Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Hamlet D'Arcy (hamletdrc)
>Assigned to: Hamlet D'Arcy (hamletdrc)
Summary: new rule: avoid Direct Connection Management

Initial Comment:
* DirectConnectionManagement Rule
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  <New in CodeNarc 0.14>
  The J2EE standard requires that applications use the container's resource management facilities to obtain connections
  to resources. Every major web application container provides pooled database connection management as part of its
  resource management framework. Duplicating this functionality in an application is difficult and error prone, which
  is part of the reason it is forbidden under the J2EE standard.

  For more information see: https://www.fortify.com/vulncat/en/vulncat/java/j2ee_badpractices_getconnection.html

  Example of violations:

-------------------------------------------------------------------------------
    DriverManager.getConnection()
    java.sql.DriverManager.getConnection()
-------------------------------------------------------------------------------


----------------------------------------------------------------------

>Comment By: Hamlet D'Arcy (hamletdrc)
Date: 2011-04-10 09:38

Message:
fixed in 0.14

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126575&aid=3283605&group_id=250145

[Codenarc-developer] [ANN] Announcing CodeNarc 0.13

[Chris M. <chr...@ea...>]

The CodeNarc Team is proud to announce the release of version 0.13. 

CodeNarc <http://codenarc.sourceforge.net/>  is a static analysis tool for Groovy source code. Version 0.13 adds 40 new rules (bringing the total to 206 rules). Try it out on the CodeNarc web console <http://meetcodenarc.appspot.com/edit/14001> , running on Google App Engine.

New Features 

*	New and improved syntax for defining custom rulesets. Just list the rule names you want. No need to specify ruleset filename or rule class. No more tweaking your custom rulesets with every CodeNarc release when we add new rules to the "basic" ruleset or one of the others. Feature #3193684.
*	Better support for command line runners. You can now specify the report type "console" as a command line parameter, and the CodeNarc text report is output to the console instead of a file. Feature #3162487
*	All rules now provide a nicely formatted message. This makes console tools and the CodeNarc Web Console much more user friendly. Feature #3162847
*	Greatly improved styling of the HTML report. Feature #3192593
*	Improved error messages when CodeNarc is mis-configured and configuration file does not compile. Feature #3193468
*	Improved println rule. If a class defines a println() method, then it is OK to call this method because it won't dispatch to System.out.println(). Feature #3194121

New Rules 

Unnecessary/Dead Code 

*	EmptyInstanceInitializer rule (basic) - Feature #3163464 - An empty instance initializer. It is safe to remove it.
*	EmptyStaticInitializer rule (basic) - Feature #3161685 - An empty static initializer was found. It is safe to remove it.
*	EmptyMethod rule (basic) - Feature #3163806 - A method was found without an implementation. If the method is overriding or implementing a parent method, then mark it with the @Override annotation.
*	UnnecessaryCallToSubstring rule (unnecessary) - Feature #3164688 - Calling String.substring(0) always returns the original string. This code is meaningless.
*	UnnecessaryModOne rule (unnecessary) - Feature #3164684 - Any expression mod 1 (exp % 1) is guaranteed to always return zero. This code is probably an error, and should be either (exp & 1) or (exp % 2).
*	UnnecessarySelfAssignment rule (unnecessary) - Feature #3164674 - Method contains a pointless self-assignment to a variable or property.
*	UnnecessaryTransientModifier rule (unnecessary) - Feature #3164672 - The field is marked as transient, but the class isn't Serializable, so marking it as transient has no effect.
*	UnnecessaryFail rule (junit) - Feature #3105925 - In a unit test, catching an exception and immediately calling Assert.fail() is pointless and hides the stack trace. It is better to rethrow the exception or not catch the exception at all.
*	UnnecessaryPublicModifier rule (unnecessary) - Feature #3166320 - The 'public' modifier is not required on methods or classes.
*	UnnecessaryDefInMethodDeclaration rule (unnecessary) - Feature #3165469 - If a method has a visibility modifier, then the def keyword is unneeded. For instance 'def private method() {}' is redundant and can be simplified to 'private method() {}'.
*	UnnecessarySemicolon rule (unnecessary) - Feature #3176207 - Semicolons as line terminators are not required in Groovy: remove them. Do not use a semicolon as a replacement for empty braces on for and while loops; this is a confusing practice.
*	UnnecessaryGString rule (unnecessary) - Feature #3183521 - String objects should be created with single quotes, and GString objects created with double quotes. Creating normal String objects with double quotes is confusing to readers..

Bugs/Bad Practices 

*	AssignmentInConditional rule (basic) - An assignment operator (=) was used in a conditional test. This is usually a typo, and the comparison operator (==) was intended.
*	SerializableClassMustDefineSerialVersionUID rule (basic) - Feature #3161076 - Classes that implement Serializable should define a serialVersionUID.
*	ConsecutiveStringConcatenation rule (basic) - Feature #3163826 - Catches concatenation of two string literals on the same line. These can safely by joined.
*	ConsecutiveLiteralAppends rule (basic) - Feature #3161779 - Violations occur when method calls to append(Object) are chained together with literals as parameters. The chained calls can be joined into one invocation.
*	AddEmptyString rule (basic) - Feature #3161763 - Finds empty string literals which are being added. This is an inefficient way to convert any type to a String.
*	BrokenOddnessCheck rule (basic) - Feature #3164687 - The code uses x % 2 == 1 to check to see if a value is odd, but this won't work for negative numbers (e.g., (-5) % 2 == -1). If this code is intending to check for oddness, consider using x & 1 == 1, or x % 2 != 0.
*	ExceptionExtendsError rule (exceptions) - Feature #3161749 - Errors are system exceptions. Do not extend them.
*	MissingNewInThrowStatementRule (exceptions) - Feature #3166115 - Improved existing rule to catch throwing a class literal, which always causes a RuntimeException.
*	UseAssertTrueInsteadOfAssertEquals (junit) - Feature #3172959 - This rule was expanded to handle assert statements as well as JUnit style assertions.
*	GroovyLangImmutable rule (basic) - Feature #3175158 - The groovy.lang.Immutable annotation has been deprecated and replaced by groovy.transform.Immutable. Do not use the Immutable in groovy.lang.
*	IntegerGetInteger rule (basic) - Feature #3174771 - This rule catches usages of java.lang.Integer.getInteger(String, ...) which reads an Integer from the System properties. It is often mistakenly used to attempt to read user input or parse a String into an Integer. It is a poor piece of API to use; replace it with System.properties['prop'].
*	BooleanGetBoolean rule (basic) - Feature #3174770 - This rule catches usages of java.lang.Boolean.getBoolean(String) which reads a boolean from the System properties. It is often mistakenly used to attempt to read user input or parse a String into a boolean. It is a poor piece of API to use; replace it with System.properties['prop̈́'].
*	ChainedTest rule (junit) - Feature #3175647 - A test methodency that invokes another test method is a chained test; the methods are dependent on one another. Tests should be isolated, and not be dependent on one another.
*	CoupledTestCase rule (junit) - Feature #3175645 - This rule finds test cases that are coupled to other test cases, either by invoking static methods on another test case or by creating instances of another test case. If you require shared logic in test cases then extract that logic to a new class where it can properly be reused.

Concurrency Problems 

·         BusyWait rule (concurrency) - Feature #3170271 - Busy waiting (forcing a Thread.sleep() while waiting on a condition) should be avoided. Prefer using the gate and barrier objects in the java.util.concurrent package.

·         DoubleCheckedLocking rule (concurrency) - Feature #3170263 - This rule detects double checked locking, where a 'lock hint' is tested for null before initializing an object within a synchronized block. Double checked locking does not guarantee correctness and is an anti-pattern.

·         InconsistentPropertyLocking rule (concurrency) - Feature #3164700 - Class contains similarly-named get and set methods where one method of the pair is marked either @WithReadLock or @WithWriteLock and the other is not locked at all.

·         InconsistentPropertySynchronization rule (concurrency) - Feature #3164699 - Class contains similarly-named get and set methods where the set method is synchronized and the get method is not, or the get method is synchronized and the set method is not.

·         StaticCalendarField rule (concurrency) - Feature #3164702 - Calendar objects should not be used as static fields. Calendars are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.

·         StaticDateFormatField rule (concurrency) - DateFormat objects should not be used as static fields. DateFormat are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.

·         StaticMatcherField rule (concurrency) - Feature #3170276 - Matcher objects should not be used as static fields. Calendars are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.

·         SynchronizedOnBoxedPrimitive rule (concurrency) - Feature #3164708 - The code synchronizes on a boxed primitive constant, such as an Integer. Since Integer objects can be cached and shared, this code could be synchronizing on the same object as other, unrelated code, leading to unresponsiveness and possible deadlock

·         SynchronizedOnReentrantLock rule (concurrency) - Feature #3170262 - Synchronizing on a ReentrantLock field is almost never the intended usage. A ReentrantLock should be obtained using the lock() method and released in a finally block using the unlock() method.

·         SynchronizedOnString rule (concurrency) - Feature #3164707 - Synchronization on a String field can lead to deadlock because Strings are interned by the JVM and can be shared.

·         SynchronizedReadObjectMethod rule (concurrency) - Feature #3164704 - Catches Serializable classes that define a synchronized readObject method. By definition, an object created by deserialization is only reachable by one thread, and thus there is no need for readObject() to be synchronized. If the readObject() method itself is causing the object to become visible to another thread, that is an example of very dubious coding style.

·         ThreadGroup rule (concurrency) - Feature #3161692 - Avoid using ThreadGroup; although it is intended to be used in a threaded environment it contains methods that are not thread safe.

·         VolatileArrayField rule (concurrency) - Feature #3170265 - Volatile array fields are unsafe because the contents of the array are not treated as volatile. Changing the entire array reference is visible to other threads, but changing an array element is not.

·         WaitOutsideOfWhileLoop rule (concurrency) - Feature #3127703 - Calls to Object.wait() must be within a while loop. This ensures that the awaited condition has not already been satisfied by another thread before the wait() is invoked. It also ensures that the proper thread was resumed and guards against incorrect notification.

Bug Fixes 

*	Fix Bug #3162499 UnnecessaryObjectReferences: This rule was not ignoring 'this' references, leading to false positives. 
*	Fix Bug #3164150 UnnecessaryReturnKeyword: Rule is no longer triggered if the return is for a closure.
*	Fix Bug #3165139 LoggingSwallowsStacktrace: No longer reports multiple logger errors.
*	Fix bug #3166311: Error on numeric/boolean property values if they contain leading or trailing whitespace in "codenarc.properties" or in XML ruleset file.
*	Fix bug #3170295: @SuppressWarnings does not work with GMetrics-based rules (CC and ABC).
*	Fix bug #3190483: The UnusedPrivateField rule now ignores fields named serialVersionUID. The rule has a property called ignoreFieldNames that can be used to add other ignores as well.
*	Fix bug #3162975: The UnusedPrivate* rules now correctly read anonymous classes.
*	Fix bug #3155974: The UnusedPrivate* rules now correctly read inner classes.
*	Fix bug #3183443: Restricted the ConfusingTernary rule to reduce false positives. The rule looks for inverted conditionals in ternary statements. It did not account for Groovy Truth, and suggested 'x != null' be inverted to 'x', but that is not the inverse. So the rule was relaxed. 
*	Fix bug #3195027: The violation message for "Replace Getter with Property Access" suggests converting ".getURLs()" to ".uRLs". This has been corrected to ".URLs". 
*	Fix bug #3196019: Compiling files with unresolved Grapes dependencies no longer causes an error..

Potential Breaking Changes 

*	addViolation(ASTNode) is deprecated. Instead use addViolation(ASTNode, String) when adding violations to the output.

Thanks 

*	Many thanks to Mathilde Lemée, Guillaume Laforge, and Tim Yates for helping us redesign our HTML report.
*	Big thanks to Evgeny Goldin and Cédric Champeau for reporting bugs which helps us improve the product so much faster..

Visit the CodeNarc Home Page <http://codenarc.sourceforge.net/> 

Re: [Codenarc-developer] 0.13 release planning

[Chris M. <chr...@ea...>]

I agree. I still need to update the sample reports, which I started on
yesterday. I also noticed some of the web pages need a little cleanup. And I
may still try to run the RC against my work projects (it has been a crazy
week).

When I get a chance, I will see what is required to give you access to
upload site files, do the maven stuff. etc.. I never did fix my automated
Maven deploy. After much trial and error, I was able to manually install it
in my local Maven Repo and then copy the files over to the staging repo
manually.  I assume that same process will work for the real release.

Chris
-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Saturday, March 05, 2011 8:05 AM
To: Cod...@li...
Subject: [Codenarc-developer] 0.13 release planning

We have no open defects, all my changes are in, and we have no feedback on
the 0.13 release candidate.

Should we release? I think so.

Our tasks:
* Make a new download button for site (me)
* Upload the new site pages (you)
* Upload new release to maven (you)
* Update Gradle (me)
* Update Grails plugin (you)
* Update the Griffon plugin (me)
* Update CHANGELOG.txt (Done!)
* Write announcement (you)

Anything else? Can I do any other of the tasks?

--
Hamlet D'Arcy
ham...@gm...

----------------------------------------------------------------------------
--
What You Don't Know About Data Connectivity CAN Hurt You This paper provides
an overview of data connectivity, details its effect on application quality,
and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

Re: [Codenarc-developer] 0.13 release planning

[Hamlet D'A. <ham...@gm...>]

The .png "get it" image is checked in.


On Sat, Mar 5, 2011 at 2:04 PM, Hamlet D'Arcy <ham...@gm...> wrote:
> We have no open defects, all my changes are in, and we have no
> feedback on the 0.13 release candidate.
>
> Should we release? I think so.
>
> Our tasks:
> * Make a new download button for site (me)
> * Upload the new site pages (you)
> * Upload new release to maven (you)
> * Update Gradle (me)
> * Update Grails plugin (you)
> * Update the Griffon plugin (me)
> * Update CHANGELOG.txt (Done!)
> * Write announcement (you)
>
> Anything else? Can I do any other of the tasks?
>
> --
> Hamlet D'Arcy
> ham...@gm...
>



-- 
Hamlet D'Arcy
ham...@gm...

[Codenarc-developer] 0.13 release planning

[Hamlet D'A. <ham...@gm...>]

We have no open defects, all my changes are in, and we have no
feedback on the 0.13 release candidate.

Should we release? I think so.

Our tasks:
* Make a new download button for site (me)
* Upload the new site pages (you)
* Upload new release to maven (you)
* Update Gradle (me)
* Update Grails plugin (you)
* Update the Griffon plugin (me)
* Update CHANGELOG.txt (Done!)
* Write announcement (you)

Anything else? Can I do any other of the tasks?

-- 
Hamlet D'Arcy
ham...@gm...

Re: [Codenarc-developer] CodeNarc.ipr file

[Hamlet D'A. <ham...@gm...>]

Definitely check it in.

It's great to have the .ipr and .iml as part of the project.



On Fri, Mar 4, 2011 at 1:25 AM, Chris Mair <chr...@ea...> wrote:
> When I upgraded to IntelliJ IDEA 10.0.2, it made some changes to my
> “CodeNarc.ipr” file. It looks like it was just adding default config for
> some new features.
>
>
>
> Currently, that file is checked into SVN. Should it be? Should I check in my
> changed file?
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>
>



-- 
Hamlet D'Arcy
ham...@gm...

[Codenarc-developer] CodeNarc.ipr file

[Chris M. <chr...@ea...>]

When I upgraded to IntelliJ IDEA 10.0.2, it made some changes to my
"CodeNarc.ipr" file. It looks like it was just adding default config for
some new features.

 

Currently, that file is checked into SVN. Should it be? Should I check in my
changed file?

[Codenarc-developer] Griffon CodeNarc plugin update to 0.13 RC1

[Hamlet D'A. <ham...@gm...>]

Hi all,

The Griffon CodeNarc plugin is updated to CodeNarc 0.13 RC1.

Any Griffon users out there? Now would be a great time to test the new rules.

-- 
Hamlet D'Arcy
ham...@gm...

[Codenarc-developer] CodeNarc-0.13-RC1 available in Maven2 Central Repo

[Chris M. <chr...@ea...>]

A CodeNarc-0.13-RC1.jar is available in Maven2 Central Repo. 

 

groupId:               org.codenarc

artifactId:            CodeNarc

version:                0.13-RC1

 

It took a whole day to replicate into the central repo, so note that this
release is from Tuesday March 1st @ 22:00 EST  (I know that bug #3196019 was
fixed since then).

 

Chris

Re: [Codenarc-developer] updated tests for File Mod Dates

[<chr...@wa...>]

I agree Hamlet. Overwriting the "real" file every time the test suite runs 
is not a good idea. I will look into that and probably do something like 
you suggest.

Thanks.
Chris

Hamlet DArcy <ham...@ca...> wrote on 03/02/2011 08:32:14 AM:

> It builds and runs fine for me. 
> 
> You could also write the output to a temp file using 
>   def f = File.createTempFile
>   f.deleteOnExit()
> 
> That would also not set the mod time on the file under version control. 
> 
> The risk of rewriting the versioned file is if something goes wrong 
> you will lose any local changes you have made. 
> 
> 
> 
> ----- Original Message -----
> > The problem is that this is regenerating an existing file. So without
> > the
> > timestamp check, or some similar check, the generation could fail or
> > generate the wrong file and the test would still pass (because of the
> > original file).
> > 
> > I tweaked the timestamp logic in the test. Hopefully that addresses
> > the
> > issue. Let me know if you come up with a better way to verify that
> > aspect of
> > the test.
> > 
> > Chris
> > -----Original Message-----
> > From: Hamlet DArcy [mailto:ham...@ca...]
> > Sent: Tuesday, March 01, 2011 2:42 AM
> > To: cod...@li...
> > Subject: [Codenarc-developer] updated tests for File Mod Dates
> > 
> > Hi Chris,
> > 
> > You checked in two tests that compared modification dates on files to
> > the
> > current time. Those tests failed on Linux because the File timestamp
> > is
> > rounded to the second, which put the file mod date slightly before
> > the test
> > start time. Anyway, I just deleted the assertion. It's safe to assume
> > that
> > the file system works, I think.
> > 
> > --
> > Hamlet D'Arcy
> > ham...@ca...
> > 
> > 
> > 
----------------------------------------------------------------------------
> > --
> > Free Software Download: Index, Search & Analyze Logs and other IT
> > data in
> > Real-Time with Splunk. Collect, index and harness all the fast moving
> > IT
> > data generated by your applications, servers and devices whether
> > physical,
> > virtual or in the cloud. Deliver compliance at lower cost and gain
> > new
> > business insights. http://p.sf.net/sfu/splunk-dev2dev
> > _______________________________________________
> > Codenarc-developer mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> > 
> > 
> > 
> 
------------------------------------------------------------------------------
> > Free Software Download: Index, Search & Analyze Logs and other IT
> > data in
> > Real-Time with Splunk. Collect, index and harness all the fast moving
> > IT data
> > generated by your applications, servers and devices whether physical,
> > virtual
> > or in the cloud. Deliver compliance at lower cost and gain new
> > business
> > insights. http://p.sf.net/sfu/splunk-dev2dev
> > _______________________________________________
> > Codenarc-developer mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> > 
> 
> 
------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data 
in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT 
data 
> generated by your applications, servers and devices whether physical, 
virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer

> ForwardSourceID:NT00104B3E 

Re: [Codenarc-developer] updated tests for File Mod Dates

[Hamlet D. <ham...@ca...>]

It builds and runs fine for me. 

You could also write the output to a temp file using 
  def f = File.createTempFile
  f.deleteOnExit()

That would also not set the mod time on the file under version control. 

The risk of rewriting the versioned file is if something goes wrong you will lose any local changes you have made. 



----- Original Message -----
> The problem is that this is regenerating an existing file. So without
> the
> timestamp check, or some similar check, the generation could fail or
> generate the wrong file and the test would still pass (because of the
> original file).
> 
> I tweaked the timestamp logic in the test. Hopefully that addresses
> the
> issue. Let me know if you come up with a better way to verify that
> aspect of
> the test.
> 
> Chris
> -----Original Message-----
> From: Hamlet DArcy [mailto:ham...@ca...]
> Sent: Tuesday, March 01, 2011 2:42 AM
> To: cod...@li...
> Subject: [Codenarc-developer] updated tests for File Mod Dates
> 
> Hi Chris,
> 
> You checked in two tests that compared modification dates on files to
> the
> current time. Those tests failed on Linux because the File timestamp
> is
> rounded to the second, which put the file mod date slightly before
> the test
> start time. Anyway, I just deleted the assertion. It's safe to assume
> that
> the file system works, I think.
> 
> --
> Hamlet D'Arcy
> ham...@ca...
> 
> 
> ----------------------------------------------------------------------------
> --
> Free Software Download: Index, Search & Analyze Logs and other IT
> data in
> Real-Time with Splunk. Collect, index and harness all the fast moving
> IT
> data generated by your applications, servers and devices whether
> physical,
> virtual or in the cloud. Deliver compliance at lower cost and gain
> new
> business insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 
> 
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT
> data in
> Real-Time with Splunk. Collect, index and harness all the fast moving
> IT data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new
> business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 

Re: [Codenarc-developer] updated tests for File Mod Dates

[Chris M. <chr...@ea...>]

The problem is that this is regenerating an existing file. So without the
timestamp check, or some similar check, the generation could fail or
generate the wrong file and the test would still pass (because of the
original file).

I tweaked the timestamp logic in the test. Hopefully that addresses the
issue. Let me know if you come up with a better way to verify that aspect of
the test. 

Chris
-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Tuesday, March 01, 2011 2:42 AM
To: cod...@li...
Subject: [Codenarc-developer] updated tests for File Mod Dates

Hi Chris, 

You checked in two tests that compared modification dates on files to the
current time. Those tests failed on Linux because the File timestamp is
rounded to the second, which put the file mod date slightly before the test
start time. Anyway, I just deleted the assertion. It's safe to assume that
the file system works, I think. 

--
Hamlet D'Arcy
ham...@ca...


----------------------------------------------------------------------------
--
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT
data generated by your applications, servers and devices whether physical,
virtual or in the cloud. Deliver compliance at lower cost and gain new
business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

Re: [Codenarc-developer] Reducing Build Output

[Hamlet D. <ham...@ca...>]

If you like it then I'll leave it. No worries.



----- Original Message -----
> 
> 
> I changed the test output (back) to INFO level deliberately because I
> am used to and prefer having that test output visible when I run the
> tests. But habit should not get in the way of practicality. :-> You
> can go ahead and set the test output (i.e., the log() method) to
> DEBUG level. I guess if/when I need to examine that output I can
> temporarily change the "log4j.properties" file.
> 
> >> Also, a few of the main() methods use println. Is this on purpose?
> 
> Yes, that was on purpose, but I'm not sure I can make an effective
> case for why output from a main() should be different. Feel free to
> change, otherwise I'll plan to do that.
> 
> Chris
> Hamlet DArcy <ham...@ca...> wrote on 03/01/2011 02:55:08
> AM:
> 
> > Hi Chris,
> > 
> > Our build is very verbose.
> > 
> > Do you mind if I reduce some UnitTest related warnings and info
> > messages to debug? I will leave the Logger.warn() calls in the
> > code,
> > but in unit tests I'll just redirect them to Logger.debug(). What
> > do
> > you think?
> > 
> > Also, a few of the main() methods use println. Is this on purpose?
> > Or should we switch those to use Log4j info messages?
> > 
> > --
> > Hamlet D'Arcy
> > ham...@ca...
> > 
> > 
> > ------------------------------------------------------------------------------
> > Free Software Download: Index, Search & Analyze Logs and other IT
> > data in
> > Real-Time with Splunk. Collect, index and harness all the fast
> > moving IT data
> > generated by your applications, servers and devices whether
> > physical, virtual
> > or in the cloud. Deliver compliance at lower cost and gain new
> > business
> > insights. http://p.sf.net/sfu/splunk-dev2dev
> > _______________________________________________
> > Codenarc-developer mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 
> > ForwardSourceID:NT00104536
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT
> data in
> Real-Time with Splunk. Collect, index and harness all the fast moving
> IT data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new
> business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 

Re: [Codenarc-developer] Reducing Build Output

[<chr...@wa...>]

I changed the test output (back) to INFO level deliberately because I am 
used to and prefer having that test output visible when I run the tests. 
But habit should not get in the way of practicality. :->  You can go ahead 
and set the test output (i.e., the log() method) to DEBUG level. I guess 
if/when I need to examine that output I can temporarily change the 
"log4j.properties" file.

>> Also, a few of the main() methods use println. Is this on purpose?

Yes, that was on purpose, but I'm not sure I can make an effective case 
for why output from a main() should be different. Feel free to change, 
otherwise I'll plan to do that.

Chris
Hamlet DArcy <ham...@ca...> wrote on 03/01/2011 02:55:08 AM:

> Hi Chris, 
> 
> Our build is very verbose. 
> 
> Do you mind if I reduce some UnitTest related warnings and info 
> messages to debug? I will leave the Logger.warn() calls in the code,
> but in unit tests I'll just redirect them to Logger.debug(). What do
> you think? 
> 
> Also, a few of the main() methods use println. Is this on purpose? 
> Or should we switch those to use Log4j info messages? 
> 
> --
> Hamlet D'Arcy
> ham...@ca...
> 
> 
> 
------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data 
in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT 
data 
> generated by your applications, servers and devices whether physical, 
virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer

> ForwardSourceID:NT00104536 

[Codenarc-developer] Reducing Build Output

[Hamlet D. <ham...@ca...>]

Hi Chris, 

Our build is very verbose. 

Do you mind if I reduce some UnitTest related warnings and info messages to debug? I will leave the Logger.warn() calls in the code, but in unit tests I'll just redirect them to Logger.debug(). What do you think? 

Also, a few of the main() methods use println. Is this on purpose? Or should we switch those to use Log4j info messages? 

--
Hamlet D'Arcy
ham...@ca...

[Codenarc-developer] updated tests for File Mod Dates

[Hamlet D. <ham...@ca...>]

Hi Chris, 

You checked in two tests that compared modification dates on files to the current time. Those tests failed on Linux because the File timestamp is rounded to the second, which put the file mod date slightly before the test start time. Anyway, I just deleted the assertion. It's safe to assume that the file system works, I think. 

--
Hamlet D'Arcy
ham...@ca...

Re: [Codenarc-developer] Maven - Snapshot & migrating off of GMaven for Groovy 1.8

[Chris M. <chr...@ea...>]

Perhaps after the 0.13 release we can consider migrating the build part to
Gradle. I would love to get some experience with Gradle, as long as we could
make the build + site generation relatively seamless.

I will try to build and upload a 0.13-SNAPSHOT build to Maven within the
next couple days. I don't know how we would do anything like that
automatically without a more sophisticated continuous integration setup.

Chris

-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Sunday, February 27, 2011 2:18 AM
To: Cod...@li...
Subject: [Codenarc-developer] Maven - Snapshot & migrating off of GMaven for
Groovy 1.8

I tested our codebase with Groovy 1.8. From IDEA everything worked fine.
>From the command line it broke. The problem, as I understand it, is that the
GMaven version we use dictates the version of the Groovy compiler. I can
specify Groovy 1.8 in the pom.xml, but that isn't used to compile, only as a
dependency to run tests, etc. Perhaps we should use Rene's Gradle build for
building, and use Maven only for the site target. Then we can have a 1.7
version and a 1.8 version. *However*, this is not a big deal. You can
happily have a 1.8 Groovy project and run CodeNarc+1.7 against it. It is
just that some language features may not be recognized.

Also, I updated the version number in the pom to 0.13-SNAPSHOT. Is there any
way we could upload this to Maven central or have it automatically
published? I would like to have people use 0.13 SNAPSHOT to report defects
easily and then when we release we are more confident of our quality (and
can deliver bug fixes in SNAPSHOT versions faster). It would be nice to get
everyone on the snapshot and that way every time we check in a new rule,
they could get the rule automatically.

--
Hamlet D'Arcy
ham...@gm...

----------------------------------------------------------------------------
--
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT
data generated by your applications, servers and devices whether physical,
virtual or in the cloud. Deliver compliance at lower cost and gain new
business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

[Codenarc-developer] Maven - Snapshot & migrating off of GMaven for Groovy 1.8

[Hamlet D'A. <ham...@gm...>]

I tested our codebase with Groovy 1.8. From IDEA everything worked
fine. From the command line it broke. The problem, as I understand it,
is that the GMaven version we use dictates the version of the Groovy
compiler. I can specify Groovy 1.8 in the pom.xml, but that isn't used
to compile, only as a dependency to run tests, etc. Perhaps we should
use Rene's Gradle build for building, and use Maven only for the site
target. Then we can have a 1.7 version and a 1.8 version. *However*,
this is not a big deal. You can happily have a 1.8 Groovy project and
run CodeNarc+1.7 against it. It is just that some language features
may not be recognized.

Also, I updated the version number in the pom to 0.13-SNAPSHOT. Is
there any way we could upload this to Maven central or have it
automatically published? I would like to have people use 0.13 SNAPSHOT
to report defects easily and then when we release we are more
confident of our quality (and can deliver bug fixes in SNAPSHOT
versions faster). It would be nice to get everyone on the snapshot and
that way every time we check in a new rule, they could get the rule
automatically.

-- 
Hamlet D'Arcy
ham...@gm...

Re: [Codenarc-developer] ready for release -- turn on all rules?

[Hamlet D'A. <ham...@gm...>]

The unnecessary rules, the junit rules, and the concurrency rules are
important.

I see your point. It's up to you I guess.

Griffon now has a CodeNarc build with a proper config file. GPars as
well. Groovy has one, but there is not proper config file so
violations do not fail the build.

Maybe we should just update the sample reports with the new CSS
format, and mention that Griffon, GPars, and Groovy all use CodeNarc.

--
Hamlet



On Sun, Feb 27, 2011 at 3:41 AM, Chris Mair <chr...@ea...> wrote:
> The reason I didn't turn on all the rules originally was that I did not want
> to have these huge, overwhelming report files. And back then we had a lot
> fewer rules.
>
> For the last release, the Grails report is already huge and has over 1000
> violations. My guess is that turning on all rules will generate 10 times
> that much, but we can try it and see. I am a little afraid that someone not
> familiar with CodeNarc will look at a report like that and just be
> overwhelmed and possibly scared off.
>
> Are there specific rules that you want to turn on, or are you seeing some
> significant benefit of having "all" of the rules in there?
>
> Chris
> -----Original Message-----
> From: Hamlet D'Arcy [mailto:ham...@gm...]
> Sent: Saturday, February 26, 2011 1:30 AM
> To: Cod...@li...
> Subject: [Codenarc-developer] ready for release
>
> Hi Chris,
>
> All the defects for 0.13 are fixed. I say we start the release process by
> running codenarc against the open source projects and see what happens.
> Remember, we want to expand the rulesets on the sample reports. I think we
> should add all rulesets in to the samples.
>
> --
> Hamlet D'Arcy
> ham...@gm...
>
> ----------------------------------------------------------------------------
> --
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data generated by your applications, servers and devices whether physical,
> virtual or in the cloud. Deliver compliance at lower cost and gain new
> business insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>



-- 
Hamlet D'Arcy
ham...@gm...

Re: [Codenarc-developer] ready for release

[Chris M. <chr...@ea...>]

FYI, I have the implementation pretty much ready for allowing configuring
custom rulesets using only the rule name (rather than requiring the rule
class and/or ruleset filename).

A sample ruleset looks like this:

    ruleset {
        description 'A custom Groovy RuleSet (see
CodeNarcTask_CustomRuleSetTest)'
    
        CyclomaticComplexity {
            maxMethodComplexity = 1
        }
    
        ClassName

        MethodName
    
        ConfusingTernary(priority:3)
    
        CatchThrowable {
            priority = 1
            enabled = false
        }
        
        // Old style - to illustrate compatibility only
        rule(org.codenarc.rule.basic.ThrowExceptionFromFinallyBlockRule) {
            priority = 3
        }
        ruleset('rulesets/dry.xml')       
    }

It uses a "codenarc-base-rules.properties" file to contain the rule entries,
e.g.:
	AbcComplexity = org.codenarc.rule.size.AbcComplexityRule

But I wrote a script (main() method, actually) that loads all rulesets and
generates this file, so hopefully maintenance effort is minimal.

I still have to work on the documentation. My plan is to check this in
(unless I hear an objection) and document this as the preferred way to
configure a custom ruleset.

Chris
-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Saturday, February 26, 2011 1:30 AM
To: Cod...@li...
Subject: [Codenarc-developer] ready for release

Hi Chris,

All the defects for 0.13 are fixed. I say we start the release process by
running codenarc against the open source projects and see what happens.
Remember, we want to expand the rulesets on the sample reports. I think we
should add all rulesets in to the samples.

--
Hamlet D'Arcy
ham...@gm...

----------------------------------------------------------------------------
--
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT
data generated by your applications, servers and devices whether physical,
virtual or in the cloud. Deliver compliance at lower cost and gain new
business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

Re: [Codenarc-developer] ready for release -- turn on all rules?

[Chris M. <chr...@ea...>]

The reason I didn't turn on all the rules originally was that I did not want
to have these huge, overwhelming report files. And back then we had a lot
fewer rules. 

For the last release, the Grails report is already huge and has over 1000
violations. My guess is that turning on all rules will generate 10 times
that much, but we can try it and see. I am a little afraid that someone not
familiar with CodeNarc will look at a report like that and just be
overwhelmed and possibly scared off.

Are there specific rules that you want to turn on, or are you seeing some
significant benefit of having "all" of the rules in there?

Chris
-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Saturday, February 26, 2011 1:30 AM
To: Cod...@li...
Subject: [Codenarc-developer] ready for release

Hi Chris,

All the defects for 0.13 are fixed. I say we start the release process by
running codenarc against the open source projects and see what happens.
Remember, we want to expand the rulesets on the sample reports. I think we
should add all rulesets in to the samples.

--
Hamlet D'Arcy
ham...@gm...

----------------------------------------------------------------------------
--
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT
data generated by your applications, servers and devices whether physical,
virtual or in the cloud. Deliver compliance at lower cost and gain new
business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

[Codenarc-developer] ready for release

[Hamlet D'A. <ham...@gm...>]

Hi Chris,

All the defects for 0.13 are fixed. I say we start the release process
by running codenarc against the open source projects and see what
happens. Remember, we want to expand the rulesets on the sample
reports. I think we should add all rulesets in to the samples.

-- 
Hamlet D'Arcy
ham...@gm...

[Codenarc-developer] FW: [ codenarc-Bugs-3155974 ] Unused* rules misses references within inner classes

[Chris M. <chr...@ea...>]

Hamlet,

I think the UnusedVariable rule still has this limitation. That test class even has a testApplyTo_VariableOnlyReferencedWithinInnerClass_Violation_KnownIssue() test method.

Thanks a bunch for fixing these inner class issues!

Chris

-----Original Message-----
From: SourceForge.net [mailto:no...@so...] 
Sent: Thursday, February 24, 2011 10:20 AM
To: no...@so...
Subject: [ codenarc-Bugs-3155974 ] Unused* rules misses references within inner classes

Bugs item #3155974, was opened at 2011-01-11 19:29 Message generated for change (Comment added) made by hamletdrc You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=3155974&group_id=250145

Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Chris Mair (chrismair)
Assigned to: Hamlet D'Arcy (hamletdrc)
Summary: Unused* rules misses references within inner classes

Initial Comment:
This code:

            def buildCallable() {
                String ssn = 'xxx'
                return new Callable<Object>(){
                    public Object call(){
                        return participantDao.getParticipantPlans(ssn)
                    }
                }
            }

produces:

    Violation[rule=UnusedVariableRule[name=UnusedVariable, priority=2], lineNumber=3, sourceLine=String ssn = 'xxx', message=The variable [ssn] is not used]


----------------------------------------------------------------------

>Comment By: Hamlet D'Arcy (hamletdrc)
Date: 2011-02-24 09:20

Message:
fixed in 0.13

----------------------------------------------------------------------

Comment By: Hamlet D'Arcy (hamletdrc)
Date: 2011-02-23 15:35

Message:
i fixed this for private methods and private fields. Have not finished with parameters yet. 

----------------------------------------------------------------------

Comment By: Chris Mair (chrismair)
Date: 2011-01-21 07:42

Message:
Yes, let's leave it open and work towards a solution.

----------------------------------------------------------------------

Comment By: Hamlet D'Arcy (hamletdrc)
Date: 2011-01-21 07:14

Message:
Can we leave this open? 

The unused rules should all work with anonymous inner classes, no problems. 

For inner classes and nested classes, it is a little harder. But, we do have the getSourceUnit() method available to us, and we can actually see all the other classes defined in the SourceUnit. It's a matter of getting the other classes out of the SourceUnit, scanning them once to build up a list of referenced variables/methods/properties, and then walking each class once to see if there are private members not in the list. 

Need to make sure it works in this threaded environment too. 

This seems feasible to me. I say leave it open. 

----------------------------------------------------------------------

Comment By: Chris Mair (chrismair)
Date: 2011-01-20 19:54

Message:
I have expanded the scope of this issue to include UnusedVariable, UnusedPrivateMethod, UnusedPrivateMethodParameter and UnusedPrivateField rules. They all suffer the same limitation, for the same reason.

----------------------------------------------------------------------

Comment By: Chris Mair (chrismair)
Date: 2011-01-12 20:24

Message:
Unfortunately, the AST does not give direct access to ClassNode for the inner class being defined from the point in the AST where it is defined.
For example, in the code example above, the ReturnStatement contains a ConstructorCall, but provides no way to get at that inner ClassNode.
Furthermore, CodeNarc is designed to analyze at the class-level, so it would take some pretty nasty contortions to get to it.

So, for now, I am documenting it as a known limitation that the UnusedVariableRule cannot see references within inner classes.

Keep in mind also, that anonymous inner classes can often be rewritten using closures (which work just fine with the UnusedVariable rule).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=3155974&group_id=250145

[Codenarc-developer] FW: [ codenarc-Bugs-3190483 ] unused private field should have ignore list

[Chris M. <chr...@ea...>]

Thanks for fixing this Hamlet. FYI, I changed ignoreRegex to ignoreFieldNames to be consistent with the FieldName and StatelessClass rules.

-----Original Message-----
From: SourceForge.net [mailto:no...@so...] 
Sent: Wednesday, February 23, 2011 2:51 PM
To: chr...@ea...
Subject: [ codenarc-Bugs-3190483 ] unused private field should have ignore list

Bugs item #3190483, was opened at 2011-02-23 13:44 Message generated for change (Comment added) made by hamletdrc You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=3190483&group_id=250145

Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Hamlet D'Arcy (hamletdrc)
Assigned to: Hamlet D'Arcy (hamletdrc)
Summary: unused private field should have ignore list

Initial Comment:
unused private field should have ignore list

by default, this rule should ignore fields named serialVersionUID. 

----------------------------------------------------------------------

>Comment By: Hamlet D'Arcy (hamletdrc)
Date: 2011-02-23 13:51

Message:
fixed in 0.13

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=3190483&group_id=250145