codenarc-user — CodeNarc Users

[Codenarc-user] @Grab and IntelliJ IDEA

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

Hi,

I'm having hard days working around this bug : 
https://github.com/melix/codenarc-idea/issues#issue/1

First IntelliJ seems to do some dark magic swallowing my exceptions :

|try {
    final List<Violation> list = rule.applyTo(code);
} catch (Throwable e) {
... // never gets executed oO, but should according to the stack trace
}
|
doesn't work oO, but that's not directly related to CodeNarc. What is 
related is that it complains about a missing Ivy dependency, because of 
the @Grab annotation in the source file. That said, I think it's 
dangerous for CodeNarc to trigger the @Grab resolving process, because 
if the inspection is configured as a runtime inspection in the IDE, then 
CodeNarc would download the dependency where one would have expected it 
to be downloaded at execution time only. What do you think ? Do you have 
any workaround for this ? Here's the stacktrace from IntelliJ IDEA :


|[1140420]  ERROR - m.intellij.concurrency.JobUtil - 
org/apache/ivy/core/report/ResolveReport
java.lang.NoClassDefFoundError: org/apache/ivy/core/report/ResolveReport
     at java.lang.Class.getDeclaredMethods0(Native Method)
     at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
     at java.lang.Class.getDeclaredMethods(Class.java:1791)
     at 
org.codehaus.groovy.reflection.CachedClass$3$1.run(CachedClass.java:83)
     at java.security.AccessController.doPrivileged(Native Method)
     at 
org.codehaus.groovy.reflection.CachedClass$3.initValue(CachedClass.java:80)
     at 
org.codehaus.groovy.reflection.CachedClass$3.initValue(CachedClass.java:78)
     at 
org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
     at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:33)
     at 
org.codehaus.groovy.reflection.CachedClass.getMethods(CachedClass.java:249)
     at groovy.lang.MetaClassImpl.populateMethods(MetaClassImpl.java:341)
     at groovy.lang.MetaClassImpl.fillMethodIndex(MetaClassImpl.java:291)
     at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2914)
     at 
org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
     at 
org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
     at groovy.grape.GrapeIvy.$getStaticMetaClass(GrapeIvy.groovy)
     at groovy.grape.GrapeIvy.<init>(GrapeIvy.groovy:59)
     at sun.reflect.GeneratedConstructorAccessor82.newInstance(Unknown 
Source)
     at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
     at java.lang.Class.newInstance0(Class.java:355)
     at java.lang.Class.newInstance(Class.java:308)
     at groovy.grape.Grape.getInstance(Grape.java:103)
     at groovy.grape.Grape.grab(Grape.java:138)
     at 
groovy.grape.GrabAnnotationTransformation.visit(GrabAnnotationTransformation.java:260)
     at 
org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:302)
     at 
org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:813)
     at 
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:511)
     at 
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:487)
     at 
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:464)
     at sun.reflect.GeneratedMethodAccessor261.invoke(Unknown Source)
     at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at 
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
     at 
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
     at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
     at 
org.codenarc.source.AbstractSourceCode.getAst(AbstractSourceCode.groovy:71)
     at sun.reflect.GeneratedMethodAccessor117.invoke(Unknown Source)
     at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at 
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:88)
     at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
     at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1600)
     at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3305)
     at 
org.codenarc.source.AbstractSourceCode.getProperty(AbstractSourceCode.groovy)
     at 
org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:47)
     at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:237)
     at 
org.codenarc.rule.AbstractAstVisitorRule.applyTo(AbstractAstVisitorRule.groovy:77)
     at 
org.codenarc.rule.AbstractAstVisitorRule$applyTo$0.callCurrent(Unknown 
Source)
     at 
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
     at 
org.codenarc.rule.AbstractAstVisitorRule$applyTo$0.callCurrent(Unknown 
Source)
     at org.codenarc.rule.AbstractRule.applyTo(AbstractRule.groovy:126)
*at 
org.codenarc.idea.CodeNarcInspectionTool$2.compute(CodeNarcInspectionTool.java:163)* 
*// final List<Violation> list = rule.applyTo(code);*
     at 
org.codenarc.idea.CodeNarcInspectionTool$2.compute(CodeNarcInspectionTool.java:150)
     at 
com.intellij.psi.impl.PsiParameterizedCachedValue.doCompute(PsiParameterizedCachedValue.java:52)
     at 
com.intellij.util.CachedValueBase.getValueWithLock(CachedValueBase.java:191)
     at 
com.intellij.psi.impl.PsiParameterizedCachedValue.getValue(PsiParameterizedCachedValue.java:43)
     at 
org.codenarc.idea.CodeNarcInspectionTool.checkFile(CodeNarcInspectionTool.java:185)
     at 
com.intellij.codeInspection.LocalInspectionTool$1.visitFile(LocalInspectionTool.java:128)
     at com.intellij.extapi.psi.PsiFileBase.accept(PsiFileBase.java:70)
     at 
com.intellij.codeInsight.daemon.impl.LocalInspectionsPass.a(LocalInspectionsPass.java:309)
     at 
com.intellij.codeInsight.daemon.impl.LocalInspectionsPass.access$100(LocalInspectionsPass.java:76)
     at 
com.intellij.codeInsight.daemon.impl.LocalInspectionsPass$1.process(LocalInspectionsPass.java:274)
     at 
com.intellij.codeInsight.daemon.impl.LocalInspectionsPass$1.process(LocalInspectionsPass.java:258)
     at com.intellij.concurrency.JobUtil$2$1.run(JobUtil.java:116)
     at 
com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:233)
     at com.intellij.concurrency.JobUtil$2.process(JobUtil.java:114)
     at com.intellij.concurrency.JobUtil$1.run(JobUtil.java:57)
     at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
     at java.util.concurrent.FutureTask.run(FutureTask.java:138)
     at 
com.intellij.concurrency.PrioritizedFutureTask.access$101(PrioritizedFutureTask.java:31)
     at 
com.intellij.concurrency.PrioritizedFutureTask$1.run(PrioritizedFutureTask.java:70)
     at 
com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:1016)
     at 
com.intellij.concurrency.PrioritizedFutureTask.run(PrioritizedFutureTask.java:97)
     at 
com.intellij.concurrency.JobSchedulerImpl.stealAndRunTask(JobSchedulerImpl.java:65)
     at 
com.intellij.concurrency.JobImpl.scheduleAndWaitForResults(JobImpl.java:126)
     at com.intellij.concurrency.JobUtil.a(JobUtil.java:71)
     at 
com.intellij.concurrency.JobUtil.invokeConcurrentlyUnderProgress(JobUtil.java:111)
     at 
com.intellij.codeInsight.daemon.impl.LocalInspectionsPass.a(LocalInspectionsPass.java:258)
     at 
com.intellij.codeInsight.daemon.impl.LocalInspectionsPass.a(LocalInspectionsPass.java:225)
     at 
com.intellij.codeInsight.daemon.impl.LocalInspectionsPass.collectInformationWithProgress(LocalInspectionsPass.java:122)
     at 
com.intellij.codeInsight.daemon.impl.ProgressableTextEditorHighlightingPass.doCollectInformation(ProgressableTextEditorHighlightingPass.java:57)
     at 
com.intellij.codeHighlighting.TextEditorHighlightingPass.collectInformation(TextEditorHighlightingPass.java:58)
     at 
com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass$1$1.run(PassExecutorService.java:348)
     at 
com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:1016)
     at 
com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass$1.run(PassExecutorService.java:340)
     at 
com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:233)
     at 
com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.a(PassExecutorService.java:338)
     at 
com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.run(PassExecutorService.java:314)
     at com.intellij.concurrency.JobUtil$3.call(JobUtil.java:133)
     at com.intellij.concurrency.JobUtil$3.call(JobUtil.java:130)
     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
     at java.util.concurrent.FutureTask.run(FutureTask.java:138)
     at 
com.intellij.concurrency.PrioritizedFutureTask.access$101(PrioritizedFutureTask.java:31)
     at 
com.intellij.concurrency.PrioritizedFutureTask$1.run(PrioritizedFutureTask.java:70)
     at 
com.intellij.concurrency.PrioritizedFutureTask.run(PrioritizedFutureTask.java:113)
     at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
     at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
     at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassNotFoundException: 
org.apache.ivy.core.report.ResolveReport
     at 
com.intellij.util.lang.UrlClassLoader.findClass(UrlClassLoader.java:71)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
     at 
com.intellij.util.lang.UrlClassLoader.loadClass(UrlClassLoader.java:84)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
     ... 100 more

|

Re: [Codenarc-user] new report format (css/formatting)

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

Wow, that does look pretty sweet!

Very nice work.

"Hamlet D'Arcy" <ham...@gm...> wrote on 02/25/2011 03:25:06 PM:

