codenarc-user — CodeNarc Users

[Codenarc-user] ExplicitCallToEqualsMethod and implementing equals method

[R. S. <ren...@go...>]

How is it possible to implement an equals method with the help of the
superclass' equals method?

@Override
boolean equals(Object that) {
    ...
    super.equals(that)
}

Shouldn't the ExplicitCallToEqualsMethod rule allow this?

Regards,
René Scheibe

[Codenarc-user] LoggerWithWrongModifiersRule supporting subclasses

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

Hi everyone,

This email is about the idea about the LoggerWithWrongModifiersRule
supporting subclasses.

René filed an issue (and supplied a patch) describing the issue:
https://sourceforge.net/tracker/index.php?func=detail&aid=3308930&group_id=250145&atid=1126575#

Basically, the question is how subclasses should be allowed to access
a Logger in a parent class.

Normally Loggers are private, static, and final. This patch allows you
to accept this as valid code when you turn a certain property on:

    protected final LOG = Logger.getLogger(this.class)

I'd like to discuss this just a little more before committing the patch.

With this change, it is acceptable to have a non-static logger. So
each instance of a subclass makes and creates a logger. This does not
seem right, and I would reject it in a code review as improper
logging. I would accept this form though:

    protected static final LOG = Logger.getLogger(MyClass.class)

Do we really want to allow non-static Loggers?

if so, I recommend two new properties instead of just one:
  * allowNonStaticLogger
  * allowProtectedLogger

Then the user can control the behavior a little better.



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

Re: [Codenarc-user] UnnecessaryGroovyImport handles static imports incorrectly

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

I agree with you René.

I think these should not be violations.

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



On Sun, May 29, 2011 at 8:59 PM, René Scheibe
<ren...@go...> wrote:
> Why does UnnecessaryGroovyImport mark static import of default imports as unnecessary? They are not staticly imported by default.
>
> Looking UnnecessaryGroovyImportTest shows that static imports are also tested. But the expected results are incorrect. See below:
>
> ---------------------------------------------------------------
> void testApplyTo_StaticImport_Violations() {
>    final SOURCE = '''
>        import static java.io.DataInputStream.*
>        import static java.lang.Integer.MAX_VALUE
>    '''
>    assertTwoViolations(SOURCE, 2, 'import static java.io.DataInputStream.*', 3, 'import static java.lang.Integer.MAX_VALUE')
> }
> ---------------------------------------------------------------
>
> If for example MAX_VALUE from java.lang.Integer should be used directly without prefixing it with Integer, it has to be imported staticly.
>
> If you feel the samem just let me know and I will open a ticket and fix it.
>
> Regards,
> René Scheibe
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>

[Codenarc-user] UnnecessaryGroovyImport handles static imports incorrectly

[R. S. <ren...@go...>]

Why does UnnecessaryGroovyImport mark static import of default imports as unnecessary? They are not staticly imported by default.

Looking UnnecessaryGroovyImportTest shows that static imports are also tested. But the expected results are incorrect. See below:

---------------------------------------------------------------
void testApplyTo_StaticImport_Violations() {
    final SOURCE = '''
        import static java.io.DataInputStream.*
        import static java.lang.Integer.MAX_VALUE
    '''
    assertTwoViolations(SOURCE, 2, 'import static java.io.DataInputStream.*', 3, 'import static java.lang.Integer.MAX_VALUE')
}
---------------------------------------------------------------

If for example MAX_VALUE from java.lang.Integer should be used directly without prefixing it with Integer, it has to be imported staticly.

If you feel the samem just let me know and I will open a ticket and fix it.

Regards,
René Scheibe

Re: [Codenarc-user] ExplicitCallToAndMethodRule: allowing explicit "and" calls for various classes?

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

>> Is it possible to allow explicit "and" calls on different classes in the
ExplicitCallToAndMethodRule?
>> doNotApplyToClassNames cannot be used because this filters only the
classes that are analyzed, not the ones, "and" is called on.
>> We are using Hamcrest a lot. It has a fluent interface which can go like
...

René,

Adding exceptions based on the class types that are the parameters would not
be practical, as you discovered, at least with the way CodeNarc currently
parses the source code.

As a workaround, I would just turn off the rule for all of your test
classes. e.g., 
    doNotApplyToClassNames = *Test,*Tests
or if you do not have a naming convention for your test classes, then use
doNotApplyToFileNames or doNotApplyToFilesMatching.

Chris

[Codenarc-user] ExplicitCallToAndMethodRule: allowing explicit "and" calls for various classes?

[R. S. <ren...@go...>]

Is it possible to allow explicit "and" calls on different classes in the
ExplicitCallToAndMethodRule?

