codenarc-user — CodeNarc Users

[Codenarc-user] [ANN] Announcing CodeNarc 0.16

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

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

CodeNarc <http://codenarc.sourceforge.net/>  is a static analysis tool for
Groovy source code. Version 0.16 includes huge performance improvements from
Hamlet and adds 13 new rules (bringing the total to 277 rules) and a bunch
of bug fixes and enhancements. Try it out on the CodeNarc web console
<http://meetcodenarc.appspot.com/edit/14001> , running on Google App Engine.

New Features

.         Performance Improvements (3394481) - There are big performance
improvements in this release.

.         Upgrade to GMetrics 0.4. (3424121) - This upgrade is optional for
users, but may provide performance improvements.

.         Rule Index page: Rule name is now a link to the rule description
web page. (3434063)

 

New and Updated Rules 

.         @SuppressWarnings Support - The support for @SuppressWarnings was
redesigned so that it is more reliable. @SuppressWarnings no works on *all*
rules at the Class, Field, and Method level. 

.         CouldBeElvis rule (convention) - Catch an if block that could be
written as an elvis expression.

.         LongLiteralWithLowerCaseL rule (convention) - In Java and Groovy,
you can specify long literals with the L or l character, for instance 55L or
24l. It is best practice to always use an uppercase L and never a lowercase
l. This is because 11l rendered in some fonts may look like 111 instead of
11L.

.         ConfusingMultipleReturns rule (groovyism) - Multiple return values
can be used to set several variables at once. To use multiple return values,
the left hand side of the assignment must be enclosed in parenthesis. If
not, then you are not using multiple return values, you're only assigning
the last element.

.         GetterMethodCouldBeProperty rule (groovyism) - If a class defines
a public method that follows the Java getter notation, and returns a
constant, then it is cleaner to provide a Groovy property for the value
rather than a Groovy method.

.         UnnecessaryDefInMethodDeclaration rule (unnecessary) - 3176230 -
Rule now catches when you try to add the def keyword to constructor
declarations. Also expanded to catch more instances of in method
declarations with explicit return types. 

.         UnnecessaryDefInFieldDeclaration rule (unnecessary) - If a field
has a visibility modifier or a type declaration, then the def keyword is
unneeded. For instance, 'static def constraints = {}' is redundant and can
be simplified to 'static constraints = {}.

.         UnnecessaryDefInVariableDeclaration rule (unnecessary) - Expanded
rule to catch more instances of unneeded defs.

.         UnusedMethodParameter rule (unused) - This rule finds instances of
method parameters not being used. It does not analyze private methods (that
is done by the UnusedPrivateMethodParameter rule) or methods marked
@Override.

.         BuilderMethodWithSideEffects rule (design) - 3408045 - A builder
method is defined as one that creates objects. As such, they should never be
of void return type. If a method is named build, create, or make, then it
should always return a value.

.         MisorderedStaticImportRule - 3392892 - The rule now allows you to
specify that static imports come after the other imports, not just before.
This rule has one property comesBefore, which defaults to true. If you like
your static imports to come after the others, then set this property to
false.

.         FactoryMethodName rule (naming) - A factory method is a method
that creates objects, and they are typically named either buildFoo(),
makeFoo(), or createFoo(). This rule enforces that only one naming
convention is used. It defaults to makeFoo(), but that can be changed using
the property 'regex'.

.         UseCollectMany rule (groovyism) - 3411722 - In many case
collectMany() yields the same result as collect{}.flatten. It is easier to
understand and more clearly conveys the intent.

.         CollectAllIsDeprecated rule (groovyism) - 3411724 - collectAll is
deprecated since Groovy 1.8.1. Use collectNested instead

.         UseCollectNested rule (groovyism) - 3411724 - Instead of nested
collect{}-calls use collectNested{}

.         DuplicateMapLiteral (dry) - 3413600 - Check for multiple instances
of the same Map literal; limited to Maps where the keys and values are all
constants or literals.

.         DuplicateListLiteral (dry) - 3413601 - Check for multiple
instances of the same List literal; limited to Lists where the values are
all constants or literals..

 

Bug Fixes and Enhancements 

.         #3393179: Fix for JUnitPublicNonTestMethod reporting violations
for public non-test methods that are annotated @Override

.         #3394313: Fixed UnusedPrivateField to honor the @SuppressWarnings
annotation.

.         #3397468: Fixed CyclomaticComplexity rule to honor the
@SuppressWarnings annotation.  

.         #3392768: The UnnecessaryDefInVariableDeclaration no longer checks
fields. That work is done in the UnnecessaryDefInFieldDeclaration rule. 

.         #3401516: Fixed FinalClassWithProtectedMember to ignore methods
with @Override

.         #3408106: Fixed UnnecessaryDefInMethod to ignore parameters that
have the def keyword

.         #3393184: Fixed ExplicitCallToEqualsMethod to suggest a better
rewrite, which works better with negation

.         #3408108: Fixed UnnecessaryDefInMethodDeclaration to not flag
generic methods with a required def as an error

.         #3410261: Fixed UnusedImport - confuses import of similar class
names

.         #3408440: Fixed UnnecessaryObjectReferences rule to not track
references across methods.

.         #3393144: Fixed unnecessaryObjectReferences rule to not track
references across fields.

.         #3394312: Fixed UnusedPrivateField rule to search for usages based
on super class references.

.         #3423987: BracesFor* rules should not produce violations if there
are no braces.

.         #3429658: False positive for UnusedPrivateMethod rule

.         #3387422: ClosureAsLastMethodParameter - false positive.

 

Breaking Changes***

 

HardcodedWindowsRootDirectory