> Thanks everyone for the help with CodeNarc report redesign. This is
> our new scheme: http://goo.gl/e9Fo2
> 
> Looks great.
> 
> -- 
> Hamlet D'Arcy
> ham...@gm...
> 
> 
------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data 
in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT 
data 
> generated by your applications, servers and devices whether physical, 
virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user

> ForwardSourceID:NT0010415E 

Re: [Codenarc-user] new report format (css/formatting)

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

Thanks everyone for the help with CodeNarc report redesign. This is
our new scheme: http://goo.gl/e9Fo2

Looks great.

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

Re: [Codenarc-user] new report format (css/formatting)

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

I would like to add that an important requirement, at least in the 
basic/default HTML report, is that it be a single standalone file. 

If we come up with anything that requires pulling in additional files, we 
should create a separate HTML ReportWriter.

Chris



"Hamlet D'Arcy" <ham...@gm...> 
02/25/2011 05:02 AM


To
Cod...@li...
cc

Subject
Re: [Codenarc-user] new report format (css/formatting)






Hi all,

I've had a few people ask about how to help with the CSS. You can do
anything you want... CSS, Javascript... just please no Flash. It needs
to be simple enought to run everywhere.

The report is generated by HtmlReportWriter and tested by
HtmlReportWriterTest. If you need to add class names and more divs (or
remove divs) then that is the class to change. If you change the
structure and add class names, then please keep track of what you do
so it is easier for us to code it.

Thanks,


On Thu, Feb 24, 2011 at 9:47 PM, Hamlet D'Arcy <ham...@gm...> 
wrote:
> Hi all,
>
> I am sending this to the user list in hopes that some css guru can
> offer some help.
>
> I committed a first draft at restyling the CodeNarc reports:
> 
http://codenarc.svn.sourceforge.net/viewvc/codenarc/trunk/src/test/groovy/org/codenarc/report/data/HtmlReportWriterTest.testWriteReport.html?revision=610

>
> You can't please everyone, but I think it is an improvements. We need
> to get the Logo on there somehow, but that shouldn't be too hard to
> embed in the CSS.
>
> So... this looks nice in Chrome... less so in Firefox.
>
> Does anyone feel like hacking some css and making this better?
>
> --
> Hamlet D'Arcy
> ham...@gm...
>



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

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

ForwardSourceID:NT00104006 

Re: [Codenarc-user] new report format (css/formatting)

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

Hi all,

I've had a few people ask about how to help with the CSS. You can do
anything you want... CSS, Javascript... just please no Flash. It needs
to be simple enought to run everywhere.

The report is generated by HtmlReportWriter and tested by
HtmlReportWriterTest. If you need to add class names and more divs (or
remove divs) then that is the class to change. If you change the
structure and add class names, then please keep track of what you do
so it is easier for us to code it.

Thanks,


On Thu, Feb 24, 2011 at 9:47 PM, Hamlet D'Arcy <ham...@gm...> wrote:
> Hi all,
>
> I am sending this to the user list in hopes that some css guru can
> offer some help.
>
> I committed a first draft at restyling the CodeNarc reports:
> http://codenarc.svn.sourceforge.net/viewvc/codenarc/trunk/src/test/groovy/org/codenarc/report/data/HtmlReportWriterTest.testWriteReport.html?revision=610
>
> You can't please everyone, but I think it is an improvements. We need
> to get the Logo on there somehow, but that shouldn't be too hard to
> embed in the CSS.
>
> So... this looks nice in Chrome... less so in Firefox.
>
> Does anyone feel like hacking some css and making this better?
>
> --
> Hamlet D'Arcy
> ham...@gm...
>



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

[Codenarc-user] new report format (css/formatting)

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

Hi all,

I am sending this to the user list in hopes that some css guru can
offer some help.

I committed a first draft at restyling the CodeNarc reports:
http://codenarc.svn.sourceforge.net/viewvc/codenarc/trunk/src/test/groovy/org/codenarc/report/data/HtmlReportWriterTest.testWriteReport.html?revision=610

You can't please everyone, but I think it is an improvements. We need
to get the Logo on there somehow, but that shouldn't be too hard to
embed in the CSS.

So... this looks nice in Chrome... less so in Firefox.

Does anyone feel like hacking some css and making this better?

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

Re: [Codenarc-user] [Codenarc-developer] gradle + codenarc

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

Thanks for the heads-up Hamlet.

I am waiting for my subscription request to us...@gr... list to
be accepted/confirmed so that I can reply.

(1) It looks like the problem is this code in RuleSetUtil for loading a rule
script file:

        def inputStream = resourceFactory.getResource(path).inputStream
        Class ruleClass
        inputStream.withStream { input ->
            GroovyClassLoader gcl = new GroovyClassLoader()
            ruleClass = gcl.parseClass(input)
        }

I expect that the new GroovyClassLoader() should probably instead be:
	new GroovyClassLoader(this.class.classLoader())

That may explain not being able to compile the rule script file.

(2) The file:xxx URL to the rule script file can also be a relative path (to
the current dir). So I was gonna suggest trying:

	rule('file:config/codenarc/MyCustomRuleScript.groovy') 

instead of:

	def ruleScript = new
File('config/codenarc/MyCustomRuleScript.groovy') 
	rule('file:' + ruleScript.canonicalPath) 


Let me know if you think I am off base on either of these.

Unfortunately, Nabble is blocked at my work (don't get me started about our
$%#@^ firewall policy), so it will be another half-day or so until I can
reply.

Thanks.
Chris

-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Tuesday, February 22, 2011 2:13 PM
To: cod...@li...;
cod...@li...
Subject: [Codenarc-developer] gradle + codenarc

Does anyone want to comment on this thread: 
http://gradle.1045684.n5.nabble.com/code-quality-plugin-location-of-custom-c
odenarc-rule-td3373768.html

A user is having trouble including their own custom rule. 

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


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

[Codenarc-user] gradle + codenarc

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

Does anyone want to comment on this thread: 
http://gradle.1045684.n5.nabble.com/code-quality-plugin-location-of-custom-codenarc-rule-td3373768.html

A user is having trouble including their own custom rule. 

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

[Codenarc-user] CodeNarc/GMetrics in Guillaume LaForge's Groovy Ecosystem slides

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

CodeNarc makes an appearance in Guillaume's Groovy Ecosystem slides.

His tweet: "My #jfokus presentation on the #groovy ecosystem
http://slidesha.re/hHB5ER (#gradle #spock #grails #gpars #codenarc
#gaelyk #easyb...)"

See slides 45-50: http://slidesha.re/hHB5ER

This is great news, and thanks everyone who provided feedback and help
over the last few years. We've finally made it to the big time!

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

[Codenarc-user] what if CodeNarc had achievements?

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

Has anyone seen this post? 
http://blog.whiletrue.com/2011/01/what-if-visual-studio-had-achievements/

It might be fun to try and work achievements into CodeNarc :) 

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

Re: [Codenarc-user] new GMetrics rule about software stability?

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

>> I am excited about the momentum we have with CodeNarc

Yes, me too. It was my "intent" to do that after we released CodeNarc 
v0.11, but then 0.12 ramped up (and you added a bunch more rules :->), and 
then I said to myself, "ok, I'll do it after the next release".  These are 
good problems to have. I am not complaining.

Hamlet DArcy <ham...@ca...> wrote on 01/25/2011 07:55:47 AM:

> > Are you thinking that a heuristic would be based on relative
> > comparison? Perhaps # commits versus average or beyond one standard
> > deviation -- 
> 
> Does Sonar do anything like this? Perhaps we are reinventing the wheel. 
> To start, it would be good to list the absolute numbers sorted 
> highest to lowest. 
> Then you might want to list the # of commits per day per file sorted
> highest to lowest. 
> After that maybe start looking at standard deviation stuff. 
> 
> > BTW, My intent was to switch back to working on GMetrics for a while
> > and give that some attention. 
> 
> It's your decision. I am excited about the momentum we have with 
> CodeNarc, especially to see that Cedric created an IntelliJ IDEA 
> plugin. In my opinion, adoption will come once we have a ton of 
> rules. There is plenty of low hanging fruit left to pick (ie. easy 
> rules to implement). I'm going to stick with more CodeNarc rules for 
now. 
> 
> > Sigh. Never enough hours in the day...
> 
> There are plenty of hours, we just have day jobs :( 
> 
> --
> Hamlet D'Arcy
> ham...@ca...
> 
> ----- Original Message -----
> > That is quite interesting. I agree that could be a valuable metric.
> > And GMetrics does seem like a reasonable place to put it.
> > 
> > Are you thinking that a heuristic would be based on relative
> > comparison? Perhaps # commits versus average or beyond one standard
> > deviation -- figure out a good way to determine "outliers" on the high
> > side.
> > 
> > BTW, My intent was to switch back to working on GMetrics for a while
> > and give that some attention. There is a long to-do list for that
> > project as well. Sigh. Never enough hours in the day...
> > 
> > Chris
> > 
> > Hamlet DArcy <ham...@ca...> wrote on 01/25/2011 03:20:02 AM:
> > 
> > > Hi all,
> > >
> > > I ran across an interesting blog post this morning from Michael
> > > Feathers:
> > > http://michaelfeathers.typepad.
> > > com/michael_feathers_blog/2011/01/measuring-the-closure-of-code.html
> > >
> > > As a measure of risk, he graphed the number of version control
> > > commits against each file in the codebase. A file at revision 3 is
> > > less risky than a file at revision 300. The file at revision 300 is
> > > a code smell because all changes filter through that file.
> > >
> > > I have long wanted to see metrics on this version control revision
> > > number. A high number shows unstable code that, at a minimum, needs
> > > extensive test coverage, and possibly refactoring.
> > >
> > > Do you think GMetrics is the place for this code? Could we produce
> > > some sort of report showing the risk areas of a project based on
> > > revision number? And could you define heuristics for a CodeNarc rule
> > > based on this info?
> > >
> > > Or perhaps a different open source project is a better fit for this
> > > functionality.
> > >
> > > --
> > > Hamlet D'Arcy
> > > ham...@ca...
> > >
> > >
> > > 
> 
------------------------------------------------------------------------------
> > > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > > Finally, a world-class log management solution at an even better
> > > price-free!
> > > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > > February 28th, so secure your free ArcSight Logger TODAY!
> > > http://p.sf.net/sfu/arcsight-sfd2d
> > > _______________________________________________
> > > Codenarc-user mailing list
> > > Cod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/codenarc-user
> > 
> > > ForwardSourceID:NT000F9C52

> ForwardSourceID:NT000F9CEA 

Re: [Codenarc-user] new GMetrics rule about software stability?

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

> Are you thinking that a heuristic would be based on relative
> comparison? Perhaps # commits versus average or beyond one standard
> deviation -- 

Does Sonar do anything like this? Perhaps we are reinventing the wheel. 
To start, it would be good to list the absolute numbers sorted highest to lowest. 
Then you might want to list the # of commits per day per file sorted highest to lowest. 
After that maybe start looking at standard deviation stuff. 

> BTW, My intent was to switch back to working on GMetrics for a while
> and give that some attention. 

It's your decision. I am excited about the momentum we have with CodeNarc, especially to see that Cedric created an IntelliJ IDEA plugin. In my opinion, adoption will come once we have a ton of rules. There is plenty of low hanging fruit left to pick (ie. easy rules to implement). I'm going to stick with more CodeNarc rules for now. 

> Sigh. Never enough hours in the day...

There are plenty of hours, we just have day jobs :( 

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

----- Original Message -----
> That is quite interesting. I agree that could be a valuable metric.
> And GMetrics does seem like a reasonable place to put it.
> 
> Are you thinking that a heuristic would be based on relative
> comparison? Perhaps # commits versus average or beyond one standard
> deviation -- figure out a good way to determine "outliers" on the high
> side.
> 
> BTW, My intent was to switch back to working on GMetrics for a while
> and give that some attention. There is a long to-do list for that
> project as well. Sigh. Never enough hours in the day...
> 
> Chris
> 
> Hamlet DArcy <ham...@ca...> wrote on 01/25/2011 03:20:02 AM:
> 
> > Hi all,
> >
> > I ran across an interesting blog post this morning from Michael
> > Feathers:
> > http://michaelfeathers.typepad.
> > com/michael_feathers_blog/2011/01/measuring-the-closure-of-code.html
> >
> > As a measure of risk, he graphed the number of version control
> > commits against each file in the codebase. A file at revision 3 is
> > less risky than a file at revision 300. The file at revision 300 is
> > a code smell because all changes filter through that file.
> >
> > I have long wanted to see metrics on this version control revision
> > number. A high number shows unstable code that, at a minimum, needs
> > extensive test coverage, and possibly refactoring.
> >
> > Do you think GMetrics is the place for this code? Could we produce
> > some sort of report showing the risk areas of a project based on
> > revision number? And could you define heuristics for a CodeNarc rule
> > based on this info?
> >
> > Or perhaps a different open source project is a better fit for this
> > functionality.
> >
> > --
> > Hamlet D'Arcy
> > ham...@ca...
> >
> >
> > ------------------------------------------------------------------------------
> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > Finally, a world-class log management solution at an even better
> > price-free!
> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > February 28th, so secure your free ArcSight Logger TODAY!
> > http://p.sf.net/sfu/arcsight-sfd2d
> > _______________________________________________
> > Codenarc-user mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-user
> 
> > ForwardSourceID:NT000F9C52

Re: [Codenarc-user] new GMetrics rule about software stability?

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

That is quite interesting. I agree that could be a valuable metric. And 
GMetrics does seem like a reasonable place to put it.

Are you thinking that a heuristic would be based on relative comparison? 
Perhaps # commits versus average or beyond one standard deviation -- 
figure out a good way to determine "outliers" on the high side.

BTW, My intent was to switch back to working on GMetrics for a while and 
give that some attention. There is a long to-do list for that project as 
well. Sigh. Never enough hours in the day...

Chris

Hamlet DArcy <ham...@ca...> wrote on 01/25/2011 03:20:02 AM:

> Hi all, 
> 
> I ran across an interesting blog post this morning from Michael 
Feathers: 
> http://michaelfeathers.typepad.
> com/michael_feathers_blog/2011/01/measuring-the-closure-of-code.html
> 
> As a measure of risk, he graphed the number of version control 
> commits against each file in the codebase. A file at revision 3 is 
> less risky than a file at revision 300. The file at revision 300 is 
> a code smell because all changes filter through that file. 
> 
> I have long wanted to see metrics on this version control revision 
> number. A high number shows unstable code that, at a minimum, needs 
> extensive test coverage, and possibly refactoring. 
> 
> Do you think GMetrics is the place for this code? Could we produce 
> some sort of report showing the risk areas of a project based on 
> revision number? And could you define heuristics for a CodeNarc rule
> based on this info? 
> 
> Or perhaps a different open source project is a better fit for this 
> functionality. 
> 
> --
> Hamlet D'Arcy
> ham...@ca...
> 
> 
> 
------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better 
price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user

> ForwardSourceID:NT000F9C52 

[Codenarc-user] new GMetrics rule about software stability?

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

Hi all, 

I ran across an interesting blog post this morning from Michael Feathers: http://michaelfeathers.typepad.com/michael_feathers_blog/2011/01/measuring-the-closure-of-code.html

As a measure of risk, he graphed the number of version control commits against each file in the codebase. A file at revision 3 is less risky than a file at revision 300. The file at revision 300 is a code smell because all changes filter through that file. 

I have long wanted to see metrics on this version control revision number. A high number shows unstable code that, at a minimum, needs extensive test coverage, and possibly refactoring. 

Do you think GMetrics is the place for this code? Could we produce some sort of report showing the risk areas of a project based on revision number? And could you define heuristics for a CodeNarc rule based on this info? 

Or perhaps a different open source project is a better fit for this functionality. 

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

Re: [Codenarc-user] CodeNarc rulesets - even necessary?

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

But even using Gradle/Grails/Griffon plugins, you often still need to 
assemble a custom ruleset.

I may still explore options such as @Rule and configuring a custom ruleset 
without needing to reference those individual predefined rulesets. I think 
that could be done without harming backwards-compatibility.

Chris

Hamlet DArcy <ham...@ca...> wrote on 01/24/2011 03:23:00 AM:

> To me, the future lies in tools like the Grails, Griffon, Gradle, 
> and IDEA plugins. There are few questions (so far) about how to use 
> CodeNarc with these tools because the plugins take care of it for you. 
> 
> I wouldn't make any changes now because of backwards compatibility. 
> 
> --
> Hamlet D'Arcy
> ham...@ca...
> 
> ----- Original Message -----
> > Okay, to continue the discussion about the necessity of rulesets...
> > 
> > 
> > 
> > >> But why even have rulesets? ...
> > 
> > 
> > 
> > In general, I agree with you. Although we have done a little bit of
> > mix-and-match of picking rulesets at my work (e.g. pulling in the
> > Grails rules only for Grails projects), overall that has probably not
> > been worth the effort and complexity of maintaining those separate
> > rulesets.
> > 
> > 
> > 
> > But I would add that having something like the "Basic" ruleset is
> > valuable -- here are a "minimal" set of rules that pretty much
> > everyone can agree on. This is often the way to wade into using a tool
> > like CodeNarc. (Though I admittedly let the "basic" ruleset drift away
> > from that core mission a bit)
> > 
> > 
> > 
> > At this point, for backward-compatibility, I don' think we could just
> > remove the existing rulesets.
> > 
> > 
> > 
> > That all being said, I do think there is definitely room for
> > reorganization, improvement and innovation.
> > 
> > 
> > 
> > We could create one "All-Rules" ruleset. The Groovy Ruleset DSL could
> > be used as-is, but we’d have to figure out some scheme to NOT
> > automatically include all the rules in the ruleset by default, as it
> > does today, e.g.
> > 
> > 
> > 
> > ruleset {
> > 
> > ruleset('rulesets/all-codenarc-rules.xml', excludeByDefault:true ) {
> > 
> > CatchThrowable(priority:1) // only include explicitly-configured rules
> > 
> > EqualsAndHashCode(priority:3)
> > 
> > ThrowExceptionFromFinallyBlock()
> > 
> > UnnecessaryConstructor()
> > 
> > }
> > 
> > }
> > 
> > 
> > 
> > Another option along these lines is to automatically retain a
> > "registry" of all rules, indexed by name. Perhaps we could introduce a
> > @Rule (or somesuch) annotation for the rule implementations. I had
> > considered that from the beginning, but back then I needed to maintain
> > compatibility with Java 1.4 (don't get me started), so I could not
> > support annotations. I think it would then be possible to extend the
> > Groovy Ruleset DSL to automatically look into this registry for rule
> > names, so, there would be no need to specify an explicit ruleset file,
> > e.g.
> > 
> > 
> > 
> > ruleset {
> > 
> > CatchThrowable(priority:1)
> > 
> > EqualsAndHashCode(priority:3)
> > 
> > MethodCount {
> > 
> > doNotApplyToClassNames = ‘*Test, *TestCase’
> > 
> > }
> > 
> > UnnecessaryConstructor()
> > 
> > }
> > 
> > 
> > 
> > That seems quite nice and usable from my perspective.
> > 
> > 
> > 
> > 
> > 
> > >> One idea I had for simplification was to provide a "CodeNarc
> > >> Configuration Console"...
> > 
> > 
> > 
> > That sounds pretty cool.
> > 
> > 
> > 
> > Chris
> > 
> > -----Original Message-----
> > From: Hamlet DArcy [mailto:ham...@ca...]
> > Sent: Friday, January 21, 2011 9:31 AM
> > To: chris mair
> > Cc: cod...@li...; Jason Stell
> > Subject: Re: [Codenarc-user] Ruleset Resources Namespace Conflict
> > 
> > 
> > 
> > This is getting off topic from Jason's email...
> > 
> > 
> > 
> > But why even have rulesets? You can't actually make a decision based
> > on rulesets. You never say "you know, I want the concurrency ruleset
> > but not the exception ruleset". You would always look inside the set
> > and make decisions about individual rules. In my mind, I'd rather see
> > two and only two rulesets: CodeNarc rules and user rules.
> > 
> > 
> > 
> > One idea I had for simplification was to provide a "CodeNarc
> > Configuration Console". It would read the ruleset.xml files and
> > produce a tree view UI based on the rule classes, the declared
> > parameters, and the documentation. Then the user could just click
> > checkboxes and text fields until they had the configuration they
> > wanted and export the correct codenarc-properties.groovy file. The
> > model would be the IntelliJ IDEA Inspections UI. It's a bit of work
> > but nothing too challenging. A Gaelyk app would be cool. Can't we talk
> > someone from Gaelyk into doing this? I wonder what rentacoder.com
> > would charge.
> > 
> > 
> > 
> > 
> > 
> > --
> > 
> > Hamlet D'Arcy
> > 
> > ham...@ca...
> > 
> > 
> > 
> > ----- Original Message -----
> > 
> > > Yes, in hindsight, I should have put the ruleset files in a unique
> > 
> > > namespace, and as Hamlet suggested, avoiding specific rulesets
> > 
> > > altogether might have been a better approach.
> > 
> > >
> > 
> > > Is there anything forcing you to use the same classpath for both
> > 
> > > CodeNarc and PMD?
> > 
> > >
> > 
> > > I don't think we can, at this point, move the CodeNarc ruleset
> > > files,
> > 
> > > since that would break every user. Copying the ruleset files to a
> > 
> > > different location may help as a workaround, but I don't think that
> > 
> > > would solve the problem if the CodeNarc files are "hiding" the
> > 
> > > CodeNarc ones.
> > 
> > >
> > 
> > > Chris
> > 
> > >
> > 
> > >
> > 
> > > Hamlet DArcy < ham...@ca... >
> > 
> > >
> > 
> > > 01/21/2011 09:05 AM
> > 
> > >
> > 
> > > To Jason Stell < js...@gm... >
> > 
> > >
> > 
> > > cc cod...@li...
> > 
> > >
> > 
> > > Subject Re: [Codenarc-user] Ruleset Resources Namespace Conflict
> > 
> > >
> > 
> > >
> > 
> > >
> > 
> > >
> > 
> > > CodeNarc is modeled on PMD so we have all those ruleset files in
> > 
> > > common. Personally, I find both projects a little difficult to
> > 
> > > configure. I'd prefer to see one massive configuration file. But
> > 
> > > that's water under the bridge at this point. As you know, there is
> > 
> > > nothing special about that location. You /can/ copy all the contents
> > 
> > > of the ruleset xml files and dump them into one big file.
> > 
> > >
> > 
> > > --
> > 
> > > Hamlet D'Arcy
> > 
> > > ham...@ca...
> > 
> > >
> > 
> > > ----- Original Message -----
> > 
> > > > It does kinda stink ;) I would have suggested a change to PMD
> > 
> > > > resource names, as well, but that project has been around a long
> > 
> > > > time and a change would probably impact many more users (still, as
> > > > a
> > 
> > > > good practice, they should also think about putting resources in
> > > > an
> > 
> > > > appropriate namespace).
> > 
> > > >
> > 
> > > >
> > 
> > > > As a workaround I can always extract/copy the rulesets I'm using
> > > > and
> > 
> > > > put them in a different local namespace.
> > 
> > > >
> > 
> > > >
> > 
> > > > Oh - and thanks for CodeNarc!
> > 
> > > >
> > 
> > > >
> > 
> > > > Regards
> > 
> > > > Jason
> > 
> > > >
> > 
> > > >
> > 
> > > > On Fri, Jan 21, 2011 at 1:30 AM, Hamlet DArcy <
> > 
> > > > ham...@ca...
> > 
> > > > > wrote:
> > 
> > > >
> > 
> > > >
> > 
> > > >
> > 
> > > > > If I have both CodeNarc and PMD libs in my classpath, I have
> > 
> > > > > problems
> > 
> > > >
> > 
> > > > Well that stinks. If we rename the rules then we have backwards
> > 
> > > > compatibility issues. :( We'll have to discuss what to do.
> > 
> > > >
> > 
> > > > Do you need a workaround temporarily? Or do you have that covered?
> > 
> > > >
> > 
> > > >
> > 
> > > > --
> > 
> > > > Hamlet D'Arcy
> > 
> > > > ham...@ca...
> > 
> > > >
> > 
> > > >
> > 
> > > >
> > 
> > > >
> > 
> > > > ----- Original Message -----
> > 
> > > > > If I have both CodeNarc and PMD libs in my classpath, I have
> > 
> > > > > problems with one or the other, because both have resources with
> > 
> > > > > the same
> > 
> > > > > name:
> > 
> > > > > e.g., 'rulesets/basic.xml', 'rulesets/design.xml', etc. How
> > > > > about
> > 
> > > > > using a safer resource namespace, like
> > 
> > > > > 'org/codenarc/rulesets/...'?
> > 
> > > > >
> > 
> > > > >
> > 
> > > > > Thanks!
> > 
> > > > > Jason
> > 
> > > > > 
------------------------------------------------------------------
> > 
> > > > > ------------ Special Offer-- Download ArcSight Logger for FREE
> > > > > (a
> > 
> > > > > $49 USD value)!
> > 
> > > > > Finally, a world-class log management solution at an even better
> > 
> > > > > price-free!
> > 
> > > > > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > 
> > > > > February 28th, so secure your free ArcSight Logger TODAY!
> > 
> > > > > http://p.sf.net/sfu/arcsight-sfd2d
> > 
> > > > > _______________________________________________
> > 
> > > > > Codenarc-user mailing list
> > 
> > > > > Cod...@li...
> > 
> > > > > https://lists.sourceforge.net/lists/listinfo/codenarc-user
> > 
> > >
> > 
> > > 
----------------------------------------------------------------------
> > 
> > > -------- Special Offer-- Download ArcSight Logger for FREE (a $49
> > > USD
> > 
> > > value)!
> > 
> > > Finally, a world-class log management solution at an even better
> > 
> > > price-free!
> > 
> > > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > 
> > > February 28th, so secure your free ArcSight Logger TODAY!
> > 
> > > http://p.sf.net/sfu/arcsight-sfd2d
> > 
> > > _______________________________________________
> > 
> > > Codenarc-user mailing list
> > 
> > > Cod...@li...
> > 
> > > https://lists.sourceforge.net/lists/listinfo/codenarc-user
> > 
> > >
> > 
> > > ForwardSourceID:NT000F67C6
> > 
> > 
> > 
> > 
> 
------------------------------------------------------------------------------
> > 
> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > 
> > Finally, a world-class log management solution at an even better
> > price-free!
> > 
> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > February 28th, so secure your free ArcSight Logger TODAY!
> > 
> > http://p.sf.net/sfu/arcsight-sfd2d
> > 
> > _______________________________________________
> > 
> > Codenarc-user mailing list
> > 
> > Cod...@li...
> > 
> > https://lists.sourceforge.net/lists/listinfo/codenarc-user
> 
> 
------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better 
price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user

> ForwardSourceID:NT000F9A3A 

Re: [Codenarc-user] CodeNarc rulesets - even necessary?

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

To me, the future lies in tools like the Grails, Griffon, Gradle, and IDEA plugins. There are few questions (so far) about how to use CodeNarc with these tools because the plugins take care of it for you. 

I wouldn't make any changes now because of backwards compatibility. 

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

----- Original Message -----
> Okay, to continue the discussion about the necessity of rulesets...
> 
> 
> 
> >> But why even have rulesets? ...
> 
> 
> 
> In general, I agree with you. Although we have done a little bit of
> mix-and-match of picking rulesets at my work (e.g. pulling in the
> Grails rules only for Grails projects), overall that has probably not
> been worth the effort and complexity of maintaining those separate
> rulesets.
> 
> 
> 
> But I would add that having something like the "Basic" ruleset is
> valuable -- here are a "minimal" set of rules that pretty much
> everyone can agree on. This is often the way to wade into using a tool
> like CodeNarc. (Though I admittedly let the "basic" ruleset drift away
> from that core mission a bit)
> 
> 
> 
> At this point, for backward-compatibility, I don' think we could just
> remove the existing rulesets.
> 
> 
> 
> That all being said, I do think there is definitely room for
> reorganization, improvement and innovation.
> 
> 
> 
> We could create one "All-Rules" ruleset. The Groovy Ruleset DSL could
> be used as-is, but we’d have to figure out some scheme to NOT
> automatically include all the rules in the ruleset by default, as it
> does today, e.g.
> 
> 
> 
> ruleset {
> 
> ruleset('rulesets/all-codenarc-rules.xml', excludeByDefault:true ) {
> 
> CatchThrowable(priority:1) // only include explicitly-configured rules
> 
> EqualsAndHashCode(priority:3)
> 
> ThrowExceptionFromFinallyBlock()
> 
> UnnecessaryConstructor()
> 
> }
> 
> }
> 
> 
> 
> Another option along these lines is to automatically retain a
> "registry" of all rules, indexed by name. Perhaps we could introduce a
> @Rule (or somesuch) annotation for the rule implementations. I had
> considered that from the beginning, but back then I needed to maintain
> compatibility with Java 1.4 (don't get me started), so I could not
> support annotations. I think it would then be possible to extend the
> Groovy Ruleset DSL to automatically look into this registry for rule
> names, so, there would be no need to specify an explicit ruleset file,
> e.g.
> 
> 
> 
> ruleset {
> 
> CatchThrowable(priority:1)
> 
> EqualsAndHashCode(priority:3)
> 
> MethodCount {
> 
> doNotApplyToClassNames = ‘*Test, *TestCase’
> 
> }
> 
> UnnecessaryConstructor()
> 
> }
> 
> 
> 
> That seems quite nice and usable from my perspective.
> 
> 
> 
> 
> 
> >> One idea I had for simplification was to provide a "CodeNarc
> >> Configuration Console"...
> 
> 
> 
> That sounds pretty cool.
> 
> 
> 
> Chris
> 
> -----Original Message-----
> From: Hamlet DArcy [mailto:ham...@ca...]
> Sent: Friday, January 21, 2011 9:31 AM
> To: chris mair
> Cc: cod...@li...; Jason Stell
> Subject: Re: [Codenarc-user] Ruleset Resources Namespace Conflict
> 
> 
> 
> This is getting off topic from Jason's email...
> 
> 
> 
> But why even have rulesets? You can't actually make a decision based
> on rulesets. You never say "you know, I want the concurrency ruleset
> but not the exception ruleset". You would always look inside the set
> and make decisions about individual rules. In my mind, I'd rather see
> two and only two rulesets: CodeNarc rules and user rules.
> 
> 
> 
> One idea I had for simplification was to provide a "CodeNarc
> Configuration Console". It would read the ruleset.xml files and
> produce a tree view UI based on the rule classes, the declared
> parameters, and the documentation. Then the user could just click
> checkboxes and text fields until they had the configuration they
> wanted and export the correct codenarc-properties.groovy file. The
> model would be the IntelliJ IDEA Inspections UI. It's a bit of work
> but nothing too challenging. A Gaelyk app would be cool. Can't we talk
> someone from Gaelyk into doing this? I wonder what rentacoder.com
> would charge.
> 
> 
> 
> 
> 
> --
> 
> Hamlet D'Arcy
> 
> ham...@ca...
> 
> 
> 
> ----- Original Message -----
> 
> > Yes, in hindsight, I should have put the ruleset files in a unique
> 
> > namespace, and as Hamlet suggested, avoiding specific rulesets
> 
> > altogether might have been a better approach.
> 
> >
> 
> > Is there anything forcing you to use the same classpath for both
> 
> > CodeNarc and PMD?
> 
> >
> 
> > I don't think we can, at this point, move the CodeNarc ruleset
> > files,
> 
> > since that would break every user. Copying the ruleset files to a
> 
> > different location may help as a workaround, but I don't think that
> 
> > would solve the problem if the CodeNarc files are "hiding" the
> 
> > CodeNarc ones.
> 
> >
> 
> > Chris
> 
> >
> 
> >
> 
> > Hamlet DArcy < ham...@ca... >
> 
> >
> 
> > 01/21/2011 09:05 AM
> 
> >
> 
> > To Jason Stell < js...@gm... >
> 
> >
> 
> > cc cod...@li...
> 
> >
> 
> > Subject Re: [Codenarc-user] Ruleset Resources Namespace Conflict
> 
> >
> 
> >
> 
> >
> 
> >
> 
> > CodeNarc is modeled on PMD so we have all those ruleset files in
> 
> > common. Personally, I find both projects a little difficult to
> 
> > configure. I'd prefer to see one massive configuration file. But
> 
> > that's water under the bridge at this point. As you know, there is
> 
> > nothing special about that location. You /can/ copy all the contents
> 
> > of the ruleset xml files and dump them into one big file.
> 
> >
> 
> > --
> 
> > Hamlet D'Arcy
> 
> > ham...@ca...
> 
> >
> 
> > ----- Original Message -----
> 
> > > It does kinda stink ;) I would have suggested a change to PMD
> 
> > > resource names, as well, but that project has been around a long
> 
> > > time and a change would probably impact many more users (still, as
> > > a
> 
> > > good practice, they should also think about putting resources in
> > > an
> 
> > > appropriate namespace).
> 
> > >
> 
> > >
> 
> > > As a workaround I can always extract/copy the rulesets I'm using
> > > and
> 
> > > put them in a different local namespace.
> 
> > >
> 
> > >
> 
> > > Oh - and thanks for CodeNarc!
> 
> > >
> 
> > >
> 
> > > Regards
> 
> > > Jason
> 
> > >
> 
> > >
> 
> > > On Fri, Jan 21, 2011 at 1:30 AM, Hamlet DArcy <
> 
> > > ham...@ca...
> 
> > > > wrote:
> 
> > >
> 
> > >
> 
> > >
> 
> > > > If I have both CodeNarc and PMD libs in my classpath, I have
> 
> > > > problems
> 
> > >
> 
> > > Well that stinks. If we rename the rules then we have backwards
> 
> > > compatibility issues. :( We'll have to discuss what to do.
> 
> > >
> 
> > > Do you need a workaround temporarily? Or do you have that covered?
> 
> > >
> 
> > >
> 
> > > --
> 
> > > Hamlet D'Arcy
> 
> > > ham...@ca...
> 
> > >
> 
> > >
> 
> > >
> 
> > >
> 
> > > ----- Original Message -----
> 
> > > > If I have both CodeNarc and PMD libs in my classpath, I have
> 
> > > > problems with one or the other, because both have resources with
> 
> > > > the same
> 
> > > > name:
> 
> > > > e.g., 'rulesets/basic.xml', 'rulesets/design.xml', etc. How
> > > > about
> 
> > > > using a safer resource namespace, like
> 
> > > > 'org/codenarc/rulesets/...'?
> 
> > > >
> 
> > > >
> 
> > > > Thanks!
> 
> > > > Jason
> 
> > > > ------------------------------------------------------------------
> 
> > > > ------------ Special Offer-- Download ArcSight Logger for FREE
> > > > (a
> 
> > > > $49 USD value)!
> 
> > > > Finally, a world-class log management solution at an even better
> 
> > > > price-free!
> 
> > > > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> 
> > > > February 28th, so secure your free ArcSight Logger TODAY!
> 
> > > > http://p.sf.net/sfu/arcsight-sfd2d
> 
> > > > _______________________________________________
> 
> > > > Codenarc-user mailing list
> 
> > > > Cod...@li...
> 
> > > > https://lists.sourceforge.net/lists/listinfo/codenarc-user
> 
> >
> 
> > ----------------------------------------------------------------------
> 
> > -------- Special Offer-- Download ArcSight Logger for FREE (a $49
> > USD
> 
> > value)!
> 
> > Finally, a world-class log management solution at an even better
> 
> > price-free!
> 
> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> 
> > February 28th, so secure your free ArcSight Logger TODAY!
> 
> > http://p.sf.net/sfu/arcsight-sfd2d
> 
> > _______________________________________________
> 
> > Codenarc-user mailing list
> 
> > Cod...@li...
> 
> > https://lists.sourceforge.net/lists/listinfo/codenarc-user
> 
> >
> 
> > ForwardSourceID:NT000F67C6
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> 
> Finally, a world-class log management solution at an even better
> price-free!
> 
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> 
> http://p.sf.net/sfu/arcsight-sfd2d
> 
> _______________________________________________
> 
> Codenarc-user mailing list
> 
> Cod...@li...
> 
> https://lists.sourceforge.net/lists/listinfo/codenarc-user

[Codenarc-user] CodeNarc rulesets - even necessary?

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

Okay, to continue the discussion about the necessity of rulesets...

 

>> But why even have rulesets? ...

 

In general, I agree with you. Although we have done a little bit of
mix-and-match of picking rulesets at my work (e.g. pulling in the Grails
rules only for Grails projects), overall that has probably not been worth
the effort and complexity of maintaining those separate rulesets. 

 

But I would add that having something like the "Basic" ruleset is valuable
-- here are a "minimal" set of rules that pretty much everyone can agree on.
This is often the way to wade into using a tool like CodeNarc. (Though I
admittedly let the "basic" ruleset drift away from that core mission a bit)

 

At this point, for backward-compatibility, I don' think we could just remove
the existing rulesets.

 

That all being said, I do think there is definitely room for reorganization,
improvement and innovation. 

 

We could create one "All-Rules" ruleset.  The Groovy Ruleset DSL could be
used as-is, but we'd have to figure out some scheme to NOT automatically
include all the rules in the ruleset by default, as it does today, e.g.

 

ruleset {

    ruleset('rulesets/all-codenarc-rules.xml', excludeByDefault:true) {

        CatchThrowable(priority:1)                 // only include
explicitly-configured rules

        EqualsAndHashCode(priority:3)

        ThrowExceptionFromFinallyBlock()

        UnnecessaryConstructor()

    }

}

 

Another option along these lines is to automatically retain a "registry" of
all rules, indexed by name. Perhaps we could introduce a @Rule (or somesuch)
annotation for the rule implementations. I had considered that from the
beginning, but back then I needed to maintain compatibility with Java 1.4
(don't get me started), so I could not support annotations.  I think it
would then be possible to extend the Groovy Ruleset DSL to automatically
look into this registry for rule names, so, there would be no need to
specify an explicit ruleset file, e.g.

 

ruleset {

        CatchThrowable(priority:1)

        EqualsAndHashCode(priority:3)

        MethodCount {

                doNotApplyToClassNames = '*Test, *TestCase'

        }

        UnnecessaryConstructor()

}

 

That seems quite nice and usable from my perspective.

 

 

>> One idea I had for simplification was to provide a "CodeNarc
Configuration Console"...

 

That sounds pretty cool.

 

Chris

-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Friday, January 21, 2011 9:31 AM
To: chris mair
Cc: cod...@li...; Jason Stell
Subject: Re: [Codenarc-user] Ruleset Resources Namespace Conflict

 

This is getting off topic from Jason's email... 

 

But why even have rulesets? You can't actually make a decision based on
rulesets. You never say "you know, I want the concurrency ruleset but not
the exception ruleset". You would always look inside the set and make
decisions about individual rules. In my mind, I'd rather see two and only
two rulesets: CodeNarc rules and user rules. 

 

One idea I had for simplification was to provide a "CodeNarc Configuration
Console". It would read the ruleset.xml files and produce a tree view UI
based on the rule classes, the declared parameters, and the documentation.
Then the user could just click checkboxes and text fields until they had the
configuration they wanted and export the correct codenarc-properties.groovy
file. The model would be the IntelliJ IDEA Inspections UI. It's a bit of
work but nothing too challenging. A Gaelyk app would be cool. Can't we talk
someone from Gaelyk into doing this? I wonder what rentacoder.com would
charge. 

 

 

--

Hamlet D'Arcy

 <mailto:ham...@ca...> ham...@ca...

 

----- Original Message -----

> Yes, in hindsight, I should have put the ruleset files in a unique 

> namespace, and as Hamlet suggested, avoiding specific rulesets 

> altogether might have been a better approach.

> 

> Is there anything forcing you to use the same classpath for both 

> CodeNarc and PMD?

> 

> I don't think we can, at this point, move the CodeNarc ruleset files, 

> since that would break every user. Copying the ruleset files to a 

> different location may help as a workaround, but I don't think that 

> would solve the problem if the CodeNarc files are "hiding" the 

> CodeNarc ones.

> 

> Chris

> 

> 

> Hamlet DArcy < <mailto:ham...@ca...> ham...@ca...>

> 

> 01/21/2011 09:05 AM

> 

> To Jason Stell < <mailto:js...@gm...> js...@gm...>

> 

> cc  <mailto:cod...@li...>
cod...@li...

> 

> Subject Re: [Codenarc-user] Ruleset Resources Namespace Conflict

> 

> 

> 

> 

> CodeNarc is modeled on PMD so we have all those ruleset files in 

> common. Personally, I find both projects a little difficult to 

> configure. I'd prefer to see one massive configuration file. But 

> that's water under the bridge at this point. As you know, there is 

> nothing special about that location. You /can/ copy all the contents 

> of the ruleset xml files and dump them into one big file.

> 

> --

> Hamlet D'Arcy

>  <mailto:ham...@ca...> ham...@ca...

> 

> ----- Original Message -----

> > It does kinda stink ;) I would have suggested a change to PMD 

> > resource names, as well, but that project has been around a long 

> > time and a change would probably impact many more users (still, as a 

> > good practice, they should also think about putting resources in an 

> > appropriate namespace).

> >

> >

> > As a workaround I can always extract/copy the rulesets I'm using and 

> > put them in a different local namespace.

> >

> >

> > Oh - and thanks for CodeNarc!

> >

> >

> > Regards

> > Jason

> >

> >

> > On Fri, Jan 21, 2011 at 1:30 AM, Hamlet DArcy < 

> >  <mailto:ham...@ca...> ham...@ca...

> > > wrote:

> >

> >

> >

> > > If I have both CodeNarc and PMD libs in my classpath, I have 

> > > problems

> >

> > Well that stinks. If we rename the rules then we have backwards 

> > compatibility issues. :( We'll have to discuss what to do.

> >

> > Do you need a workaround temporarily? Or do you have that covered?

> >

> >

> > --

> > Hamlet D'Arcy

> >  <mailto:ham...@ca...> ham...@ca...

> >

> >

> >

> >

> > ----- Original Message -----

> > > If I have both CodeNarc and PMD libs in my classpath, I have 

> > > problems with one or the other, because both have resources with 

> > > the same

> > > name:

> > > e.g., 'rulesets/basic.xml', 'rulesets/design.xml', etc. How about 

> > > using a safer resource namespace, like 

> > > 'org/codenarc/rulesets/...'?

> > >

> > >

> > > Thanks!

> > > Jason

> > > ------------------------------------------------------------------

> > > ------------ Special Offer-- Download ArcSight Logger for FREE (a 

> > > $49 USD value)!

> > > Finally, a world-class log management solution at an even better 

> > > price-free!

> > > Download using promo code Free_Logger_4_Dev2Dev. Offer expires 

> > > February 28th, so secure your free ArcSight Logger TODAY!

> > >  <http://p.sf.net/sfu/arcsight-sfd2d>
http://p.sf.net/sfu/arcsight-sfd2d

> > > _______________________________________________

> > > Codenarc-user mailing list

> > >  <mailto:Cod...@li...>
Cod...@li...

> > >  <https://lists.sourceforge.net/lists/listinfo/codenarc-user>
https://lists.sourceforge.net/lists/listinfo/codenarc-user

> 

> ----------------------------------------------------------------------

> -------- Special Offer-- Download ArcSight Logger for FREE (a $49 USD 

> value)!

> Finally, a world-class log management solution at an even better 

> price-free!

> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 

> February 28th, so secure your free ArcSight Logger TODAY!

>  <http://p.sf.net/sfu/arcsight-sfd2d> http://p.sf.net/sfu/arcsight-sfd2d

> _______________________________________________

> Codenarc-user mailing list

>  <mailto:Cod...@li...>
Cod...@li...

>  <https://lists.sourceforge.net/lists/listinfo/codenarc-user>
https://lists.sourceforge.net/lists/listinfo/codenarc-user

> 

> ForwardSourceID:NT000F67C6

 

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

Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!

Finally, a world-class log management solution at an even better price-free!

Download using promo code Free_Logger_4_Dev2Dev. Offer expires February
28th, so secure your free ArcSight Logger TODAY! 

 <http://p.sf.net/sfu/arcsight-sfd2d> http://p.sf.net/sfu/arcsight-sfd2d

_______________________________________________

Codenarc-user mailing list

 <mailto:Cod...@li...>
Cod...@li...

 <https://lists.sourceforge.net/lists/listinfo/codenarc-user>
https://lists.sourceforge.net/lists/listinfo/codenarc-user

Re: [Codenarc-user] Checking out CodeNarc..

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

Jeremy,

 

Thanks for the feedback.  I included the CodeNarc User List on this reply, since these issues  might interest other users.

 

I agree that one part of addressing these issues is to improve the rule descriptions and include suggested solutions. I expect we can make some progress on that.

As for the enhanced HTML report, I am open to enhancing the existing report – if it can be done without sacrificing portability (i.e. still be a single file with no external dependencies) and universal readability (everyone with a browser). Otherwise, we could look into perhaps providing another report type, or describe or provide an XSLT transformation for the existing XML report (see the mrhaki <http://mrhaki.blogspot.com/>  blog post about creating custom CodeNarc HTML reports using XSLT <http://mrhaki.blogspot.com/2011/01/groovy-goodness-create-codenarc-reports.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mrhaki+%28Messages+from+mrhaki%29> ) , though that would lose the existing HTML markup.

Please consider opening feature requests <https://sourceforge.net/tracker/?group_id=250145&atid=1126575>  for these issues.

The online documentation on the CodeNarc  web site <http://codenarc.sourceforge.net/index.html>  has more detailed information on the rules (at least for many of them). Specifically, for that rule, it includes: “Grails controller actions and interceptors are defined as properties on the controller class. Public methods on a controller class are unnecessary. They break encapsulation and can be confusing.”

But I know that you were bringing up the larger issue of the quality and immediacy of the descriptions and help info.

Thanks.

Chris

 

From: mes...@bo... [mailto:mes...@bo...] On Behalf Of Jeremy Flowers via LinkedIn
Sent: Saturday, January 22, 2011 11:22 AM
To: Chris Mair
Subject: Checking out CodeNarc..

 



LinkedIn


Jeremy Flowers has sent you a message.

Date: 1/22/2011 

Subject: Checking out CodeNarc.. 

When you have a rule that has been violated, instead of having a link to separate table, why not have a floating text box with the more detailed description when you hover over the link. I wasn't quite sure what GrailsPublicControllerMethod was supposed to be telling me either. The detailed message : Checks for public methods on Grails controller classes. Static methods are ignored. doesn't really advise what to do instead. It's a bit to cryptic. Any chance of giving descriptions that suggest solutions? 

 <http://www.linkedin.com/e/961093-gj8q8os7-4p/bHMlR5GR33zX2M_7sdy3N7NsJa8tU1l08-Xi/mbi/I1069419969_3/> View/reply to this message

Don't want to receive e-mail notifications?  <http://www.linkedin.com/e/961093-gj8q8os7-4p/bHMlR5GR33zX2M_7sdy3N7NsJa8tU1l08-Xi/blk/I1069419969_3/s6hJbOYWrSlI/mdp/> Adjust your message settings.

© 2010, LinkedIn Corporation

 

Re: [Codenarc-user] CodeNarc plugin for IntelliJ IDEA

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

Yes, the ABC and CyclomaticComplexity rules require GMetrics 0.3.

 

From: Cédric CHAMPEAU [mailto:ced...@gm...] 
Sent: Saturday, January 22, 2011 3:33 AM
To: cod...@li...
Subject: Re: [Codenarc-user] CodeNarc plugin for IntelliJ IDEA

 

Thank you Chris. First feedback comes from myself ;) There's a rule that
doesn't run due to a missing dependency : AbcComplexityRule.

Error from [org.codenarc.rule.size.AbcComplexityRule] processing source file
[null]: org.gmetrics.metric.abc.AbcMetric
java.lang.NoClassDefFoundError: org.gmetrics.metric.abc.AbcMetric
    at
org.codenarc.rule.size.AbcComplexityAstVisitor.class$(AbcComplexityRule.groo
vy)
    at
org.codenarc.rule.size.AbcComplexityAstVisitor.$get$$class$org$gmetrics$metr
ic$abc$AbcMetric(AbcComplexityRule.groovy)
    at
org.codenarc.rule.size.AbcComplexityAstVisitor.createMetric(AbcComplexityRul
e.groovy:62)

The distribution of CodeNarc does not include this dependency. Should I add
a dependency on gmetrics ? If so, what version ?

Le 21/01/2011 20:58, chr...@wa... a écrit : 


Wonderful! Thanks very much for doing this. 

Chris 

Cédric CHAMPEAU  <mailto:ced...@gm...>
<ced...@gm...> wrote on 01/21/2011 10:14:18 AM:

> Hi,
> 
> Those who are brave enough could test the beta release of the plugin for 
> IntelliJ IDEA that I've just pushed to GitHub. Basically, it adds 
> support for CodeNarc rules as IntelliJ IDEA inspections. Those 
> inspections are available both on the fly and on demand.
> 
> Some limitations though :
>      - no support for quick fixes
>      - as CodeNarc only reports the line number, on long lines, you 
> won't know precisely where the violation is
> 
> Project home : https://github.com/melix/codenarc-idea
> Download the beta release : 
>
https://github.com/downloads/melix/codenarc-idea/CodeNarcPlugin-0.1-beta.zip
> 
> Bug reports and contributions are welcome ;)
> 
> Cédric
> 
> 
>
----------------------------------------------------------------------------
--
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user

> ForwardSourceID:NT000F6822     

 

Re: [Codenarc-user] CodeNarc plugin for IntelliJ IDEA

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

Thank you Chris. First feedback comes from myself ;) There's a rule that 
doesn't run due to a missing dependency : AbcComplexityRule.

Error from [org.codenarc.rule.size.AbcComplexityRule] processing source 
file [null]: org.gmetrics.metric.abc.AbcMetric
java.lang.NoClassDefFoundError: org.gmetrics.metric.abc.AbcMetric
     at 
org.codenarc.rule.size.AbcComplexityAstVisitor.class$(AbcComplexityRule.groovy)
     at 
org.codenarc.rule.size.AbcComplexityAstVisitor.$get$$class$org$gmetrics$metric$abc$AbcMetric(AbcComplexityRule.groovy)
     at 
org.codenarc.rule.size.AbcComplexityAstVisitor.createMetric(AbcComplexityRule.groovy:62)

The distribution of CodeNarc does not include this dependency. Should I 
add a dependency on gmetrics ? If so, what version ?

Le 21/01/2011 20:58, chr...@wa... a écrit :
>
> Wonderful! Thanks very much for doing this.
>
> Chris
>
> Cédric CHAMPEAU <ced...@gm...> wrote on 01/21/2011 
> 10:14:18 AM:
>
> > Hi,
> >
> > Those who are brave enough could test the beta release of the plugin 
> for
> > IntelliJ IDEA that I've just pushed to GitHub. Basically, it adds
> > support for CodeNarc rules as IntelliJ IDEA inspections. Those
> > inspections are available both on the fly and on demand.
> >
> > Some limitations though :
> >      - no support for quick fixes
> >      - as CodeNarc only reports the line number, on long lines, you
> > won't know precisely where the violation is
> >
> > Project home : https://github.com/melix/codenarc-idea
> > Download the beta release :
> > 
> https://github.com/downloads/melix/codenarc-idea/CodeNarcPlugin-0.1-beta.zip
> >
> > Bug reports and contributions are welcome ;)
> >
> > Cédric
> >
> >
> > 
> ------------------------------------------------------------------------------
> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > Finally, a world-class log management solution at an even better 
> price-free!
> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > February 28th, so secure your free ArcSight Logger TODAY!
> > http://p.sf.net/sfu/arcsight-sfd2d
> > _______________________________________________
> > Codenarc-user mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
> > ForwardSourceID:NT000F6822 

Re: [Codenarc-user] CodeNarc plugin for IntelliJ IDEA

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

Wonderful! Thanks very much for doing this.

Chris

Cédric CHAMPEAU <ced...@gm...> wrote on 01/21/2011 10:14:18 
AM:

> Hi,
> 
> Those who are brave enough could test the beta release of the plugin for 

> IntelliJ IDEA that I've just pushed to GitHub. Basically, it adds 
> support for CodeNarc rules as IntelliJ IDEA inspections. Those 
> inspections are available both on the fly and on demand.
> 
> Some limitations though :
>      - no support for quick fixes
>      - as CodeNarc only reports the line number, on long lines, you 
> won't know precisely where the violation is
> 
> Project home : https://github.com/melix/codenarc-idea
> Download the beta release : 
> 
https://github.com/downloads/melix/codenarc-idea/CodeNarcPlugin-0.1-beta.zip
> 
> Bug reports and contributions are welcome ;)
> 
> Cédric
> 
> 
> 
------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better 
price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user

> ForwardSourceID:NT000F6822 

Re: [Codenarc-user] CodeNarc plugin for IntelliJ IDEA

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

Thanks ;) I'm unsure about what are the best things to do to improve the 
integration. The first problem I have is that the line number isn't 
sufficient : IntelliJ uses its own AST where nodes are PsiElement 
subclasses. When an inspection reports an error, it must provide the 
PsiElement for which it occurs. As I don't know the exact element which 
has thrown the error, I'm doing a quick hint : choose the first 
PsiElement that's on line X. If the violation class could also return an 
ASTNode, I guess I could trigger more heuristics to find the good 
PsiElement.