doNotApplyToClassNames cannot be used because this filters only the
classes that are analyzed, not the ones, "and" is called on.

We are using Hamcrest a lot. It has a fluent interface which can go like
this:

--------------------------------------------------------------------
import static org.hamcrest.MatcherAssert.assertThat
import static org.hamcrest.Matchers.*

def numbers = [1, 2, 3]
assertThat numbers, hasItem(both(1).and(2))
--------------------------------------------------------------------

I already had a look at the rule implementation. And as suggested in
another thread I also changed the phase to OUTPUT in AbstractSourceCode.
But as expected this results in a compilation error as Hamcrest is not
part of CodeNarc.

Any ideas how to get the desired behavior?

Regards,
René Scheibe

Re: [Codenarc-user] CodeNarc with Groovy 1.8

[Cédric C. <ced...@gm...>]

That would be perfect.

Le 17/05/2011 07:23, Hamlet D'Arcy a écrit :
>> BTW, I'm wondering what I should do with the IDEA plugin: release two
>> versions ?
> No, I would not release two versions. We're going to make CodeNarc run
> on both 1.7 and 1.8 with the same binary class files. I talked to
> someone about this and you can do it. It means writing the missing
> class files into the Jar ourselves, but it is possible. It means
> CodeNarc will have classes in the package org.codeaus.groovy... that
> just dispatch on to the new location. Does that make sense?
>

Re: [Codenarc-user] CodeNarc with Groovy 1.8

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

> BTW, I'm wondering what I should do with the IDEA plugin: release two
> versions ?

No, I would not release two versions. We're going to make CodeNarc run
on both 1.7 and 1.8 with the same binary class files. I talked to
someone about this and you can do it. It means writing the missing
class files into the Jar ourselves, but it is possible. It means
CodeNarc will have classes in the package org.codeaus.groovy... that
just dispatch on to the new location. Does that make sense?

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



On Mon, May 16, 2011 at 2:14 PM, Cédric Champeau
<ced...@gm...> wrote:
> BTW, I'm wondering what I should do with the IDEA plugin: release two
> versions ?
>
> Le 16/05/2011 00:19, Chris Mair a écrit :
>>>> Concerning the Groovy 1.8 support...
>>>> Rene from Gradle is almost done with a Site plugin for Gradle. Once that
>> is complete then it will be much easier for
>>>> us to create two different artifacts for a single project, one based on
>> 1.7 and one on 1.8.
>>
>> Excellent. I know I am not the only one interested in that. Depending on the
>> capabilities, that should be a big selling point.
>>
>>>> How does this affect the Grails plugin? Will we need an option somewhere
>> to specify the dependency version
>>>> easily? (Grails won't support 1.8 for a while though, so no rush on that
>> problem)
>>
>> I am not really sure about the effect on the Grails plugin. That build
>> process/script is integrated with the Grails Plugin facility and repo. I do
>> manually add in the CodeNarc jar into that plugin project, but I don't know
>> how or if you could support multiple CodeNarc versions.
>>
>> Chris
>>
>>
>> ------------------------------------------------------------------------------
>> Achieve unprecedented app performance and reliability
>> What every C/C++ and Fortran developer should know.
>> Learn how Intel has extended the reach of its next-generation tools
>> to help boost performance applications - inlcuding clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> Codenarc-user mailing list
>> Cod...@li...
>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>

Re: [Codenarc-user] CodeNarc with Groovy 1.8

[Cédric C. <ced...@gm...>]

BTW, I'm wondering what I should do with the IDEA plugin: release two 
versions ?

Le 16/05/2011 00:19, Chris Mair a écrit :
>>> Concerning the Groovy 1.8 support...
>>> Rene from Gradle is almost done with a Site plugin for Gradle. Once that
> is complete then it will be much easier for
>>> us to create two different artifacts for a single project, one based on
> 1.7 and one on 1.8.
>
> Excellent. I know I am not the only one interested in that. Depending on the
> capabilities, that should be a big selling point.
>
>>> How does this affect the Grails plugin? Will we need an option somewhere
> to specify the dependency version
>>> easily? (Grails won't support 1.8 for a while though, so no rush on that
> problem)
>
> I am not really sure about the effect on the Grails plugin. That build
> process/script is integrated with the Grails Plugin facility and repo. I do
> manually add in the CodeNarc jar into that plugin project, but I don't know
> how or if you could support multiple CodeNarc versions.
>
> Chris
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user

Re: [Codenarc-user] CodeNarc with Groovy 1.8

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

>> Concerning the Groovy 1.8 support...
>> Rene from Gradle is almost done with a Site plugin for Gradle. Once that
is complete then it will be much easier for 
>> us to create two different artifacts for a single project, one based on
1.7 and one on 1.8.