The HardcodedWindowsRootDirectory rule has been renamed to
HardCodedWindowsRootDirectory. (#3433741)

 

Major Reorganization of the "Basic" RuleSet

There has been a major reorganization of the "Basic" RuleSet (#3432475).
This included moving several rules from the "Basic" ruleset to other
rulesets, as well as adding two new rulesets:

      1. "Groovyism" - Groovy idiomatic usage, and Groovy-specific bad
practices

      2. "Convention" - Coding conventions; not typically errors.

 

  The following rules were moved out of the "Basic" ruleset:

     - AddEmptyString                                     (unnecessary)

     - AssignCollectionSort                               (groovyism)

     - AssignCollectionUnique                          (groovyism)

     - BooleanMethodReturnsNull                   (design)

     - CloneableWithoutClone                          (design)

     - ClosureAsLastMethodParameter            (groovyism)

     - CollectAllIsDeprecated                           (groovyism)

     - CompareToWithoutComparable              (design)

     - ConfusingMultipleReturns                      (groovyism)

     - ConfusingTernary                                    (convention)

     - ConsecutiveLiteralAppends                    (unnecessary)

     - ConsecutiveStringConcatenation            (unnecessary)

     - CouldBeElvis                                          (convention)

     - ExplicitArrayListInstantiation                 (groovyism)

     - ExplicitCallToAndMethod                      (groovyism)

     - ExplicitCallToCompareToMethod          (groovyism)

     - ExplicitCallToDivMethod                       (groovyism)

     - ExplicitCallToEqualsMethod                  (groovyism)

     - ExplicitCallToGetAtMethod                   (groovyism)

     - ExplicitCallToLeftShiftMethod              (groovyism)

     - ExplicitCallToMinusMethod                   (groovyism)

     - ExplicitCallToModMethod                     (groovyism)

     - ExplicitCallToMultiplyMethod               (groovyism)

     - ExplicitCallToOrMethod                         (groovyism)

     - ExplicitCallToPlusMethod                      (groovyism)

     - ExplicitCallToPowerMethod                   (groovyism)

     - ExplicitCallToRightShiftMethod            (groovyism)

     - ExplicitCallToXorMethod                       (groovyism)

     - ExplicitHashMapInstantiation                 (groovyism)

     - ExplicitHashSetInstantiation                   (groovyism)

     - ExplicitLinkedHashMapInstantiation     (groovyism)

     - ExplicitLinkedListInstantiation              (groovyism)

     - ExplicitStackInstantiation                       (groovyism)

     - ExplicitTreeSetInstantiation                    (groovyism)

     - GStringAsMapKey                                  (groovyism)

     - GroovyLangImmutable                           (groovyism)

     - InvertedIfElse                                         (convention)

     - LongLiteralWithLowerCaseL                 (convention)

     - ReturnsNullInsteadOfEmptyArray         (design)

     - ReturnsNullInsteadOfEmptyCollection (design)

     - SimpleDateFormatMissingLocale           (design)

     - UseCollectMany                                      (groovyism)

     - UseCollectNested                                    (groovyism)

 

The ruleset parser classes have been modified to print a helpful error
message for moved and renamed rules (see MovedRules helper class).

 

AbstractAstVisitor Method Name Changes

In a previous version, method names on AbstractAstVisitor were changed to
add @SuppressWarnings support. visitField became visitFieldEx, visitProperty
became visitPropertyEx, and visitConstructor became visitConstructorEx.
These were changed back to the default names used by Groovy visitors.

 

Thanks 

*	Thanks to the Groovy Users of Minnesota for the CouldBeElvis rule.
Thanks Jeff Beck, Doug Sabers, Ryan Applegate, and Mike Minner.
*	Thanks to Joachim Baumann for UseCollectMany,
CollectAllIsDeprecated, UseCollectNested.

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

[Codenarc-user] Reorganizing the Basic RuleSet

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

Here is my plan for reorganizing the CodeNarc "Basic" ruleset.

This will include adding three new rulesets:

1.    "String" - String-related rules

2.    "Groovyism" - Groovy idiomatic usage, and Groovy-specific bad
practices

3.    "Convention" - Coding conventions; not typically errors; might end up
become something of a "miscellaneous" set.

Current Basic RuleSet and (New Destination)

The rules in bold will stay in the Basic ruleset.

.         AddEmptyString                                (string)

.         AssignCollectionSort                          (groovyism)

.         AssignCollectionUnique                       (groovyism)

.         AssignmentInConditional

.         BigDecimalInstantiation

.         BitwiseOperatorInConditional

.         BooleanGetBoolean

.         BooleanMethodReturnsNull

.         BrokenOddnessCheck

.         ClassForName

.         CloneableWithoutClone                       (design)

.         ClosureAsLastMethodParameter           (groovyism)

.         CollectAllIsDeprecated                        (groovyism)

.         CompareToWithoutComparable            (design)

.         ComparisonOfTwoConstants

.         ComparisonWithSelf

.         ConfusingMultipleReturns                    (groovyism)

.         ConfusingTernary                             (convention)

.         ConsecutiveLiteralAppends                  (string)

.         ConsecutiveStringConcatenation           (string)

.         ConstantIfExpression

.         ConstantTernaryExpression

.         CouldBeElvis                                     (convention)

.         DeadCode

.         DoubleNegative

.         DuplicateCaseStatement

.         DuplicateMapKey

.         DuplicateSetValue

.         EmptyCatchBlock

.         EmptyElseBlock

.         EmptyFinallyBlock

.         EmptyForStatement

.         EmptyIfStatement

.         EmptyInstanceInitializer

.         EmptyMethod

.         EmptyStaticInitializer

.         EmptySwitchStatement

.         EmptySynchronizedStatement

.         EmptyTryBlock

.         EmptyWhileStatement

.         EqualsAndHashCode

.         EqualsOverloaded

.         ExplicitArrayListInstantiation                (groovyism)

.         ExplicitCallToAndMethod                     (groovyism)

.         ExplicitCallToCompareToMethod           (groovyism)

.         ExplicitCallToDivMethod                      (groovyism)

.         ExplicitCallToEqualsMethod                  (groovyism)

.         ExplicitCallToGetAtMethod                   (groovyism)

.         ExplicitCallToLeftShiftMethod               (groovyism)

.         ExplicitCallToMinusMethod                   (groovyism)

.         ExplicitCallToModMethod                     (groovyism)

.         ExplicitCallToMultiplyMethod                 (groovyism)

.         ExplicitCallToOrMethod                       (groovyism)

.         ExplicitCallToPlusMethod                     (groovyism)

.         ExplicitCallToPowerMethod                  (groovyism)

.         ExplicitCallToRightShiftMethod              (groovyism)

.         ExplicitCallToXorMethod                      (groovyism)

.         ExplicitGarbageCollection               

.         ExplicitHashMapInstantiation                (groovyism)

.         ExplicitHashSetInstantiation                 (groovyism)

.         ExplicitLinkedHashMapInstantiation       (groovyism)

.         ExplicitLinkedListInstantiation               (groovyism)

.         ExplicitStackInstantiation                     (groovyism)

.         ExplicitTreeSetInstantiation                 (groovyism)

.         ForLoopShouldBeWhileLoop            

.         GStringAsMapKey                             (groovyism)

.         GroovyLangImmutable                       (groovyism)

.         HardCodedWindowsFileSeparator

.         HardcodedWindowsRootDirectory 

.         IntegerGetInteger

.         InvertedIfElse                                   (convention)

.         LongLiteralWithLowerCaseL                 (convention)

.         RandomDoubleCoercedToZero                  

.         RemoveAllOnSelf                                     

.         ReturnFromFinallyBlock

.         ReturnsNullInsteadOfEmptyArray         (design)

.         ReturnsNullInsteadOfEmptyCollection    (design)

.         SimpleDateFormatMissingLocale           (design) (or convention?)

.         ThrowExceptionFromFinallyBlock

.         UseCollectMany                                (groovyism)

.         UseCollectNested                              (groovyism)

 

Re: [Codenarc-user] Inherited equals and toString methods gives violations

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

Mathias,

 

The GrailsDomainHasEquals and GrailsDomainHasToString rules are by no means universally applicable to all Grails projects. As with most other CodeNarc rules, you should tailor the set of rules that you use to your own standards and sensibilities.

 

In general, turning off a rule can be done in a few different ways. If you are currently including the Grails ruleset in your own custom ruleset, then you can disable a rule by setting its enabled property to false, e.g.:

 

ruleset {

        // ..

       ruleset('rulesets/grails.xml') {

            GrailsDomainHasEquals(enabled:false)

            GrailsDomainHasToString(enabled:false)

        }

}

 

Also see http://codenarc.sourceforge.net/codenarc-configuring-rules.html#Turning_Off_A_Rule for other ways.

 

If you don’t already have your own custom ruleset file, I suggest you create one:  http://codenarc.sourceforge.net/codenarc-creating-ruleset.html.

 

And then another option is to turn the enabled property off in the “codenarc.properties” file. Just aware that if you are using the Grails CodeNarc plugin, that there are special considerations for specifying the location of that file. See http://grails.org/plugin/codenarc.

 

Chris

 

From: Mathias Åhsberg [mailto:mat...@gm...] 
Sent: Tuesday, October 18, 2011 5:12 PM
To: cod...@li...
Subject: [Codenarc-user] Inherited equals and toString methods gives violations

 

I have several Grails Domain classes which represent different permissions. e.g. UserPermission, PrintPermission etc.  

All these domain classes extends a common Permission domain class (Permission.groovy) which holds some common properties and methods.

 

The Permission domain class also holds a toString method and an equals method, which are used by the classes that extends the Permission domain class. However, I still get violations due to the codenarc rules:

 

GrailsDomainHasEquals Rule and GrailsDomainHasToString Rule because the subclasses do not explicit includes these methods.

 

Is there a way to fix this so the violations are ignored for those classes that extends another class which has those methods? Or some other solutions which removes these violations?

 

Thanks

[Codenarc-user] Inherited equals and toString methods gives violations

[Mathias Å. <mat...@gm...>]

I have several Grails Domain classes which represent different permissions.
e.g. UserPermission, PrintPermission etc.
All these domain classes extends a common Permission domain class
(Permission.groovy) which holds some common properties and methods.

The Permission domain class also holds a toString method and an equals
method, which are used by the classes that extends the Permission domain
class. However, I still get violations due to the codenarc rules:

GrailsDomainHasEquals Rule and GrailsDomainHasToString Rule because the
subclasses do not explicit includes these methods.

Is there a way to fix this so the violations are ignored for those classes
that extends another class which has those methods? Or some other solutions
which removes these violations?

Thanks

Re: [Codenarc-user] Considering Reorganizing the "Basic" RuleSet --> GroovyIdioms

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

It really doesn't matter to me how the rules are reorganized. 
There are enough new rules with each release that you need to reconfigure things anyway. 

One option is to print warnings when mis-configurations are found. If you know a rule is moved, then add code to the property file reader that looks for incorrect packages and such. 


----- Original Message -----
> 
> 
> 
> 
> To CodeNarc Users,
> 
> 
> 
> I am considering moving a subset of the rules currently in the
> CodeNarc “ Basic ” ruleset into one or more other new rulesets,
> probably including at least a ruleset encoding Groovy-specific
> idioms or best practices.
> 
> 
> 
> I do not make this decision lightly. I know this will impact current
> users (including me), requiring adjustment of custom CodeNarc
> rulesets, if they:
> 
> · Include the “Basic” ruleset and then configured any of the affected
> rules within that ruleset closure.
> 
> · Include rules explicitly by class name
> 
> 
> 
> My motivations include:
> 
> Ø The “Basic” ruleset has strayed from my original intent of being a
> core set of serious and uncontroversial rules. All violations of
> these should be fixed. As it is now, that ruleset includes a bunch
> of rules that are less-important or are not universal practices.
> 
> Ø The “Basic” ruleset has become large and unwieldy.
> 
> Ø There may be value in having a separate ruleset encoding
> Groovy-specific idioms.
> 
> 
> 
> That all being said, I’d like to (continue to) reduce the emphasis on
> the organization and categorization of the predefined ruleset
> anyway. I’d like users to be able to focus more on the rules, not
> really caring which rulesets contain them.
> 
> 
> 
> Some Basic Rules That Could Be Groovy-Specific (“GroovyIdiom” or
> “Groovyism”?)
> 
>     • AssignCollectionSort
>     • AssignCollectionUnique
>     • ClosureAsLastMethodParameter
>     • ExplicitArrayListInstantiation
>     • ExplicitCallToAndMethod
>     • ExplicitCallToCompareToMethod
>     • ExplicitCallToDivMethod
>     • ExplicitCallToEqualsMethod
>     • ExplicitCallToGetAtMethod
>     • ExplicitCallToLeftShiftMethod
>     • ExplicitCallToMinusMethod
>     • ExplicitCallToModMethod
>     • ExplicitCallToMultiplyMethod
>     • ExplicitCallToOrMethod
>     • ExplicitCallToPlusMethod
>     • ExplicitCallToPowerMethod
>     • ExplicitCallToRightShiftMethod
>     • ExplicitCallToXorMethod
>     • ExplicitGarbageCollection
>     • ExplicitHashMapInstantiation
>     • ExplicitHashSetInstantiation
>     • ExplicitLinkedHashMapInstantiation
>     • ExplicitLinkedListInstantiation
>     • ExplicitStackInstantiation
>     • ExplicitTreeSetInstantiation
>     • GStringAsMapKey
>     • GroovyLangImmutable
> 
> 
> 
> Please let me know if you have any opinions one way or another.
> 
> 
> 
> Thanks.
> 
> Chris
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and
> makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
> 

[Codenarc-user] Considering Reorganizing the "Basic" RuleSet --> GroovyIdioms

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

To CodeNarc Users,

 

I am considering moving a subset of the rules currently in the CodeNarc
“Basic” ruleset into one or more other new rulesets, probably including at
least a ruleset encoding Groovy-specific idioms or best practices.

 

I do not make this decision lightly. I know this will impact current users
(including me), requiring adjustment of custom CodeNarc rulesets, if they:

·         Include the “Basic” ruleset and then configured any of the
affected rules within that ruleset closure.

·         Include rules explicitly by class name

 

My motivations include:

Ø  The “Basic” ruleset has strayed from my original intent of being a core
set of serious and uncontroversial rules. All violations of these should be
fixed. As it is now, that ruleset includes a bunch of rules that are
less-important or are not universal practices.

Ø  The “Basic” ruleset has become large and unwieldy.

Ø  There may be value in having a  separate ruleset encoding Groovy-specific
idioms.

 

That all being said, I’d like to (continue to) reduce the emphasis on the
organization and categorization of the predefined ruleset anyway. I’d like
users to  be able to focus more on the rules, not really caring which
rulesets contain them.

 

Some Basic Rules That Could Be Groovy-Specific (“GroovyIdiom” or
“Groovyism”?)

*	AssignCollectionSort
*	AssignCollectionUnique
*	ClosureAsLastMethodParameter
*	ExplicitArrayListInstantiation
*	ExplicitCallToAndMethod
*	ExplicitCallToCompareToMethod
*	ExplicitCallToDivMethod
*	ExplicitCallToEqualsMethod
*	ExplicitCallToGetAtMethod
*	ExplicitCallToLeftShiftMethod
*	ExplicitCallToMinusMethod
*	ExplicitCallToModMethod
*	ExplicitCallToMultiplyMethod
*	ExplicitCallToOrMethod
*	ExplicitCallToPlusMethod
*	ExplicitCallToPowerMethod
*	ExplicitCallToRightShiftMethod
*	ExplicitCallToXorMethod
*	ExplicitGarbageCollection
*	ExplicitHashMapInstantiation
*	ExplicitHashSetInstantiation
*	ExplicitLinkedHashMapInstantiation
*	ExplicitLinkedListInstantiation
*	ExplicitStackInstantiation
*	ExplicitTreeSetInstantiation
*	GStringAsMapKey
*	GroovyLangImmutable

Please let me know if you have any opinions one way or another.

 

Thanks.

Chris

Re: [Codenarc-user] GrailsPublicControllerMethod

[Olivier G. <ogo...@sm...>]

Thank you for taking this into consideration! I added a comment to:
http://jira.grails.org/browse/GPCODENARC-23?focusedCommentId=66029#comment-66029

There should be some kind of DSL that allows to do this in Grails
configiuration (BuildConfig.groovy), which generates the
codenarc.propertiesat each build.


On Wed, Aug 24, 2011 at 8:47 AM, <chr...@we...> wrote:

> Ideally, yes. Unfortunately, the Grails CodeNarc plugin is just a wrapper
> for regular CodeNarc. CodeNarc is not executing within the Grails container,
> and has no notion of what the “current” version of Grails is. I think any
> customization like this would need to be done within the plugin, and
> probably at plugin installation/upgrade time, but I’m not sure of a clean
> and straightforward way to do that. Perhaps create or append to a
> “codenarc.properties” file that turns that rule off if the plugin script is
> executed from Grails 2.x? Hmmm.****
>
> ** **
>
> *From:* Olivier Gourment [mailto:ogo...@sm...]
> *Sent:* Monday, August 22, 2011 10:44 PM
> *To:* Bobby Warner
> *Cc:* cod...@li...
> *Subject:* Re: [Codenarc-user] GrailsPublicControllerMethod****
>
> ** **
>
> Ideally, the codenarc plugin would have some knowledge about which rules
> apply to which version of Grails, *and* which version of Grails the project
> uses?****
>
> On Mon, Aug 22, 2011 at 2:15 PM, Bobby Warner <bob...@gm...>
> wrote:****
>
> The GrailsPublicControllerMethod rule should be removed from CodeNarc
> since Grails 2.0 uses methods instead of closures by default.
>
>
> Thanks,
> Bobby
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user****
>
> ** **
>

Re: [Codenarc-user] GrailsPublicControllerMethod

[<chr...@we...>]

Ideally, yes. Unfortunately, the Grails CodeNarc plugin is just a wrapper for regular CodeNarc. CodeNarc is not executing within the Grails container, and has no notion of what the "current" version of Grails is. I think any customization like this would need to be done within the plugin, and probably at plugin installation/upgrade time, but I'm not sure of a clean and straightforward way to do that. Perhaps create or append to a "codenarc.properties" file that turns that rule off if the plugin script is executed from Grails 2.x? Hmmm.

From: Olivier Gourment [mailto:ogo...@sm...]
Sent: Monday, August 22, 2011 10:44 PM
To: Bobby Warner
Cc: cod...@li...
Subject: Re: [Codenarc-user] GrailsPublicControllerMethod

Ideally, the codenarc plugin would have some knowledge about which rules apply to which version of Grails, *and* which version of Grails the project uses?
On Mon, Aug 22, 2011 at 2:15 PM, Bobby Warner <bob...@gm...<mailto:bob...@gm...>> wrote:
The GrailsPublicControllerMethod rule should be removed from CodeNarc
since Grails 2.0 uses methods instead of closures by default.


Thanks,
Bobby

------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at:  http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Codenarc-user mailing list
Cod...@li...<mailto:Cod...@li...>
https://lists.sourceforge.net/lists/listinfo/codenarc-user

Re: [Codenarc-user] GrailsPublicControllerMethod

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

Great ideas! I will open some Jira tickets for the plugin.

Can you think of any other grails rules? Are there best practices around
named queries and interceptors? Services? I would love some help thinking up
Grails rules.

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

On Aug 23, 2011 4:44 AM, "Olivier Gourment" <ogo...@sm...>
wrote:
> Ideally, the codenarc plugin would have some knowledge about which rules
> apply to which version of Grails, *and* which version of Grails the
project
> uses?
>
> On Mon, Aug 22, 2011 at 2:15 PM, Bobby Warner <bob...@gm...>
wrote:
>
>> The GrailsPublicControllerMethod rule should be removed from CodeNarc
>> since Grails 2.0 uses methods instead of closures by default.
>>
>>
>> Thanks,
>> Bobby
>>
>>
>>
------------------------------------------------------------------------------
>> uberSVN's rich system and user administration capabilities and model
>> configuration take the hassle out of deploying and managing Subversion
and
>> the tools developers use with it. Learn more about uberSVN and get a free
>> download at: http://p.sf.net/sfu/wandisco-dev2dev
>> _______________________________________________
>> Codenarc-user mailing list
>> Cod...@li...
>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>

Re: [Codenarc-user] GrailsPublicControllerMethod

[Olivier G. <ogo...@sm...>]

Ideally, the codenarc plugin would have some knowledge about which rules
apply to which version of Grails, *and* which version of Grails the project
uses?

On Mon, Aug 22, 2011 at 2:15 PM, Bobby Warner <bob...@gm...> wrote:

> The GrailsPublicControllerMethod rule should be removed from CodeNarc
> since Grails 2.0 uses methods instead of closures by default.
>
>
> Thanks,
> Bobby
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>

[Codenarc-user] GrailsPublicControllerMethod

[Bobby W. <bob...@gm...>]

The GrailsPublicControllerMethod rule should be removed from CodeNarc
since Grails 2.0 uses methods instead of closures by default.


Thanks,
Bobby

Re: [Codenarc-user] Grails plugin - enable all rulessets target?

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

> I think if people have not specified the ruleset files they want, we
> can assume they want the default ones. 

I agree. I am not proposing we change that. 

> It is currently only 3 but
> you could change the default in a new version of the plugin and
> include all the ones you mention. 

No, this is a bad idea for the reasons you provide. 

> The problem with your approach is that if you want to promote a new
> category (ruleset file), nobody will know about it unless they
> happen to read about it and explicitly add it.

Let me explain my idea better. 

If you run "grails install-plugin-codenarc" and "grails codenarc" then it should work 100% like the old version. There are no changes to BuildConfig.groovy. I propose we add a new switch or a new target. You get a new target called "grails codenarc-add-all-rules", and this target updates your BuildConfig.groovy. You could run it today and it would add all the rulessets into your config. Or you could run it after a CodeNarc upgrade and get any new rulesets added to your config. 

> PS: also, codenarc should be able to recognize when ruleSetFiles is a
> collection: users should not have to add ".join(',').toString()"..

Is that possible in a .properties file? I think the field needs to be a String. I'm not sure lists are possible in a Java resource bundle. 

--
Hamlet


----- Original Message -----
> 
> I think if people have not specified the ruleset files they want, we
> can assume they want the default ones. It is currently only 3 but
> you could change the default in a new version of the plugin and
> include all the ones you mention. If suddenly they get too many
> violations, then they will have to ead the doc and explicitly state
> the ones they are interested in.
> 
> The problem with your approach is that if you want to promote a new
> category (ruleset file), nobody will know about it unless they
> happen to read about it and explicitly add it.
> 
> My 2c.
> 
> PS: also, codenarc should be able to recognize when ruleSetFiles is a
> collection: users should not have to add ".join(',').toString()"..
> 
> 
> 
> On Thu, Aug 18, 2011 at 4:07 AM, Hamlet DArcy <
> ham...@ca... > wrote:
> 
> 
> I am using the Grails plugin.
> 
> By default, only three rulessets are used. I think we should
> encourage people to use more of the rulesets.
> 
> What do you think of adding a switch to the codenarc target, like
> this:
> 
> grails codenarc -enableAllRulesets
> 
> And when you run this, BuildConfig.groovy has this text appended to
> it:
> 
> codenarc.ruleSetFiles=[
> 'rulesets/basic.xml',
> 'rulesets/braces.xml',
> 'rulesets/concurrency.xml',
> 'rulesets/design.xml',
> 'rulesets/exceptions.xml',
> 'rulesets/formatting.xml',
> 'rulesets/grails.xml',
> 'rulesets/imports.xml',
> 'rulesets/jdbc.xml',
> 'rulesets/junit.xml',
> 'rulesets/logging.xml',
> 'rulesets/naming.xml',
> 'rulesets/security.xml',
> 'rulesets/serialization.xml',
> 'rulesets/size.xml',
> 'rulesets/unnecessary.xml',
> 'rulesets/unused.xml'].join(',').toString()
> 
> What do you think? Is this a good idea?
> --
> Hamlet D'Arcy
> ham...@ca...
> 
> 
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
> 
> 

Re: [Codenarc-user] Grails plugin - enable all rulessets target?

[Olivier G. <ogo...@sm...>]

I think if people have not specified the ruleset files they want, we can
assume they want the default ones. It is currently only 3 but you could
change the default in a new version of the plugin and include all the ones
you mention. If suddenly they get too many violations, then they will have
to ead the doc and explicitly state the ones they are interested in.

The problem with your approach is that if you want to promote a new category
(ruleset file), nobody will know about it unless they happen to read about
it and explicitly add it.

My 2c.

PS: also, codenarc should be able to recognize when ruleSetFiles is a
collection: users should not have to add ".join(',').toString()"..


On Thu, Aug 18, 2011 at 4:07 AM, Hamlet DArcy <ham...@ca...>wrote:

> I am using the Grails plugin.
>
> By default, only three rulessets are used. I think we should encourage
> people to use more of the rulesets.
>
> What do you think of adding a switch to the codenarc target, like this:
>
>  grails codenarc -enableAllRulesets
>
> And when you run this, BuildConfig.groovy has this text appended to it:
>
> codenarc.ruleSetFiles=[
>        'rulesets/basic.xml',
>        'rulesets/braces.xml',
>        'rulesets/concurrency.xml',
>        'rulesets/design.xml',
>        'rulesets/exceptions.xml',
>        'rulesets/formatting.xml',
>        'rulesets/grails.xml',
>        'rulesets/imports.xml',
>        'rulesets/jdbc.xml',
>        'rulesets/junit.xml',
>        'rulesets/logging.xml',
>        'rulesets/naming.xml',
>        'rulesets/security.xml',
>        'rulesets/serialization.xml',
>        'rulesets/size.xml',
>        'rulesets/unnecessary.xml',
>        'rulesets/unused.xml'].join(',').toString()
>
> What do you think? Is this a good idea?
> --
> Hamlet D'Arcy
> ham...@ca...
>
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>

[Codenarc-user] Grails plugin - enable all rulessets target?

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

I am using the Grails plugin. 

By default, only three rulessets are used. I think we should encourage people to use more of the rulesets. 

What do you think of adding a switch to the codenarc target, like this: 

  grails codenarc -enableAllRulesets

And when you run this, BuildConfig.groovy has this text appended to it: 

codenarc.ruleSetFiles=[
        'rulesets/basic.xml',
        'rulesets/braces.xml',
        'rulesets/concurrency.xml',
        'rulesets/design.xml',
        'rulesets/exceptions.xml',
        'rulesets/formatting.xml',
        'rulesets/grails.xml',
        'rulesets/imports.xml',
        'rulesets/jdbc.xml',
        'rulesets/junit.xml',
        'rulesets/logging.xml',
        'rulesets/naming.xml',
        'rulesets/security.xml',
        'rulesets/serialization.xml',
        'rulesets/size.xml',
        'rulesets/unnecessary.xml',
        'rulesets/unused.xml'].join(',').toString()

What do you think? Is this a good idea? 
--
Hamlet D'Arcy
ham...@ca...

Re: [Codenarc-user] Picking up codenarc.properties from Ant task

[<chr...@we...>]

Is the project root definitely in the classpath? I would probably assume not, by default.

(from the online docs)
You can optionally override the location of the properties file by setting the "codenarc.properties.file" system property to the path or URL of the properties file. That can include a "file:" URL to load from a relative or absolute path on the filesystem (e.g., "file:relative/path/override-codenarc.properties"). If the properties file is not found, then do nothing.

So, either add the project root to the classpath, or try setting the "codenarc.properties.file" system property to something like "file:codenarc.properties" (assuming that the project root is the current working dir).

Chris
-----Original Message-----
From: Steven Sproat [mailto:sp...@gm...] 
Sent: Monday, August 15, 2011 11:04 AM
To: cod...@li...
Subject: [Codenarc-user] Picking up codenarc.properties from Ant task

Hi all,

Many thanks for this great tool, we're using it in our Jenkins CI
environment with the violations plugin for nice reporting on possible
defects. However, I'm having an issue with not being able to disable
some rules that we don't particularly care about, and is causing
errors to be reported that we just want to ignore.

Given a codenarc.properties file, located in the project root (a
grails application)  with the following contents:

ExplicitArrayListInstantiation.enabled=false


and this build.xml --


<project name="myProject">	
	<taskdef name="codenarc" classname="org.codenarc.ant.CodeNarcTask" />
	
	<target name="codenarc">
	    <codenarc ruleSetFiles="rulesets/basic.xml, rulesets/braces.xml,
rulesets/imports.xml, rulesets/unused.xml" maxPriority1Violations="0">
	        <fileset dir="src" includes="**/*.groovy" />
	    	<fileset dir="grails-app" includes="**/*.groovy" />
	    	<fileset dir="test" includes="**/*.groovy" />
		    	
			<report type="xml">
				<option name="outputFile" value="test/reports/CodeNarcAntReport.xml" />
			</report>
			<report type="html">
				<option name="outputFile" value="test/reports/CodeNarcAntReport.html" />
				<option name="title" value="project Groovy Code Analysis" />
			</report>
	 	</codenarc>
	</target>	
</project>


...I am still getting errors about this explicitly instantiating
arraylists. I'm unsure how to get the codenarc.properties file to be
"picked up" by CodeNarc.

I would use the Grails CodeNarc plugin, but unfortunately it's for
Grails 1.3+ and this project is Grails 1.1 based.

Any pointers or advice would be greatly appreciated.
Regards,

Steven Sproat

-- 
--
Steven Sproat, BSc
http://www.whyteboard.org/

------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user

[Codenarc-user] Picking up codenarc.properties from Ant task

[Steven S. <sp...@gm...>]

Hi all,

Many thanks for this great tool, we're using it in our Jenkins CI
environment with the violations plugin for nice reporting on possible
defects. However, I'm having an issue with not being able to disable
some rules that we don't particularly care about, and is causing
errors to be reported that we just want to ignore.

Given a codenarc.properties file, located in the project root (a
grails application)  with the following contents:

ExplicitArrayListInstantiation.enabled=false


and this build.xml --


<project name="myProject">	
	<taskdef name="codenarc" classname="org.codenarc.ant.CodeNarcTask" />
	
	<target name="codenarc">
	    <codenarc ruleSetFiles="rulesets/basic.xml, rulesets/braces.xml,
rulesets/imports.xml, rulesets/unused.xml" maxPriority1Violations="0">
	        <fileset dir="src" includes="**/*.groovy" />
	    	<fileset dir="grails-app" includes="**/*.groovy" />
	    	<fileset dir="test" includes="**/*.groovy" />
		    	
			<report type="xml">
				<option name="outputFile" value="test/reports/CodeNarcAntReport.xml" />
			</report>
			<report type="html">
				<option name="outputFile" value="test/reports/CodeNarcAntReport.html" />
				<option name="title" value="project Groovy Code Analysis" />
			</report>
	 	</codenarc>
	</target>	
</project>


...I am still getting errors about this explicitly instantiating
arraylists. I'm unsure how to get the codenarc.properties file to be
"picked up" by CodeNarc.

I would use the Grails CodeNarc plugin, but unfortunately it's for
Grails 1.3+ and this project is Grails 1.1 based.

Any pointers or advice would be greatly appreciated.
Regards,

Steven Sproat

-- 
--
Steven Sproat, BSc
http://www.whyteboard.org/

Re: [Codenarc-user] CodeNarc Gradle plugin

[Evgeny G. <ev...@gm...>]

Hi,

I see it as alternative to existing Code Quality plugin. There were two
reasons why I didn't use it and went on writing my own thing:

   - Code Quality not being flexible enough. It exposes very few
   configurations that can be applied to CodeNarc Ant task.
   My plugin exposes everything that can be configured:

   - CodeNarc version to use which can't be set with Code Quality.
      - Directories to scan for files + extension of files to scan. This
      allows to scan Gradle builds as well, for example.
      - List of ruleset files, unlike a single file that can be set with
      Code Quality.
      - Priority violations limit  (all 3 levels) which can't be set with
      Code Quality.

      - Code Quality comes with Checkstyle verifications which I wasn't
   interested in using.


I'm now working on wiki page which will demonstrate all possible
configurations and provide a number of working examples as well.
Hope it'll explain better the points above.



On Tue, Aug 9, 2011 at 03:40, Chris Mair <chr...@ea...> wrote:

> Evgeny,****
>
> ** **
>
> Would this replace or complement the CodeNarc support with the Gradle *Code
> Quality Plugin*: http://www.gradle.org/code_quality_plugin.html?****
>
> ** **
>
> Chris****
>
> ** **
>
> *From:* Evgeny Goldin [mailto:ev...@gm...]
> *Sent:* Monday, August 08, 2011 5:51 AM
> *To:* cod...@li...
> *Subject:* [Codenarc-user] CodeNarc Gradle plugin****
>
> ** **
>
> Hi,****
>
> ** **
>
> ** **
>
> I'm about to announce CodeNarc Gradle plugin<https://raw.github.com/evgeny-goldin/gradle-plugins/master/src/main/groovy/CodeNarc.gradle>.
> Here are some usage examples: 1 <http://goo.gl/vwaZJ>, 2<http://goo.gl/i67x0>
> , 3 <http://goo.gl/Wzymd>.****
>
> It allows to specify CodeNarc version, ruleset files, violations limit,
> files to scan, etc.****
>
>  ****
>
> Any volunteers to try it out before the announcement is made? Would love to
> hear your opinions.****
>
> ** **
>
> ** **
>
> Warm regards,****
>
> Evgeny****
>
> evgeny-goldin.com****
>
> ** **
>

Re: [Codenarc-user] CodeNarc Gradle plugin

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

Evgeny,

 

Would this replace or complement the CodeNarc support with the Gradle Code Quality Plugin: http://www.gradle.org/code_quality_plugin.html?

 

Chris

 

From: Evgeny Goldin [mailto:ev...@gm...] 
Sent: Monday, August 08, 2011 5:51 AM
To: cod...@li...
Subject: [Codenarc-user] CodeNarc Gradle plugin

 

Hi,

 

 

I'm about to announce CodeNarc Gradle plugin <https://raw.github.com/evgeny-goldin/gradle-plugins/master/src/main/groovy/CodeNarc.gradle> . Here are some usage examples: 1 <http://goo.gl/vwaZJ> , 2 <http://goo.gl/i67x0> , 3 <http://goo.gl/Wzymd> .

It allows to specify CodeNarc version, ruleset files, violations limit, files to scan, etc.

 

Any volunteers to try it out before the announcement is made? Would love to hear your opinions.

 

 

Warm regards,

Evgeny

evgeny-goldin.com <http://evgeny-goldin.com/> 

 

Re: [Codenarc-user] What do you think of merging rulesets?

[Evgeny G. <ev...@gm...>]

Yes, my "codenarc.txt" is now down to <http://goo.gl/iSyD2>:

ruleset {

    description 'Gradle plugins CodeNarc RuleSet'

    ruleset( "
http://codenarc.sourceforge.net/StarterRuleSet-AllRulesByCategory.groovy.txt"
) {

        DuplicateNumberLiteral   ( enabled : false )
        DuplicateStringLiteral   ( enabled : false )
        BracesForClass           ( enabled : false )
        BracesForMethod          ( enabled : false )
        BracesForIfElse          ( enabled : false )
        BracesForForLoop         ( enabled : false )
        BracesForTryCatchFinally ( enabled : false )
        JavaIoPackageAccess      ( enabled : false )
        ThrowRuntimeException    ( enabled : false )

        AbcComplexity         ( maxMethodComplexity : 70  )
        LineLength            ( length              : 180 )
    }
}

Beautiful. Thanks again, Chris!


On Mon, Aug 8, 2011 at 03:15, Chris Mair <chr...@ea...> wrote:

> Hi Evgeny,****
>
> ** **
>
> I think you can already do most, if not all, of what you are requesting.**
> **
>
> ** **
>
> I just tested using this ruleset:****
>
> ** **
>
> *ruleset {*
>
> * *
>
> *    description 'A Sample Groovy RuleSet'*
>
> * *
>
> *    ruleset("
> http://codenarc.sourceforge.net/StarterRuleSet-AllRulesByCategory.groovy.txt")
> {*
>
> * *
>
> *                BracesForClass(enabled:false)  // Map syntax for setting
> properties*
>
> * *
>
> *                BracesForForLoop {                         // Closure
> syntax for setting properties*
>
> *                                enabled = false*
>
> *                }*
>
> *    }*
>
> *}*
>
> ** **
>
> And it applies ALL of the rules minus the two that I disabled. ****
>
> ** **
>
> That being said, I would not recommend referencing the “StarterRuleSet”
> from the CodeNarc site because, as you mentioned, its contents change
> immediately with each new release (and possibly even at other times) and
> would break your builds. So, perhaps you would substitute something like
> “MyDefaultCodeNarcRuleSet.groovy”.****
>
> ** **
>
> I’m not sure I understand what you mean when you refer to the “first set”
> and “second set” of rules. But the above example illustrates the recommended
> approach for having a global/default ruleset and allowing projects/teams to
> customize it for a specific codebase. And any property values set in this
> ruleset override properties from the “default” ruleset that it includes (the
> “StarterRuleSet..” in this case).****
>
> ** **
>
> I don’t have a great answer yet for how to migrate to the new version of
> CodeNarc, when more rules become available. In my case, I select the new
> rules that I want to include and ignore or disable the ones I don’t. I
> wonder how useful it would be to include a list of new rule names for each
> new release, suitable for copy-paste into an existing ruleset?****
>
> ** **
>
> Chris****
>
> *From:* Evgeny Goldin [mailto:ev...@gm...]
> *Sent:* Sunday, August 07, 2011 5:42 PM
> *To:* cod...@li...
> *Subject:* [Codenarc-user] What do you think of merging rulesets?****
>
> ** **
>
> Hi,
> ****
>
> Today, I keep a copy of StarterRuleSet-AllRulesByCategory.groovy.txt<http://codenarc.sourceforge.net/StarterRuleSet-AllRulesByCategory.groovy.txt> in
> each project with some modifications where rules are disabled or tuned to
> match project preferences.****
>
> It's not very convenient since I need to update this large file for every
> new CodeNarc version, merging new rules added by CodeNarc and existing rules
> configured locally.****
>
> ** **
>
> Would it better if one could reference to:****
>
>    1. Default (probably remote) set of all rules like the one available on
>    the Web today.
>    If one decided to reference the default ruleset on CodeNarc site then
>    he should be aware of a need to upgrade CodeNarc version immediately when a
>    newer version is released as the default ruleset contains new rules,
>    not recognized by older CodeNarc (or we can ask CodeNarc not to fail on
>    unknown rules - this will make it more friendly and "forward compatible").
>    ****
>    2. Local set of rules, overriding the default set for any collision by
>    commenting out rules, disabling them (see below) or changing their
>    configuration.****
>
> ** **
>
> I understand that when rule is commented out in the second set, then it
> simply doesn't exist and if it's defined in the first set then it's enabled.
> ****
>
> But .. it would be nice if CodeNarc could see the rule is actually
> "disabled" in the second set. May be some new syntax for disabling rules can
> be added if commenting them out makes it harder.****
>
> Like a general "enabled" property for all rules and then one could write *"BracesForClass
> { enabled = false }"* in the second local set.****
>
> ** **
>
> I also see with 0.15 if first ruleset contains *"LineLength { length =
> 120 }"* and second  *"LineLength { length = 160 }"* then first value (120)
> is still used by CodeNarc.****
>
> ** **
>
> So .. what do you think of merging rulesets?****
>
> ** **
>
> ** **
>
> Warm regards,****
>
> Evgeny****
>
> evgeny-goldin.com****
>
> ** **
>

Re: [Codenarc-user] CodeNarc maven plugin

[Olivier G. <ogo...@sm...>]

Ok, sorry about the spam... But it appears the faulty dependency is
org.codehaus.mojo... So, will definitely have to use your trick, Hamlet.


On Mon, Aug 8, 2011 at 10:21 AM, Olivier Gourment <
ogo...@sm...> wrote:

> Hi again,
>
> I found why my Spock tests stopped running. Apparently there's an
> incompatibility between Spock and CodeNarc? Just adding the following
> dependencies results in Spock not executing any test in my Specifications...
>
>         <dependency>
>             <groupId>org.codenarc</groupId>
>             <artifactId>CodeNarc</artifactId>
>             <version>0.15</version>
>         </dependency>
>         <dependency>
>             <groupId>org.codehaus.mojo</groupId>
>             <artifactId>codenarc-maven-plugin</artifactId>
>             <version>0.8-alpha-SNAPSHOT</version>
>         </dependency>
>         <dependency>
>             <groupId>org.codenarc</groupId>
>             <artifactId>CodeNarc</artifactId>
>             <version>0.15</version>
>         </dependency>
>
> Is this a known problem? Should I use other versions?
>
> Thanks,
>
>     Olivier
>
>
>
>
>
> On Fri, Aug 5, 2011 at 11:07 PM, Olivier Gourment <
> ogo...@sm...> wrote:
>
>> k. Will try that as soon as I understand why my Spock tests suddenly
>> stopped executing...!
>>
>>
>>
>> On Fri, Aug 5, 2011 at 9:45 AM, Hamlet DArcy <ham...@ca...>wrote:
>>
>>> In the meantime you can always run CodeNarc as part of your UnitTests:
>>>
>>> http://codenarc.sourceforge.net/codenarc-run-as-a-test.html
>>>
>>> I actually find this way of running it nicer :)
>>>
>>>
>>>
>>> ----- Original Message -----
>>> >
>>> > Thank you very much for the answer. I tried various repositories and
>>> > dependencies, following your lead, to no avail.
>>> >
>>> > I can't subscribe (or post) to the mojo user mailing list. I sent an
>>> > email to use...@mo... but did not get an
>>> > answer.......
>>> >
>>> > Thanks,
>>> >
>>> > Olivier
>>> >
>>> >
>>> >
>>> >
>>> > On Fri, Aug 5, 2011 at 2:17 AM, Hamlet DArcy < ham...@ca...
>>> > > wrote:
>>> >
>>> >
>>> > Hi,
>>> >
>>> > I'm sorry to hear you had problems running the Maven plugin.
>>> >
>>> > While we're waiting for someone else to provide a good answer to the
>>> > question, you might try asking the same question on the
>>> > mojo.codehaus.org mailing list:
>>> >
>>> > http://mojo.codehaus.org/codenarc-maven-plugin/mail-lists.html
>>> >
>>> > We don't actually maintain the Maven plugin ourselves, so you might
>>> > find that list is more knowledgeable about it.
>>> >
>>> > Now, I will try to answer the question.
>>> >
>>> > I tried to look at Maven Central and the CodeHaus Maven repository
>>> > and didn't see the org.codehaus.mojo:codenarc-maven-plugin
>>> > dependency. I believe this dependency should sit in Maven just like
>>> > any other dependency. I want to check this because perhaps the
>>> > version number is wrong.
>>> >
>>> > I did find the dependency in the Mojo Repo though:
>>> >
>>> https://nexus.codehaus.org/content/groups/snapshots-group/org/codehaus/mojo/codenarc-maven-plugin/
>>> >
>>> >
>>> > Did you add this repository to your pom.xml, or are you using just
>>> > Maven Central to resolve dependencies? I think you might need to add
>>> > the https://nexus.codehaus.org repository. I don't know the exact
>>> > XML to do this though.
>>> >
>>> > Thanks,
>>> > Hamlet
>>> >
>>> >
>>> >
>>> >
>>> > ----- Original Message -----
>>> > >
>>> > > Hi there,
>>> > >
>>> > > I've tried to include codenarc reports in my maven project, without
>>> > > luck. The documentation at
>>> > > http://mojo.codehaus.org/codenarc-maven-plugin/index.html does not
>>> > > seem to help.
>>> > > I get:
>>> > >
>>> > > Reason: POM 'org.codehaus.mojo:codenarc-maven-plugin' not found in
>>> > > repository: Unable to download the artifact from any repository
>>> > >
>>> > > org.codehaus.mojo:codenarc-maven-plugin:pom:0.8-alpha-1-SNAPSHOT
>>> > >
>>> > > Help?
>>> > >
>>> > > Thanks,
>>> > >
>>> > > Olivier
>>> > >
>>> > >
>>> ------------------------------------------------------------------------------
>>> > > BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
>>> > > The must-attend event for mobile developers. Connect with experts.
>>> > > Get tools for creating Super Apps. See the latest technologies.
>>> > > Sessions, hands-on labs, demos & much more. Register early & save!
>>> > > http://p.sf.net/sfu/rim-blackberry-1
>>> > > _______________________________________________
>>> > > Codenarc-user mailing list
>>> > > Cod...@li...
>>> > > https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>> > >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
>>> > The must-attend event for mobile developers. Connect with experts.
>>> > Get tools for creating Super Apps. See the latest technologies.
>>> > Sessions, hands-on labs, demos & much more. Register early & save!
>>> > http://p.sf.net/sfu/rim-blackberry-1
>>> > _______________________________________________
>>> > Codenarc-user mailing list
>>> > Cod...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>> >
>>>
>>
>>
>

Re: [Codenarc-user] CodeNarc maven plugin

[Olivier G. <ogo...@sm...>]

Hi again,

I found why my Spock tests stopped running. Apparently there's an
incompatibility between Spock and CodeNarc? Just adding the following
dependencies results in Spock not executing any test in my Specifications...

        <dependency>
            <groupId>org.codenarc</groupId>
            <artifactId>CodeNarc</artifactId>
            <version>0.15</version>
        </dependency>
        <dependency>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>codenarc-maven-plugin</artifactId>
            <version>0.8-alpha-SNAPSHOT</version>
        </dependency>
        <dependency>
            <groupId>org.codenarc</groupId>
            <artifactId>CodeNarc</artifactId>
            <version>0.15</version>
        </dependency>

Is this a known problem? Should I use other versions?

Thanks,

    Olivier




On Fri, Aug 5, 2011 at 11:07 PM, Olivier Gourment <
ogo...@sm...> wrote:

> k. Will try that as soon as I understand why my Spock tests suddenly
> stopped executing...!
>
>
>
> On Fri, Aug 5, 2011 at 9:45 AM, Hamlet DArcy <ham...@ca...>wrote:
>
>> In the meantime you can always run CodeNarc as part of your UnitTests:
>>
>> http://codenarc.sourceforge.net/codenarc-run-as-a-test.html
>>
>> I actually find this way of running it nicer :)
>>
>>
>>
>> ----- Original Message -----
>> >
>> > Thank you very much for the answer. I tried various repositories and
>> > dependencies, following your lead, to no avail.
>> >
>> > I can't subscribe (or post) to the mojo user mailing list. I sent an
>> > email to use...@mo... but did not get an
>> > answer.......
>> >
>> > Thanks,
>> >
>> > Olivier
>> >
>> >
>> >
>> >
>> > On Fri, Aug 5, 2011 at 2:17 AM, Hamlet DArcy < ham...@ca...
>> > > wrote:
>> >
>> >
>> > Hi,
>> >
>> > I'm sorry to hear you had problems running the Maven plugin.
>> >
>> > While we're waiting for someone else to provide a good answer to the
>> > question, you might try asking the same question on the
>> > mojo.codehaus.org mailing list:
>> >
>> > http://mojo.codehaus.org/codenarc-maven-plugin/mail-lists.html
>> >
>> > We don't actually maintain the Maven plugin ourselves, so you might
>> > find that list is more knowledgeable about it.
>> >
>> > Now, I will try to answer the question.
>> >
>> > I tried to look at Maven Central and the CodeHaus Maven repository
>> > and didn't see the org.codehaus.mojo:codenarc-maven-plugin
>> > dependency. I believe this dependency should sit in Maven just like
>> > any other dependency. I want to check this because perhaps the
>> > version number is wrong.
>> >
>> > I did find the dependency in the Mojo Repo though:
>> >
>> https://nexus.codehaus.org/content/groups/snapshots-group/org/codehaus/mojo/codenarc-maven-plugin/
>> >
>> >
>> > Did you add this repository to your pom.xml, or are you using just
>> > Maven Central to resolve dependencies? I think you might need to add
>> > the https://nexus.codehaus.org repository. I don't know the exact
>> > XML to do this though.
>> >
>> > Thanks,
>> > Hamlet
>> >
>> >
>> >
>> >
>> > ----- Original Message -----
>> > >
>> > > Hi there,
>> > >
>> > > I've tried to include codenarc reports in my maven project, without
>> > > luck. The documentation at
>> > > http://mojo.codehaus.org/codenarc-maven-plugin/index.html does not
>> > > seem to help.
>> > > I get:
>> > >
>> > > Reason: POM 'org.codehaus.mojo:codenarc-maven-plugin' not found in
>> > > repository: Unable to download the artifact from any repository
>> > >
>> > > org.codehaus.mojo:codenarc-maven-plugin:pom:0.8-alpha-1-SNAPSHOT
>> > >
>> > > Help?
>> > >
>> > > Thanks,
>> > >
>> > > Olivier
>> > >
>> > >
>> ------------------------------------------------------------------------------
>> > > BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
>> > > The must-attend event for mobile developers. Connect with experts.
>> > > Get tools for creating Super Apps. See the latest technologies.
>> > > Sessions, hands-on labs, demos & much more. Register early & save!
>> > > http://p.sf.net/sfu/rim-blackberry-1
>> > > _______________________________________________
>> > > Codenarc-user mailing list
>> > > Cod...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/codenarc-user
>> > >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
>> > The must-attend event for mobile developers. Connect with experts.
>> > Get tools for creating Super Apps. See the latest technologies.
>> > Sessions, hands-on labs, demos & much more. Register early & save!
>> > http://p.sf.net/sfu/rim-blackberry-1
>> > _______________________________________________
>> > Codenarc-user mailing list
>> > Cod...@li...
>> > https://lists.sourceforge.net/lists/listinfo/codenarc-user
>> >
>>
>
>