For a better user experience, inspections also show a short description 
of the problem. CodeNarc rules have a name, a description of what the 
rule analyzes (found in a separate resource bundle), but no short 
description (when the error is actually found). Moreover, the names are 
not really that user friendly, though the name of the class is rather 
self explanatory : http://twitpic.com/3s0xvb/full

Cédric

Le 21/01/2011 16:31, Hamlet DArcy a écrit :
> This is awesome Cédric, I owe you one.
>
> What can we do with our output to make it play better in the IDE?
>
> --
> Hamlet D'Arcy
> ham...@ca...
>
> ----- Original Message -----
>> Hi,
>>
>> Those who are brave enough could test the beta release of the plugin
>> for
>> IntelliJ IDEA that I've just pushed to GitHub. Basically, it adds
>> support for CodeNarc rules as IntelliJ IDEA inspections. Those
>> inspections are available both on the fly and on demand.
>>
>> Some limitations though :
>> - no support for quick fixes
>> - as CodeNarc only reports the line number, on long lines, you
>> won't know precisely where the violation is
>>
>> Project home : https://github.com/melix/codenarc-idea
>> Download the beta release :
>> https://github.com/downloads/melix/codenarc-idea/CodeNarcPlugin-0.1-beta.zip
>>
>> Bug reports and contributions are welcome ;)
>>
>> Cédric
>>
>>
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better
>> price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> Codenarc-user mailing list
>> Cod...@li...
>> https://lists.sourceforge.net/lists/listinfo/codenarc-user