Excellent. I know I am not the only one interested in that. Depending on the
capabilities, that should be a big selling point.

>> How does this affect the Grails plugin? Will we need an option somewhere
to specify the dependency version 
>> easily? (Grails won't support 1.8 for a while though, so no rush on that
problem)

I am not really sure about the effect on the Grails plugin. That build
process/script is integrated with the Grails Plugin facility and repo. I do
manually add in the CodeNarc jar into that plugin project, but I don't know
how or if you could support multiple CodeNarc versions.

Chris

Re: [Codenarc-user] CodeNarc with Groovy 1.8

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

Concerning the Groovy 1.8 support...

Rene from Gradle is almost done with a Site plugin for Gradle. Once
that is complete then it will be much easier for us to create two
different artifacts for a single project, one based on 1.7 and one on
1.8.

How does this affect the Grails plugin? Will we need an option
somewhere to specify the dependency version easily? (Grails won't
support 1.8 for a while though, so no rush on that problem)


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



On Mon, May 9, 2011 at 3:00 PM,  <chr...@we...> wrote:
>>> I just wanted to ask for the timeline to support Groovy 1.8?
>>>
>>> Currently CodeNarc 0.13 fails with Groovy 1.8 because some packages have
>>> been rearranged in Groovy.
>>>
>>> Groovy 1.7.10: org/codehaus/groovy/transform/powerassert/ValueRecorder
>>> Groovy 1.8.0:  org/codehaus/groovy/runtime/powerassert/ValueRecorder
>>>
>>> Regars,
>>> René Scheibe
>
>> The package rearrangement means that we just need to recompile the
>> product and re-deploy it. I estimate it would take only a few hours to
>> fix all the failing tests that 1.8 creates (I've already done the
>> research). But the bigger problem is that this means two Maven
>> artefacts: CodeNarc_for_Groovy_1_7 and CodeNarc_for_Groovy_1_8. That's
>> unfortunate because it is additional complexity in getting up and
>> running. One possible (but untested) alternative is to remove all
>> "assert" statements from the CodeNarc codebase. Then the ValueRecorder
>> incompatibility might never be triggered and we wouldn't need two
>> different deployments. I'll let Chris weigh in on this issue and see
>> what he things.
>>
>> Hamlet D'Arcy
>
> I would be hesitant to remove all of the "assert" statements. Would you replace them with a custom assert-like facility? I hate to bastardize the code like that, but perhaps that would be a worthwhile sacrifice in the name of pragmatism.
>
> And having two separate branches and maven artefacts (1.7/1.8) sounds pretty distasteful as well. Of course at some point we will need to support Groovy 1.8. Since CodeNarc runtime environment is not tied to the code that it analyzes (i.e. it can run in 1.7 and analyze 1.8 code), I would be inclined to leave it at 1.7 for the upcoming 0.14 release. Perhaps once there is a "tipping point" to 1.8, we can switch over. That does, however, have implications for environments/tools that are tied to a specific Groovy version of Groovy -- e.g. Grails. So, maybe we decide at that point that it is worth it to support two streams, or maybe we just make a clean break and move to 1.8. Worth some discussion and debate.
>
> Thanks.
> Chris
>

Re: [Codenarc-user] CodeNarc with Groovy 1.8

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

>> I just wanted to ask for the timeline to support Groovy 1.8?
>>
>> Currently CodeNarc 0.13 fails with Groovy 1.8 because some packages have
>> been rearranged in Groovy.
>>
>> Groovy 1.7.10: org/codehaus/groovy/transform/powerassert/ValueRecorder
>> Groovy 1.8.0:  org/codehaus/groovy/runtime/powerassert/ValueRecorder
>>
>> Regars,
>> René Scheibe

> The package rearrangement means that we just need to recompile the
> product and re-deploy it. I estimate it would take only a few hours to
> fix all the failing tests that 1.8 creates (I've already done the
> research). But the bigger problem is that this means two Maven
> artefacts: CodeNarc_for_Groovy_1_7 and CodeNarc_for_Groovy_1_8. That's
> unfortunate because it is additional complexity in getting up and
> running. One possible (but untested) alternative is to remove all
> "assert" statements from the CodeNarc codebase. Then the ValueRecorder
> incompatibility might never be triggered and we wouldn't need two
> different deployments. I'll let Chris weigh in on this issue and see
> what he things.
>
> Hamlet D'Arcy

I would be hesitant to remove all of the "assert" statements. Would you replace them with a custom assert-like facility? I hate to bastardize the code like that, but perhaps that would be a worthwhile sacrifice in the name of pragmatism.