[Codenarc-user] CodeNarc Gradle plugin

[Evgeny G. <ev...@gm...>]

Hi,


I'm about to announce CodeNarc Gradle
plugin<https://raw.github.com/evgeny-goldin/gradle-plugins/master/src/main/groovy/CodeNarc.gradle>.
Here are some usage examples: 1 <http://goo.gl/vwaZJ>, 2<http://goo.gl/i67x0>
, 3 <http://goo.gl/Wzymd>.
It allows to specify CodeNarc version, ruleset files, violations limit,
files to scan, etc.

Any volunteers to try it out before the announcement is made? Would love to
hear your opinions.


Warm regards,
Evgeny
evgeny-goldin.com

Re: [Codenarc-user] What do you think of merging rulesets?

[Evgeny G. <ev...@gm...>]

Thanks, Chris!

That's exactly what I was looking for.
Will try it out to separate local rules from the default ones.


On Mon, Aug 8, 2011 at 03:15, Chris Mair <chr...@ea...> wrote:

> Hi Evgeny,****
>
> ** **
>
> I think you can already do most, if not all, of what you are requesting.**
> **
>
> ** **
>
> I just tested using this ruleset:****
>
> ** **
>
> *ruleset {*
>
> * *
>
> *    description 'A Sample Groovy RuleSet'*
>
> * *
>
> *    ruleset("
> http://codenarc.sourceforge.net/StarterRuleSet-AllRulesByCategory.groovy.txt")
> {*
>
> * *
>
> *                BracesForClass(enabled:false)  // Map syntax for setting
> properties*
>
> * *
>
> *                BracesForForLoop {                         // Closure
> syntax for setting properties*
>
> *                                enabled = false*
>
> *                }*
>
> *    }*
>
> *}*
>
> ** **
>
> And it applies ALL of the rules minus the two that I disabled. ****
>
> ** **
>
> That being said, I would not recommend referencing the “StarterRuleSet”
> from the CodeNarc site because, as you mentioned, its contents change
> immediately with each new release (and possibly even at other times) and
> would break your builds. So, perhaps you would substitute something like
> “MyDefaultCodeNarcRuleSet.groovy”.****
>
> ** **
>
> I’m not sure I understand what you mean when you refer to the “first set”
> and “second set” of rules. But the above example illustrates the recommended
> approach for having a global/default ruleset and allowing projects/teams to
> customize it for a specific codebase. And any property values set in this
> ruleset override properties from the “default” ruleset that it includes (the
> “StarterRuleSet..” in this case).****
>
> ** **
>
> I don’t have a great answer yet for how to migrate to the new version of
> CodeNarc, when more rules become available. In my case, I select the new
> rules that I want to include and ignore or disable the ones I don’t. I
> wonder how useful it would be to include a list of new rule names for each
> new release, suitable for copy-paste into an existing ruleset?****
>
> ** **
>
> Chris****
>
> *From:* Evgeny Goldin [mailto:ev...@gm...]
> *Sent:* Sunday, August 07, 2011 5:42 PM
> *To:* cod...@li...
> *Subject:* [Codenarc-user] What do you think of merging rulesets?****
>
> ** **
>
> Hi,
> ****
>
> Today, I keep a copy of StarterRuleSet-AllRulesByCategory.groovy.txt<http://codenarc.sourceforge.net/StarterRuleSet-AllRulesByCategory.groovy.txt> in
> each project with some modifications where rules are disabled or tuned to
> match project preferences.****
>
> It's not very convenient since I need to update this large file for every
> new CodeNarc version, merging new rules added by CodeNarc and existing rules
> configured locally.****
>
> ** **
>
> Would it better if one could reference to:****
>
>    1. Default (probably remote) set of all rules like the one available on
>    the Web today.
>    If one decided to reference the default ruleset on CodeNarc site then
>    he should be aware of a need to upgrade CodeNarc version immediately when a
>    newer version is released as the default ruleset contains new rules,
>    not recognized by older CodeNarc (or we can ask CodeNarc not to fail on
>    unknown rules - this will make it more friendly and "forward compatible").
>    ****
>    2. Local set of rules, overriding the default set for any collision by
>    commenting out rules, disabling them (see below) or changing their
>    configuration.****
>
> ** **
>
> I understand that when rule is commented out in the second set, then it
> simply doesn't exist and if it's defined in the first set then it's enabled.
> ****
>
> But .. it would be nice if CodeNarc could see the rule is actually
> "disabled" in the second set. May be some new syntax for disabling rules can
> be added if commenting them out makes it harder.****
>
> Like a general "enabled" property for all rules and then one could write *"BracesForClass
> { enabled = false }"* in the second local set.****
>
> ** **
>
> I also see with 0.15 if first ruleset contains *"LineLength { length =
> 120 }"* and second  *"LineLength { length = 160 }"* then first value (120)
> is still used by CodeNarc.****
>
> ** **
>
> So .. what do you think of merging rulesets?****
>
> ** **
>
> ** **
>
> Warm regards,****
>
> Evgeny****
>
> evgeny-goldin.com****
>
> ** **
>