Re: [Codenarc-user] CodeNarc plugin for IntelliJ IDEA

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

This is awesome Cédric, I owe you one. 

What can we do with our output to make it play better in the IDE?

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

----- Original Message -----
> Hi,
> 
> Those who are brave enough could test the beta release of the plugin
> for
> IntelliJ IDEA that I've just pushed to GitHub. Basically, it adds
> support for CodeNarc rules as IntelliJ IDEA inspections. Those
> inspections are available both on the fly and on demand.
> 
> Some limitations though :
> - no support for quick fixes
> - as CodeNarc only reports the line number, on long lines, you
> won't know precisely where the violation is
> 
> Project home : https://github.com/melix/codenarc-idea
> Download the beta release :
> https://github.com/downloads/melix/codenarc-idea/CodeNarcPlugin-0.1-beta.zip
> 
> Bug reports and contributions are welcome ;)
> 
> Cédric
> 
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user

[Codenarc-user] CodeNarc plugin for IntelliJ IDEA

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

Hi,

Those who are brave enough could test the beta release of the plugin for 
IntelliJ IDEA that I've just pushed to GitHub. Basically, it adds 
support for CodeNarc rules as IntelliJ IDEA inspections. Those 
inspections are available both on the fly and on demand.

Some limitations though :
     - no support for quick fixes
     - as CodeNarc only reports the line number, on long lines, you 