And having two separate branches and maven artefacts (1.7/1.8) sounds pretty distasteful as well. Of course at some point we will need to support Groovy 1.8. Since CodeNarc runtime environment is not tied to the code that it analyzes (i.e. it can run in 1.7 and analyze 1.8 code), I would be inclined to leave it at 1.7 for the upcoming 0.14 release. Perhaps once there is a "tipping point" to 1.8, we can switch over. That does, however, have implications for environments/tools that are tied to a specific Groovy version of Groovy -- e.g. Grails. So, maybe we decide at that point that it is worth it to support two streams, or maybe we just make a clean break and move to 1.8. Worth some discussion and debate.

Thanks.
Chris

Re: [Codenarc-user] CodeNarc with Groovy 1.8

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

The package rearrangement means that we just need to recompile the
product and re-deploy it. I estimate it would take only a few hours to
fix all the failing tests that 1.8 creates (I've already done the
research). But the bigger problem is that this means two Maven
artefacts: CodeNarc_for_Groovy_1_7 and CodeNarc_for_Groovy_1_8. That's
unfortunate because it is additional complexity in getting up and
running. One possible (but untested) alternative is to remove all
"assert" statements from the CodeNarc codebase. Then the ValueRecorder
incompatibility might never be triggered and we wouldn't need two
different deployments. I'll let Chris weigh in on this issue and see
what he things.

We currently have 23 new rules finished for the unreleased 0.14
version, plus a few defects that _must_ be fixed. I was hoping for an
end-of-May release after the GR8 conference.

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



On Mon, May 9, 2011 at 12:04 AM, René Scheibe
<ren...@go...> wrote:
> Hi,
>
> I just wanted to ask for the timeline to support Groovy 1.8?
>
> Currently CodeNarc 0.13 fails with Groovy 1.8 because some packages have
> been rearranged in Groovy.
>
> Groovy 1.7.10: org/codehaus/groovy/transform/powerassert/ValueRecorder
> Groovy 1.8.0:  org/codehaus/groovy/runtime/powerassert/ValueRecorder
>
> Regars,
> René Scheibe
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>

[Codenarc-user] CodeNarc with Groovy 1.8

[R. S. <ren...@go...>]

Hi,

I just wanted to ask for the timeline to support Groovy 1.8?

Currently CodeNarc 0.13 fails with Groovy 1.8 because some packages have
been rearranged in Groovy.

Groovy 1.7.10: org/codehaus/groovy/transform/powerassert/ValueRecorder
Groovy 1.8.0:  org/codehaus/groovy/runtime/powerassert/ValueRecorder

Regars,
René Scheibe

Re: [Codenarc-user] CodeNarc: Adding Custom Rules in a Grails project

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

>> I have not been able yet to use a custom rule class (compiled) from within the CodeNarc plugin. 

>> I’ll try to look into that a bit more next week. I was able to use a rule script, however.

 

After doing a little more research, it looks like a Grails Plugin is intentionally not given (direct) access to application classes.

 

See http://grails.1312388.n4.nabble.com/Can-a-plugin-use-an-application-level-class-td3330014.html, including:

“Can a Grails plugin access an application level class? … No. The only way is via dynamic class loading … Or refactor that class into another plugin :)”

 

Chris

Re: [Codenarc-user] CodeNarc: Adding Custom Rules in a Grails project

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

Glad you got everything working.

 

>> I can now focus on writing a rule for identifying potential SQL Injection vulnerability.

 