Re: [Codenarc-user] What do you think of merging rulesets?

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

Hi Evgeny,

 

I think you can already do most, if not all, of what you are requesting.

 

I just tested using this ruleset:

 

ruleset {

 

    description 'A Sample Groovy RuleSet'

 

    ruleset("http://codenarc.sourceforge.net/StarterRuleSet-AllRulesByCategory.groovy.txt") {

 

                BracesForClass(enabled:false)  // Map syntax for setting properties

 

                BracesForForLoop {                         // Closure syntax for setting properties

                                enabled = false

                }

    }

}

 

And it applies ALL of the rules minus the two that I disabled. 

 

That being said, I would not recommend referencing the “StarterRuleSet” from the CodeNarc site because, as you mentioned, its contents change immediately with each new release (and possibly even at other times) and would break your builds. So, perhaps you would substitute something like “MyDefaultCodeNarcRuleSet.groovy”.

 

I’m not sure I understand what you mean when you refer to the “first set” and “second set” of rules. But the above example illustrates the recommended approach for having a global/default ruleset and allowing projects/teams to customize it for a specific codebase. And any property values set in this ruleset override properties from the “default” ruleset that it includes (the “StarterRuleSet..” in this case).

 

I don’t have a great answer yet for how to migrate to the new version of CodeNarc, when more rules become available. In my case, I select the new rules that I want to include and ignore or disable the ones I don’t. I wonder how useful it would be to include a list of new rule names for each new release, suitable for copy-paste into an existing ruleset?

 