won't know precisely where the violation is

Project home : https://github.com/melix/codenarc-idea
Download the beta release : 
https://github.com/downloads/melix/codenarc-idea/CodeNarcPlugin-0.1-beta.zip

Bug reports and contributions are welcome ;)

Cédric

Re: [Codenarc-user] Ruleset Resources Namespace Conflict

[Jason S. <js...@gm...>]

I'm attempting to run some CodeNarc and PMD rules as part of our TestNG
suite (via AntBuilder + CodeNarc task).
The workaround for me isn't a bit deal (and it probably makes sense to be
more selective about the rules I apply); however, keep in mind that if
someone already using PMD happens to add the CodeNarc jar to their
classpath, they'll likely have problems.

On Fri, Jan 21, 2011 at 8:20 AM, <chr...@wa...> wrote:

>
> Yes, in hindsight, I should have put the ruleset files in a unique
> namespace, and as Hamlet suggested, avoiding specific rulesets altogether
> might have been a better approach.
>
> Is there anything forcing you to use the same classpath for both CodeNarc
> and PMD?
>
> I don't think we can, at this point, move the CodeNarc ruleset files, since
> that would break every user. Copying the ruleset files to a different
> location may help as a workaround, but I don't think that would solve the
> problem if the CodeNarc files are "hiding" the CodeNarc ones.
>
> Chris
>
>
>  *Hamlet DArcy <ham...@ca...>*
>
> 01/21/2011 09:05 AM
>   To
> Jason Stell <js...@gm...>
> cc
> cod...@li...
> Subject
> Re: [Codenarc-user] Ruleset Resources Namespace Conflict
>
>
>
>
> CodeNarc is modeled on PMD so we have all those ruleset files in common.
> Personally, I find both projects a little difficult to configure. I'd prefer
> to see one massive configuration file. But that's water under the bridge at
> this point. As you know, there is nothing special about that location. You
> /can/ copy all the contents of the ruleset xml files and dump them into one
> big file.
>
> --
> Hamlet D'Arcy
> ham...@ca...
>
> ----- Original Message -----
> > It does kinda stink ;) I would have suggested a change to PMD resource
> > names, as well, but that project has been around a long time and a
> > change would probably impact many more users (still, as a good
> > practice, they should also think about putting resources in an
> > appropriate namespace).
> >
> >
> > As a workaround I can always extract/copy the rulesets I'm using and
> > put them in a different local namespace.
> >
> >
> > Oh - and thanks for CodeNarc!
> >
> >
> > Regards
> > Jason
> >
> >
> > On Fri, Jan 21, 2011 at 1:30 AM, Hamlet DArcy < ham...@ca...
> > > wrote:
> >
> >
> >
> > > If I have both CodeNarc and PMD libs in my classpath, I have
> > > problems
> >
> > Well that stinks. If we rename the rules then we have backwards
> > compatibility issues. :( We'll have to discuss what to do.
> >
> > Do you need a workaround temporarily? Or do you have that covered?
> >
> >
> > --
> > Hamlet D'Arcy
> > ham...@ca...
> >
> >
> >
> >
> > ----- Original Message -----
> > > If I have both CodeNarc and PMD libs in my classpath, I have
> > > problems
> > > with one or the other, because both have resources with the same
> > > name:
> > > e.g., 'rulesets/basic.xml', 'rulesets/design.xml', etc. How about
> > > using a safer resource namespace, like 'org/codenarc/rulesets/...'?
> > >
> > >
> > > Thanks!
> > > Jason
> > >
> ------------------------------------------------------------------------------
> > > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > > Finally, a world-class log management solution at an even better
> > > price-free!
> > > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > > February 28th, so secure your free ArcSight Logger TODAY!
> > > http://p.sf.net/sfu/arcsight-sfd2d
> > > _______________________________________________
> > > Codenarc-user mailing list
> > > Cod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
> ForwardSourceID:NT000F67C6
>