If you come up with a good rule that others might find useful and you’re willing to share, please open a feature request and attach it as a patch (https://sourceforge.net/tracker/?group_id=250145 <https://sourceforge.net/tracker/?group_id=250145&atid=1126575> &atid=1126575), or just send it directly if you’d prefer.

 

Chris

Re: [Codenarc-user] CodeNarc: Adding Custom Rules in a Grails project

[Jan K. <ja...@fa...>]

Chris,
thank you so much.
I was indeed running into issue 13 -
http://jira.grails.org/browse/GPCODENARC-13. Commenting out the two
rules made it CodeNarc work again.
Also, following your approach to add a custom rule using the "classic"
rule("file:...") approach worked for me.
Cheers,
Jan

2011/4/29 Chris Mair <chr...@ea...>
>
> Jan,
>
>
>
> >> 1) Changing from the standard ruleset (somehow part of the CodeNarc for grails Plugin) to my ruleset using this configuration in Config.groovy:
>
> >>codenarc.ruleSetFiles="file:grails-app/conf/MyRuleSet.groovy"
>
> >> Causes all violations to disappear from the generated report.
>
>
>
> I suspect you may be running into http://jira.grails.org/browse/GPCODENARC-13.
>
> Also see http://grails.1312388.n4.nabble.com/Codenarc-Plugin-ruleset-configuration-td3462471.html#a3462495.
>
> If you are including the AbcComplexity and CyclomaticComplexity rules, try removing them (or the entire “size” ruleset).
>
>
>
> I have not been able yet to use a custom rule class (compiled) from within the CodeNarc plugin. I’ll try to look into that a bit more next week. I was able to use a rule script, however.
>
>
>
> My “Config.groovy” included:
>
>     codenarc.ruleSetFiles = "file:grails-app/conf/MyGroovyRuleSet.groovy"
>
>
>
> My ruleset file (“MyGroovyRuleSet.groovy"):
>
>
>
> ruleset {
>
>     MethodName
>
>
>
>     // Custom rule
>
>     rule("file:grails-app/conf/MyStaticFieldRuleScript.groovy") {
>
>         priority = 3
>
>     }
>
>
>
>     ruleset('rulesets/basic.xml')
>
>     ruleset('rulesets/imports.xml')
>
> }
>
>
>
> And “grails-app/conf/MyStaticFieldRuleScript.groovy":
>
>
>
> import org.codenarc.rule.AbstractRule
>
> import org.codenarc.source.SourceCode
>
>
>
> /**
>
> * Sample rule. Checks for static fields.
>
> */
>
> class MyStaticFieldRule extends AbstractRule {
>
>     String name = 'MyStaticField'
>
>     String description = 'Check for static fields'
>
>     int priority = 2
>
>
>
>     void applyTo(SourceCode sourceCode, List violations) {
>
>         sourceCode.ast.classes.each { clazz ->
>
>             clazz.fields.each { fieldNode ->
>
>                 if (fieldNode.static) {
>
>                     violations << createViolation(sourceCode, fieldNode)
>
>                 }
>
>             }
>
>         }
>
>     }
>
> }
>
>
>
> Chris
>
>
>
> From: Jan Karstens [mailto:ja...@fa...]
> Sent: Friday, April 29, 2011 4:08 AM
> To: cod...@li...
> Subject: [Codenarc-user] CodeNarc: Adding Custom Rules in a Grails project
>
>
>
> Hello,
>
>
>
> I am new to CodeNarc but rather experienced in Static Code Analysis. I am working on a Grails project where we want to apply static code analysis to scan for some project specific patterns. Adding the CodeNarc plugin to Grails and running codenarc (Plugin 0.12, CodeNarc 0.13) was really simple.
>
>
>
> I am wondering if it is possible to create CodeNarc Rules local to my Grails project. I read the documentation and watched the screencast on creating new rules. But this all refers to creating new rules in the context of the codenarc project. Is it possible to create a rule in a grails project and reference it from the ruleset?
>
>
>
> I am a bit stuck right now and any hint or help is greatly appreciated.
>
>
>
> 1) Changing from the standard ruleset (somehow part of the CodeNarc for grails Plugin) to my ruleset using this configuration in Config.groovy:
>
>
>
> codenarc.ruleSetFiles="file:grails-app/conf/MyRuleSet.groovy"
>
>
>
> Causes all violations to disappear from the generated report. I have the standard groovy ruleset configured and all these rules get listed in the report, but no violation is generated. Commenting out the ruleSetFile configuration and running grails codenarc brings back the violations.
>
>
>
> Is this a Grails Plugin issue or a CodeNarc Issue? Any idea or suggestion how I could test this outside of the Grails context?
>
>
>
> 2) I have created my own simple test rule and put it into the src/groovy folder in the Grails project structure. I am not sure if this is a valid approach, but it seems to violate some implicit assumptions. Adding my rule to the ruleset and running 'grails codenarc' leads to the following error:
>
>
>
> Running CodeNarc ...
>
> FAILED -- java.lang.AssertionError: No such rule named [MyRule]. Expression: ruleClass. Values: ruleClass = null
>
>
>
> Seems that the Rule script could not be found by CodeNarc. Again, am I missing something? Is it possible at to create and use a Grails project local rule?
>
>
>
> Again, any hints or help is greatly appreciated. I would really like to get this to work, as the combination of Groovy and the CodeNarc API for AST-analysis seem to be pretty powerful for writing static code checks.
>
>
>
> Best regards,
>
>
>
> Jan

Re: [Codenarc-user] CodeNarc: Adding Custom Rules in a Grails project

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

Jan,

 

>> 1) Changing from the standard ruleset (somehow part of the CodeNarc for grails Plugin) to my ruleset using this configuration in Config.groovy:

>>codenarc.ruleSetFiles="file:grails-app/conf/MyRuleSet.groovy"

>> Causes all violations to disappear from the generated report.

 

I suspect you may be running into http://jira.grails.org/browse/GPCODENARC-13.

Also see http://grails.1312388.n4.nabble.com/Codenarc-Plugin-ruleset-configuration-td3462471.html#a3462495.