Chris

From: Evgeny Goldin [mailto:ev...@gm...] 
Sent: Sunday, August 07, 2011 5:42 PM
To: cod...@li...
Subject: [Codenarc-user] What do you think of merging rulesets?

 

Hi,


Today, I keep a copy of StarterRuleSet-AllRulesByCategory.groovy.txt <http://codenarc.sourceforge.net/StarterRuleSet-AllRulesByCategory.groovy.txt>  in each project with some modifications where rules are disabled or tuned to match project preferences.

It's not very convenient since I need to update this large file for every new CodeNarc version, merging new rules added by CodeNarc and existing rules configured locally.

 

Would it better if one could reference to:

1.	Default (probably remote) set of all rules like the one available on the Web today.
If one decided to reference the default ruleset on CodeNarc site then he should be aware of a need to upgrade CodeNarc version immediately when a newer version is released as the default ruleset contains new rules, 
not recognized by older CodeNarc (or we can ask CodeNarc not to fail on unknown rules - this will make it more friendly and "forward compatible").
2.	Local set of rules, overriding the default set for any collision by commenting out rules, disabling them (see below) or changing their configuration.

 

I understand that when rule is commented out in the second set, then it simply doesn't exist and if it's defined in the first set then it's enabled.

But .. it would be nice if CodeNarc could see the rule is actually "disabled" in the second set. May be some new syntax for disabling rules can be added if commenting them out makes it harder.