If you are including the AbcComplexity and CyclomaticComplexity rules, try removing them (or the entire “size” ruleset).

 

I have not been able yet to use a custom rule class (compiled) from within the CodeNarc plugin. I’ll try to look into that a bit more next week. I was able to use a rule script, however.

 

My “Config.groovy” included:

    codenarc.ruleSetFiles = "file:grails-app/conf/MyGroovyRuleSet.groovy"

 

My ruleset file (“MyGroovyRuleSet.groovy"):

 

ruleset {

    MethodName

 

    // Custom rule

    rule("file:grails-app/conf/MyStaticFieldRuleScript.groovy") {

        priority = 3

    }

 

    ruleset('rulesets/basic.xml')

    ruleset('rulesets/imports.xml')

}

 

And “grails-app/conf/MyStaticFieldRuleScript.groovy":

 

import org.codenarc.rule.AbstractRule

import org.codenarc.source.SourceCode

 

/**

* Sample rule. Checks for static fields.

*/

class MyStaticFieldRule extends AbstractRule {

    String name = 'MyStaticField'

    String description = 'Check for static fields'

    int priority = 2

 

    void applyTo(SourceCode sourceCode, List violations) {

        sourceCode.ast.classes.each { clazz ->

            clazz.fields.each { fieldNode ->

                if (fieldNode.static) {

                    violations << createViolation(sourceCode, fieldNode)

                }

            }

        }

    }

}

 

Chris

 

From: Jan Karstens [mailto:ja...@fa...] 
Sent: Friday, April 29, 2011 4:08 AM
To: cod...@li...
Subject: [Codenarc-user] CodeNarc: Adding Custom Rules in a Grails project

 

Hello,

 

I am new to CodeNarc but rather experienced in Static Code Analysis. I am working on a Grails project where we want to apply static code analysis to scan for some project specific patterns. Adding the CodeNarc plugin to Grails and running codenarc (Plugin 0.12, CodeNarc 0.13) was really simple. 

 

I am wondering if it is possible to create CodeNarc Rules local to my Grails project. I read the documentation and watched the screencast on creating new rules. But this all refers to creating new rules in the context of the codenarc project. Is it possible to create a rule in a grails project and reference it from the ruleset?

 

I am a bit stuck right now and any hint or help is greatly appreciated.

 

1) Changing from the standard ruleset (somehow part of the CodeNarc for grails Plugin) to my ruleset using this configuration in Config.groovy:

 

codenarc.ruleSetFiles="file:grails-app/conf/MyRuleSet.groovy"

 

Causes all violations to disappear from the generated report. I have the standard groovy ruleset configured and all these rules get listed in the report, but no violation is generated. Commenting out the ruleSetFile configuration and running grails codenarc brings back the violations.

 

Is this a Grails Plugin issue or a CodeNarc Issue? Any idea or suggestion how I could test this outside of the Grails context?

 

2) I have created my own simple test rule and put it into the src/groovy folder in the Grails project structure. I am not sure if this is a valid approach, but it seems to violate some implicit assumptions. Adding my rule to the ruleset and running 'grails codenarc' leads to the following error:

 

Running CodeNarc ...

FAILED -- java.lang.AssertionError: No such rule named [MyRule]. Expression: ruleClass. Values: ruleClass = null

 

Seems that the Rule script could not be found by CodeNarc. Again, am I missing something? Is it possible at to create and use a Grails project local rule?

 

Again, any hints or help is greatly appreciated. I would really like to get this to work, as the combination of Groovy and the CodeNarc API for AST-analysis seem to be pretty powerful for writing static code checks.

 

Best regards,

 

Jan 

[Codenarc-user] CodeNarc: Adding Custom Rules in a Grails project

[Jan K. <ja...@fa...>]

Hello,

I am new to CodeNarc but rather experienced in Static Code Analysis. I am
working on a Grails project where we want to apply static code analysis to
scan for some project specific patterns. Adding the CodeNarc plugin to
Grails and running codenarc (Plugin 0.12, CodeNarc 0.13) was really simple.

I am wondering if it is possible to create CodeNarc Rules local to my Grails
project. I read the documentation and watched the screencast on creating new
rules. But this all refers to creating new rules in the context of the
codenarc project. Is it possible to create a rule in a grails project and
reference it from the ruleset?

I am a bit stuck right now and any hint or help is greatly appreciated.

1) Changing from the standard ruleset (somehow part of the CodeNarc for
grails Plugin) to my ruleset using this configuration in Config.groovy:

codenarc.ruleSetFiles="file:grails-app/conf/MyRuleSet.groovy"

Causes all violations to disappear from the generated report. I have the
standard groovy ruleset configured and all these rules get listed in the
report, but no violation is generated. Commenting out the ruleSetFile
configuration and running grails codenarc brings back the violations.

Is this a Grails Plugin issue or a CodeNarc Issue? Any idea or suggestion
how I could test this outside of the Grails context?

2) I have created my own simple test rule and put it into the src/groovy
folder in the Grails project structure. I am not sure if this is a valid
approach, but it seems to violate some implicit assumptions. Adding my rule
to the ruleset and running 'grails codenarc' leads to the following error:

Running CodeNarc ...

FAILED -- java.lang.AssertionError: No such rule named [MyRule]. Expression:
ruleClass. Values: ruleClass = null

Seems that the Rule script could not be found by CodeNarc. Again, am I
missing something? Is it possible at to create and use a Grails project
local rule?

Again, any hints or help is greatly appreciated. I would really like to get
this to work, as the combination of Groovy and the CodeNarc API for
AST-analysis seem to be pretty powerful for writing static code checks.

Best regards,

Jan

[Codenarc-user] codenarc feature requests assigned to nobody

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

Hi All, 

I got a message thru the SourceForge website asking about the Features Requests assigned to nobody. (but for some reason there was no way to reply to the message). 

The Nobody features are open to anyone to work on. Just attach a patch to the issue and we should see the change. If nothing happens then perhaps send a message to this list. 

Thanks, 

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

[Codenarc-user] 2 CodeNarc presentation this Spring

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

Hi All,

I was surprised to see two CodeNarc related presentations at
conferences in the next few months.

Hubert Klein Ikkink (MrHaKi) will be talking about CodeNarc at GR8
Europe: http://www.eu2011.gr8conf.org/talk/codenarc
And Stefan Glase will be talking about CodeNarc at GearConf in
Germany: http://gearconf.com/sprecher2011

I stumbled upon these by accident, and it is cool to see the community
taking off.

If anyone knows of other user groups or conferences with CodeNarc
content, then feel free to share it here.

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

Re: [Codenarc-user] Incomplete AST nodes?

[Klaus B. <kla...@go...>]

Hi Hamlet,

the class hierarchy problem is because the AST generation takes a
class at a time and fills the superClass property just for the next
level up. If the superClass itself has not yet been inspected, it gets
Object as superClass.

The way I (kind of) solved this problem was by using a 2-phase
approach. I modified the Codenarc script to run it two times and at
the same time build my own class-superClass map. Not perfect, I know.
But I got a complete hierarchy.

Now to the actual problem I want to solve: I'm writing a rule, that
finds non-declared properties (or you might say dynamic properties).
That is all variable accesses that are not declared in the
class/superClass, the closure or whatever context the access is. I'm
pretty close to a working solution but I it will remain an
approximation to a strict parser with holes in it. The background is
to give the developers in my organisation a tool to check for typos
and 'forgotten' variables due to incomplete refactoring.
I continued, where GroovyLint stopped. I tried enhancing GroovyLint on
this topic, but at some point I got non-debuggable
ClassNotFound-exceptions and went over to CodeNarc. At this point I
also discovered the differences in completeness of the AST tree
between GroovyLint and CodeNarc (mainly because of the different
compile stage).
I also though about using Groovy++ for that task, but at this point
G++ has a different semantic than original Groovy wrt. scope in
closures and maybe elsewhere too.

Anyway, that is my goal for giving Java programmers a smooth
transition to Groovy. You might argue, that CodeNarc is not the right
tool. IntelliJ would be an alternative, since it identifies these
variables as well, but I miss the reporting capability over a code
base.

Btw. a topic for a side-discussion at GR-8 in Copenhagen?!

Best regards,
klaus.

On Wed, Apr 13, 2011 at 9:15 PM, Hamlet DArcy <ham...@ca...> wrote:
> CodeNarc runs in a fairly early compiler phase. We do this so that you don't need to have the project's compiled class files on the classpath... you can still run CodeNarc even if your build/code is broken! On the negative side, that means a lot of type information is missing. Be careful when referencing types because any non-JDK types may not exist at the time you run CodeNarc.
>
> Do you have a simple example of the source the shows Object as the parent class with the missing inheritence problem? SOmething like
> {code}
> class A {}
> class B extends A {}
> class C extends B {}
> {code}
> Or something simple like that?
>
> ALso, I'd love to hear the specifics of the rule. Perhaps I can quickly write it for you, that way we can include it in the base product rather than leave it to something for you to maintain. (just a thought)
>
>
> ----- Original Message -----
>> I'm trying to build a rather complex rule based on information also
>> kept in the super class of a classnode. I made several observations:
>> 1. The class hierarchy seems broken with some classes. That is,
>> walking up along the superClass members I see java.lang.Object too
>> soon
>> 2. Not all fields of a class are visible in the classNode.
>>
>> I've built a rule based on the AbstractAstVisitor and overloaded
>> multiple visit* methods, such as visitClassEx and
>> visitConstructorOrMethodEx.
>>
>> For the incomplete fields information I suspect the threaded
>> execution
>> of the rules against the fileset. But why some superClass info is
>> missing I cannot explain.
>>
>> Any idea, what goes wrong here?
>>
>> Regards,
>> klaus.
>>
>> ------------------------------------------------------------------------------
>> Forrester Wave Report - Recovery time is now measured in hours and
>> minutes
>> not days. Key insights are discussed in the 2010 Forrester Wave
>> Report as
>> part of an in-depth evaluation of disaster recovery service
>> providers.
>> Forrester found the best-in-class provider in terms of services and
>> vision.
>> Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
>> _______________________________________________
>> Codenarc-user mailing list
>> Cod...@li...
>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>
>