Like a general "enabled" property for all rules and then one could write "BracesForClass { enabled = false }" in the second local set.

 

I also see with 0.15 if first ruleset contains "LineLength { length = 120 }" and second  "LineLength { length = 160 }" then first value (120) is still used by CodeNarc.

 

So .. what do you think of merging rulesets?

 

 

Warm regards,

Evgeny

evgeny-goldin.com <http://evgeny-goldin.com/> 

 

[Codenarc-user] What do you think of merging rulesets?

[Evgeny G. <ev...@gm...>]

Hi,


Today, I keep a copy of
StarterRuleSet-AllRulesByCategory.groovy.txt<http://codenarc.sourceforge.net/StarterRuleSet-AllRulesByCategory.groovy.txt>
in
each project with some modifications where rules are disabled or tuned to
match project preferences.
It's not very convenient since I need to update this large file for every
new CodeNarc version, merging new rules added by CodeNarc and existing rules
configured locally.

Would it better if one could reference to:

   1. Default (probably remote) set of all rules like the one available on
   the Web today.
   If one decided to reference the default ruleset on CodeNarc site then he
   should be aware of a need to upgrade CodeNarc version immediately when a
   newer version is released as the default ruleset contains new rules,
   not recognized by older CodeNarc (or we can ask CodeNarc not to fail on
   unknown rules - this will make it more friendly and "forward compatible").
   2. Local set of rules, overriding the default set for any collision by
   commenting out rules, disabling them (see below) or changing their
   configuration.


I understand that when rule is commented out in the second set, then it
simply doesn't exist and if it's defined in the first set then it's enabled.
But .. it would be nice if CodeNarc could see the rule is actually
"disabled" in the second set. May be some new syntax for disabling rules can
be added if commenting them out makes it harder.
Like a general "enabled" property for all rules and then one could
write *"BracesForClass
{ enabled = false }"* in the second local set.

I also see with 0.15 if first ruleset contains *"LineLength { length =
120 }"* and second  *"LineLength { length = 160 }"* then first value (120)
is still used by CodeNarc.

So .. what do you think of merging rulesets?


Warm regards,
Evgeny
evgeny-goldin.com