Re: [Codenarc-user] Incomplete AST nodes?

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

CodeNarc runs in a fairly early compiler phase. We do this so that you don't need to have the project's compiled class files on the classpath... you can still run CodeNarc even if your build/code is broken! On the negative side, that means a lot of type information is missing. Be careful when referencing types because any non-JDK types may not exist at the time you run CodeNarc. 

Do you have a simple example of the source the shows Object as the parent class with the missing inheritence problem? SOmething like
{code}
class A {}
class B extends A {}
class C extends B {}
{code}
Or something simple like that? 

ALso, I'd love to hear the specifics of the rule. Perhaps I can quickly write it for you, that way we can include it in the base product rather than leave it to something for you to maintain. (just a thought)


----- Original Message -----
> I'm trying to build a rather complex rule based on information also
> kept in the super class of a classnode. I made several observations:
> 1. The class hierarchy seems broken with some classes. That is,
> walking up along the superClass members I see java.lang.Object too
> soon
> 2. Not all fields of a class are visible in the classNode.
> 
> I've built a rule based on the AbstractAstVisitor and overloaded
> multiple visit* methods, such as visitClassEx and
> visitConstructorOrMethodEx.
> 
> For the incomplete fields information I suspect the threaded
> execution
> of the rules against the fileset. But why some superClass info is
> missing I cannot explain.
> 
> Any idea, what goes wrong here?
> 
> Regards,
> klaus.
> 
> ------------------------------------------------------------------------------
> Forrester Wave Report - Recovery time is now measured in hours and
> minutes
> not days. Key insights are discussed in the 2010 Forrester Wave
> Report as
> part of an in-depth evaluation of disaster recovery service
> providers.
> Forrester found the best-in-class provider in terms of services and
> vision.
> Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
> 

[Codenarc-user] Incomplete AST nodes?

[Klaus B. <kla...@go...>]

I'm trying to build a rather complex rule based on information also
kept in the super class of a classnode. I made several observations:
1. The class hierarchy seems broken with some classes. That is,
walking up along the superClass members I see java.lang.Object too
soon
2. Not all fields of a class are visible in the classNode.

I've built a rule based on the AbstractAstVisitor and overloaded
multiple visit* methods, such as visitClassEx and
visitConstructorOrMethodEx.

For the incomplete fields information I suspect the threaded execution
of the rules against the fileset. But why some superClass info is
missing I cannot explain.

Any idea, what goes wrong here?

Regards,
klaus.

[Codenarc-user] [ANN] Announcing Grails CodeNarc Plugin 0.12

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

Announcing the release of the Grails CodeNarc Plugin
<http://grails.org/plugin/codenarc>  version 0.12.

CodeNarc <http://codenarc.sourceforge.net/>  is a static analysis tool for
Groovy source code. The Grails CodeNarc Plugin
<http://grails.org/plugin/codenarc>  provides CodeNarc integration for your
Grails projects.

New Features 

.         New Reports DSL, including support for multiple reports.
http://jira.grails.org/browse/GPCODENARC-7.

The preferred way to configure reports is now to specify a reports DSL
closure within "config.groovy", e.g.

codenarc.reports = {

MyXmlReport('xml') { 

outputFile = 'CodeNarc-Report.xml' 

title = 'Sample Report' 

}

MyHtmlReport('html') {

outputFile = 'CodeNarc-Report.html' 

title = 'Sample Report' 

}

}

NOTE: The codenarc.reportName, codenarc.reportTitle and codenarc.reportType
configuration properties are now deprecated.

.         Provide error message on failure instead of throwing
BuildException. Add support for codenarc.systemExitOnBuildException
configuration option; defaults to true:
http://jira.grails.org/browse/GPCODENARC-9.

.         Allow CodeNarc rules to optionally be applied to GSP files:
http://jira.grails.org/browse/GPCODENARC-11.