codenarc-developer — CodeNarc Developers

Re: [Codenarc-developer] More performance improvements - options?

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

After I pulled in your most recent changes...

Run times for Grails + Gradle source, with my sample set of 178 rules
enabled, the average runtime went down to ~ 70 seconds (down from ~ 75sec).
This is only from 13 runs, so not at all scientific.

I also noticed a difference in timings if I had IDEA running in the
background, for what that's worth.

Chris
-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Monday, September 12, 2011 2:24 AM
To: Cod...@li...
Subject: Re: [Codenarc-developer] More performance improvements - options?

Hi Chris,

Can you run your benchmark again with the latest codebase? I'd like to see
how these changes affect performance. Locally, I see an 8-10% improvement
from this change, but I think it will be much higher in a real-world
scenario.

Thanks,


On Sun, Sep 11, 2011 at 10:52 PM, Chris Mair <chr...@ea...>
wrote:
> Hamlet,
>
> I like the getMethodCallExpressions() option. I would prefer to keep 
> the rules independent, and adding that method to SourceCode 
> interface/impl sounds like a reasonable and clean way to do that. And, 
> as you say, we could use that same pattern for other node types as well,
if needed. Sounds good.
>
> Chris
> -----Original Message-----
> From: Hamlet D'Arcy [mailto:ham...@gm...]
> Sent: Sunday, September 11, 2011 4:06 PM
> To: Cod...@li...
> Subject: [Codenarc-developer] More performance improvements - options?
>
> Hi everyone/Chris,
>
> I have an idea for more performance improvements that I believe will 
> make another big difference in how CodeNarc performs.
>
> There are many, many rules that look at only MethodCallExpressions.
> Each of these rules (about 50 of them), walks the AST individually and 
> searches out these MethodCallExpressions. Most the time of these rules 
> is spent in just walking the tree, which is 95% redundant processing 
> for all the rules. It would be better if the tree were walked once, 
> all the MethodCallExpressions were collected, and then each of the 50 
> rules called with just the relevant visitMethodCallExpression without 
> re-walking the entire tree.
>
> One idea to implement this is to create a CompositeRule that has a 
> list of other rules. Then the composite walks the tree once and calls 
> the other
> (children) rules when encountered. The problem with this is that a lot 
> of logic works off rule names, and the composite has many rule names. 
> I don't see a clean way to implement this.
>
> Another idea is to create a parent class that all the MethodCall 
> visitors could extend. Then that parent class could, in a static 
> block, cache all of the MethodCallExpressions and avoid walking the 
> tree redundantly. But this is not clean because each rule is run many 
> times, once for each SourceCode object (a source file). It's complex 
> to implement, has to worry about multithreading, and uses static 
> fields on instance objects. I just don't like it.
>
> My last idea, which I think is the best solution, is to add a new 
> method to the SourceCode interface. SourceCode#getAst exists today. I 
> propose we add SourceCode#getMethodCallExpressions. Then for each 
> SourceCode object we would only walk the tree once and collect useful 
> information about the tree, and rules could get the information when 
> they need it. This is pretty clean to implement. The lifecycle of the 
> cache has the same lifecycle as the source file, which makes sense. It 
> would still need to be multithread safe, but that doesn't sound hard.
> I would write this method on SourceCode:
>  Map<ClassNode, MethodCallExpression> getMethodCallExpressions()
>
> There are other performance enhancements like this as well. I think 
> PropertyExpressions have many rules. Then as we want to optimize we 
> could just add new methods onto the interface.
>
> What do you think of these approaches?
>
> --
> Hamlet D'Arcy
> ham...@gm...
>
> ----------------------------------------------------------------------
> ------
> --
> Using storage to extend the benefits of virtualization and iSCSI 
> Virtualization increases hardware utilization and delivers a new level 
> of agility. Learn what those decisions are and how to modernize your 
> storage and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>
>



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

----------------------------------------------------------------------------
--
Doing More with Less: The Next Generation Virtual Desktop What are the key
obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

Re: [Codenarc-developer] More performance improvements - options?

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

Hi Chris,

Can you run your benchmark again with the latest codebase? I'd like to
see how these changes affect performance. Locally, I see an 8-10%
improvement from this change, but I think it will be much higher in a
real-world scenario.

Thanks,


On Sun, Sep 11, 2011 at 10:52 PM, Chris Mair <chr...@ea...> wrote:
> Hamlet,
>
> I like the getMethodCallExpressions() option. I would prefer to keep the
> rules independent, and adding that method to SourceCode interface/impl
> sounds like a reasonable and clean way to do that. And, as you say, we could
> use that same pattern for other node types as well, if needed. Sounds good.
>
> Chris
> -----Original Message-----
> From: Hamlet D'Arcy [mailto:ham...@gm...]
> Sent: Sunday, September 11, 2011 4:06 PM
> To: Cod...@li...
> Subject: [Codenarc-developer] More performance improvements - options?
>
> Hi everyone/Chris,
>
> I have an idea for more performance improvements that I believe will make
> another big difference in how CodeNarc performs.
>
> There are many, many rules that look at only MethodCallExpressions.
> Each of these rules (about 50 of them), walks the AST individually and
> searches out these MethodCallExpressions. Most the time of these rules is
> spent in just walking the tree, which is 95% redundant processing for all
> the rules. It would be better if the tree were walked once, all the
> MethodCallExpressions were collected, and then each of the 50 rules called
> with just the relevant visitMethodCallExpression without re-walking the
> entire tree.
>
> One idea to implement this is to create a CompositeRule that has a list of
> other rules. Then the composite walks the tree once and calls the other
> (children) rules when encountered. The problem with this is that a lot of
> logic works off rule names, and the composite has many rule names. I don't
> see a clean way to implement this.
>
> Another idea is to create a parent class that all the MethodCall visitors
> could extend. Then that parent class could, in a static block, cache all of
> the MethodCallExpressions and avoid walking the tree redundantly. But this
> is not clean because each rule is run many times, once for each SourceCode
> object (a source file). It's complex to implement, has to worry about
> multithreading, and uses static fields on instance objects. I just don't
> like it.
>
> My last idea, which I think is the best solution, is to add a new method to
> the SourceCode interface. SourceCode#getAst exists today. I propose we add
> SourceCode#getMethodCallExpressions. Then for each SourceCode object we
> would only walk the tree once and collect useful information about the tree,
> and rules could get the information when they need it. This is pretty clean
> to implement. The lifecycle of the cache has the same lifecycle as the
> source file, which makes sense. It would still need to be multithread safe,
> but that doesn't sound hard.
> I would write this method on SourceCode:
>  Map<ClassNode, MethodCallExpression> getMethodCallExpressions()
>
> There are other performance enhancements like this as well. I think
> PropertyExpressions have many rules. Then as we want to optimize we could
> just add new methods onto the interface.
>
> What do you think of these approaches?
>
> --
> Hamlet D'Arcy
> ham...@gm...
>
> ----------------------------------------------------------------------------
> --
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>
>



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

Re: [Codenarc-developer] More performance improvements - options?

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

Hamlet,

I like the getMethodCallExpressions() option. I would prefer to keep the
rules independent, and adding that method to SourceCode interface/impl
sounds like a reasonable and clean way to do that. And, as you say, we could
use that same pattern for other node types as well, if needed. Sounds good.

Chris
-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Sunday, September 11, 2011 4:06 PM
To: Cod...@li...
Subject: [Codenarc-developer] More performance improvements - options?

Hi everyone/Chris,

I have an idea for more performance improvements that I believe will make
another big difference in how CodeNarc performs.

There are many, many rules that look at only MethodCallExpressions.
Each of these rules (about 50 of them), walks the AST individually and
searches out these MethodCallExpressions. Most the time of these rules is
spent in just walking the tree, which is 95% redundant processing for all
the rules. It would be better if the tree were walked once, all the
MethodCallExpressions were collected, and then each of the 50 rules called
with just the relevant visitMethodCallExpression without re-walking the
entire tree.

One idea to implement this is to create a CompositeRule that has a list of
other rules. Then the composite walks the tree once and calls the other
(children) rules when encountered. The problem with this is that a lot of
logic works off rule names, and the composite has many rule names. I don't
see a clean way to implement this.

Another idea is to create a parent class that all the MethodCall visitors
could extend. Then that parent class could, in a static block, cache all of
the MethodCallExpressions and avoid walking the tree redundantly. But this
is not clean because each rule is run many times, once for each SourceCode
object (a source file). It's complex to implement, has to worry about
multithreading, and uses static fields on instance objects. I just don't
like it.

My last idea, which I think is the best solution, is to add a new method to
the SourceCode interface. SourceCode#getAst exists today. I propose we add
SourceCode#getMethodCallExpressions. Then for each SourceCode object we
would only walk the tree once and collect useful information about the tree,
and rules could get the information when they need it. This is pretty clean
to implement. The lifecycle of the cache has the same lifecycle as the
source file, which makes sense. It would still need to be multithread safe,
but that doesn't sound hard.
I would write this method on SourceCode:
  Map<ClassNode, MethodCallExpression> getMethodCallExpressions()

There are other performance enhancements like this as well. I think
PropertyExpressions have many rules. Then as we want to optimize we could
just add new methods onto the interface.

What do you think of these approaches?

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

----------------------------------------------------------------------------
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

[Codenarc-developer] More performance improvements - options?

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

Hi everyone/Chris,

I have an idea for more performance improvements that I believe will
make another big difference in how CodeNarc performs.

There are many, many rules that look at only MethodCallExpressions.
Each of these rules (about 50 of them), walks the AST individually and
searches out these MethodCallExpressions. Most the time of these rules
is spent in just walking the tree, which is 95% redundant processing
for all the rules. It would be better if the tree were walked once,
all the MethodCallExpressions were collected, and then each of the 50
rules called with just the relevant visitMethodCallExpression without
re-walking the entire tree.

One idea to implement this is to create a CompositeRule that has a
list of other rules. Then the composite walks the tree once and calls
the other (children) rules when encountered. The problem with this is
that a lot of logic works off rule names, and the composite has many
rule names. I don't see a clean way to implement this.

Another idea is to create a parent class that all the MethodCall
visitors could extend. Then that parent class could, in a static
block, cache all of the MethodCallExpressions and avoid walking the
tree redundantly. But this is not clean because each rule is run many
times, once for each SourceCode object (a source file). It's complex
to implement, has to worry about multithreading, and uses static
fields on instance objects. I just don't like it.

My last idea, which I think is the best solution, is to add a new
method to the SourceCode interface. SourceCode#getAst exists today. I
propose we add SourceCode#getMethodCallExpressions. Then for each
SourceCode object we would only walk the tree once and collect useful
information about the tree, and rules could get the information when
they need it. This is pretty clean to implement. The lifecycle of the
cache has the same lifecycle as the source file, which makes sense. It
would still need to be multithread safe, but that doesn't sound hard.
I would write this method on SourceCode:
  Map<ClassNode, MethodCallExpression> getMethodCallExpressions()

There are other performance enhancements like this as well. I think
PropertyExpressions have many rules. Then as we want to optimize we
could just add new methods onto the interface.

What do you think of these approaches?

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

Re: [Codenarc-developer] SuppressWarnings refactoring (may effect IDE plugins)

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

Great stuff, Hamlet. I appreciate the simplification of the rule classes,
and being able to get rid of those *Ex methods.

I ran the new code (0.16) against Grails and Gradle source and encountered a
couple minor bugs, and checked in the fixes.

The performance difference between 0.15 and 0.16 is big!

Run times for Grails + Gradle source, with my sample set of 178 rules
enabled:
	CodeNarc 0.15 - average ~ 160 seconds
	CodeNarc 0.16 - average ~ 75 seconds

Sweet!

Thanks,
Chris
-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Saturday, September 10, 2011 5:16 AM
To: Cod...@li...; Cédric CHAMPEAU; René Scheibe
Subject: [Codenarc-developer] SuppressWarnings refactoring (may effect IDE
plugins)

Hi everyone,

This weekend I redesigned how the @SuppressWarnings annotations are handled
by CodeNarc. It may affect IDE support (but maybe not).

Previously, the @SuppressWarnings were handled by the AbstractAstVisitor
class. The problem with this is that not all rules subclass this class, so
not all rules respect @SuppressWarnings. Also, a subclass could sometimes
accidentally ignore the annotation. Also, the old design made it difficult
to support suppressions on parameters and general expressions. The design
has none of these problems and it will perform better as well. Also, by
removing the suppression complexity from the visitors, it makes those
classes more extensible.
Basically, it needs to be done for the two big features I have
planned: type inference and performance.

The new design moves the suppress warning functionality to a new
object: SuppressionAnalyzer. This object is invoked by any of the other
Analyzer objects, like FilesystemSourceAnalyzer and DirectorySourceAnalyzer.
If you have created a custom subclass of Analyzer, then you need to update
your code. If you have not created a custom subclass then do nothing and be
happy and quit reading!

If you have a custom analyzer, then your analyze(RuleSet):Results object
needs to change. Here is what a typical implementation should look like:

    Results analyze(RuleSet ruleSet) {
        def allViolations = []
        def suppressionService = new SuppressionAnalyzer(source)
        ruleSet.rules.each { rule ->
            if (!suppressionService.isRuleSuppressed(rule)) {
                def violations = rule.applyTo(source)
                violations.removeAll {
suppressionService.isViolationSuppressed(it) }
                allViolations.addAll(violations)
            }
        }
        new VirtualResults(allViolations)
    }

You can see that you just need to create the SuppressionAnalyzer object and
then make sure it gets called correctly.

The code is not checked in yet, but I expect it to be checked in later
today.

Thanks,

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

----------------------------------------------------------------------------
--
Malware Security Report: Protecting Your Business, Customers, and the Bottom
Line. Protect your business and customers by understanding the threat from
malware and how it can impact your online business. 
http://www.accelacomm.com/jaw/sfnl/114/51427462/
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

[Codenarc-developer] SuppressWarnings refactoring (may effect IDE plugins)

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

Hi everyone,

This weekend I redesigned how the @SuppressWarnings annotations are
handled by CodeNarc. It may affect IDE support (but maybe not).

Previously, the @SuppressWarnings were handled by the
AbstractAstVisitor class. The problem with this is that not all rules
subclass this class, so not all rules respect @SuppressWarnings. Also,
a subclass could sometimes accidentally ignore the annotation. Also,
the old design made it difficult to support suppressions on parameters
and general expressions. The design has none of these problems and it
will perform better as well. Also, by removing the suppression
complexity from the visitors, it makes those classes more extensible.
Basically, it needs to be done for the two big features I have
planned: type inference and performance.

The new design moves the suppress warning functionality to a new
object: SuppressionAnalyzer. This object is invoked by any of the
other Analyzer objects, like FilesystemSourceAnalyzer and
DirectorySourceAnalyzer. If you have created a custom subclass of
Analyzer, then you need to update your code. If you have not created a
custom subclass then do nothing and be happy and quit reading!

If you have a custom analyzer, then your analyze(RuleSet):Results
object needs to change. Here is what a typical implementation should
look like:

    Results analyze(RuleSet ruleSet) {
        def allViolations = []
        def suppressionService = new SuppressionAnalyzer(source)
        ruleSet.rules.each { rule ->
            if (!suppressionService.isRuleSuppressed(rule)) {
                def violations = rule.applyTo(source)
                violations.removeAll {
suppressionService.isViolationSuppressed(it) }
                allViolations.addAll(violations)
            }
        }
        new VirtualResults(allViolations)
    }

You can see that you just need to create the SuppressionAnalyzer
object and then make sure it gets called correctly.

The code is not checked in yet, but I expect it to be checked in later today.

Thanks,

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

Re: [Codenarc-developer] Big Performance Improvements on 0.16

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

I think that is the last of the low hanging fruit though.

I am back to my idea of rewriting some of the abstract classes in Java
or some other statically typed language.

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



On Fri, Aug 19, 2011 at 3:10 PM, Chris Mair <chr...@ea...> wrote:
> That is great news! Thanks very much.
>
> -----Original Message-----
> From: Hamlet DArcy [mailto:ham...@ca...]
> Sent: Friday, August 19, 2011 8:15 AM
> To: cod...@li...;
> cod...@li...
> Subject: [Codenarc-developer] Big Performance Improvements on 0.16
>
> Hi everyone,
>
> Just an FYI,
>
> There are some big performance improvements in CodeNarc 0.16. This is good
> news.
>
> The run times on my Grails project was cut in half.
>
> The problem was being caused by using the Object#getProperties() method that
> the GDK provides. This does dynamic lookup in the metaclass and reflection
> in the .class file. It is a bit of a performance hog. Anyway, if you're
> writing rules then you should probably avoid looking up properties this way.
>
>
> Enjoy,
>
> --
> Hamlet D'Arcy
> ham...@ca...
>
>
> ----------------------------------------------------------------------------
> --
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
> administration capabilities and model configuration. Take the hassle out of
> deploying and managing Subversion and the tools developers use with it.
> http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>

Re: [Codenarc-developer] Big Performance Improvements on 0.16

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

That is great news! Thanks very much.

-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Friday, August 19, 2011 8:15 AM
To: cod...@li...;
cod...@li...
Subject: [Codenarc-developer] Big Performance Improvements on 0.16

Hi everyone, 

Just an FYI, 

There are some big performance improvements in CodeNarc 0.16. This is good
news. 

The run times on my Grails project was cut in half. 

The problem was being caused by using the Object#getProperties() method that
the GDK provides. This does dynamic lookup in the metaclass and reflection
in the .class file. It is a bit of a performance hog. Anyway, if you're
writing rules then you should probably avoid looking up properties this way.


Enjoy, 

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


----------------------------------------------------------------------------
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user
administration capabilities and model configuration. Take the hassle out of
deploying and managing Subversion and the tools developers use with it.
http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

[Codenarc-developer] Big Performance Improvements on 0.16

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

Hi everyone, 

Just an FYI, 

There are some big performance improvements in CodeNarc 0.16. This is good news. 

The run times on my Grails project was cut in half. 

The problem was being caused by using the Object#getProperties() method that the GDK provides. This does dynamic lookup in the metaclass and reflection in the .class file. It is a bit of a performance hog. Anyway, if you're writing rules then you should probably avoid looking up properties this way. 

Enjoy, 

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

Re: [Codenarc-developer] FW: [ codenarc-Feature Requests-3392455 ] Ignore MethodName for all Spec method

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

I bet that you can configure the rule to do this. 

Don't the tests all share a naming convention? 
Or are JUnit and Spock specs mixed together? 

If we do fix this... then I propose a new global rule property: 
  ignoreSubclasses = [pattern]

So we would ignore the rule based on if an entry in the extends/implements clause matches the regex. 

For instance: 
  ignoreSubclasses = (Specification|*.TestCase)

It would be regex based, not type system based, because not all the classes are visible or on the classpath. 

Then we have a nice, global way to configure rules. 

--
Hamlet


----- Original Message -----
> Any thoughts on this issue?
> 
> It is fairly simple and straightforward to configure the MethodName
> rule (or any rule) to ignore classes by name or by filename or
> regex. I am hesitant to put framework-specific logic in generic
> rules, as suggested. But I guess we already do that so some extent
> by ignoring test classes (by default) for certain rules.
> 
> -----Original Message-----
> From: SourceForge.net [mailto:no...@so...]
> Sent: Tuesday, August 16, 2011 10:03 AM
> To: SourceForge.net
> Subject: [ codenarc-Feature Requests-3392455 ] Ignore MethodName for
> all Spec method
> 
> Feature Requests item #3392455, was opened at 2011-08-16 16:02
> Message generated for change (Tracker Item Submitted) made by
> musketyr You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=1126575&aid=3392455&group_id=250145
> 
> Please note that this message will contain a full copy of the comment
> thread, including the initial issue submission, for this request,
> not just the latest update.
> Category: None
> Group: None
> Status: Open
> Priority: 5
> Private: No
> Submitted By: Vladimír Oraný (musketyr)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: Ignore MethodName for all Spec method
> 
> Initial Comment:
> As Spock is being more and more used among Groovy developers CodeNarc
> should not complain about nonstandard method name in classes
> extending directly or indirectly from spock.lang.Specification
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=1126575&aid=3392455&group_id=250145
> 
> 
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 

[Codenarc-developer] FW: [ codenarc-Feature Requests-3392455 ] Ignore MethodName for all Spec method

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

Any thoughts on this issue?  

It is fairly simple and straightforward to configure the MethodName rule (or any rule) to ignore classes by name or by filename or regex. I am hesitant to put framework-specific logic in generic rules, as suggested. But I guess we already do that so some extent by ignoring test classes (by default) for certain rules.

-----Original Message-----
From: SourceForge.net [mailto:no...@so...] 
Sent: Tuesday, August 16, 2011 10:03 AM
To: SourceForge.net
Subject: [ codenarc-Feature Requests-3392455 ] Ignore MethodName for all Spec method

Feature Requests item #3392455, was opened at 2011-08-16 16:02 Message generated for change (Tracker Item Submitted) made by musketyr You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126575&aid=3392455&group_id=250145

Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Vladimír Oraný (musketyr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ignore MethodName for all Spec method

Initial Comment:
As Spock is being more and more used among Groovy developers CodeNarc should not complain about nonstandard method name in classes extending directly or indirectly from spock.lang.Specification

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

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

[Codenarc-developer] [ANN] Announcing CodeNarc 0.15

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

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

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

New and Updated Rules 

·         AssignCollectionUnique rule (basic) - The Collections.unique()
method mutates the list and returns the list as a value. If you are
assigning the result of unique() to a variable, then you probably don't
realize that you're also modifying the original list as well. This is
frequently the cause of subtle bugs.

·         AssignCollectionSort rule (basic) - The Collections.sort() method
mutates the list and returns the list as a value. If you are assigning the
result of sort() to a variable, then you probably don't realize that you're
also modifying the original list as well. This is frequently the cause of
subtle bugs.

·         BitwiseOperatorInConditional rule (basic) - Checks for bitwise
operations in conditionals, if you need to do a bitwise operation then it is
best practive to extract a temp variable.

·         HardcodedWindowsRootDirectory rule (basic) - This rule find cases
where a File object is constructed with a windows-based path. This is not
portable, and using the File.listRoots() method is a better alternative.

·         HardCodedWindowsFileSeparator rule (basic) - This rule finds
usages of a Windows file separator within the constructor call of a File
object. It is better to use the Unix file separator or use the
File.separator constant.

·         RandomDoubleCoercedToZero rule (basic) - The Math.random() method
returns a double result greater than or equal to 0.0 and less than 1.0. If
you coerce this result into an Integer or int, then it is coerced to zero.
Casting the result to int, or assigning it to an int field is probably a
bug.

·         UnnecessaryDefInVariableDeclaration rule (unnecessary) - If a
variable has a visibility modifier or a type declaration, then the def
keyword is unneeded. For instance 'def private n = 2' is redundant and can
be simplified to 'private n = 2'.

·         UnnecessaryDefInMethodDeclaration rule (unnecessary) - Added more
checked modifiers: final, synchronized, abstract, strictfp. Multiple method
declarations in a single line are handled correctly.

·         UnnecessaryDotClass rule (unnecessary) - To make a reference to a
class, it is unnecessary to specify the '.class' identifier. For instance
String.class can be shortened to String.

·         UnnecessaryInstanceOfCheck rule (unnecessary) - This rule finds
instanceof checks that cannot possibly evaluate to true. For instance,
checking that (!variable instanceof String) will never be true because the
result of a not expression is always a boolean. 

·         UnnecessarySubstring rule (unnecessary) - This rule finds usages
of String.substring(int) and String.substring(int, int) that can be replaced
by use of the subscript operator. For instance, var.substring(5) can be
replaced with var[5..-1].

·         BracesForClass rule (formatting) - Checks the location of the
opening brace ({) for classes. By default, requires them on the same line,
but the sameLine property can be set to false to override this.

·         LineLength rule (formatting) - Checks the maximum length for each
line of source code. It checks for number of characters, so lines that
include tabs may appear longer than the allowed number when viewing the
file. The maximum line length can be configured by setting the length
property, which defaults to 120.

·         BracesForForLoop rule (formatting) - Checks the location of the
opening brace ({) for for loops. By default, requires them on the same line,
but the sameLine property can be set to false to override this.

·         BracesForIfElse rule (formatting) - Checks the location of the
opening brace ({) for if statements. By default, requires them on the same
line, but the sameLine property can be set to false to override this.

·         BracesForMethod rule (formatting) - Checks the location of the
opening brace ({) for constructors and methods. By default, requires them on
the same line, but the sameLine property can be set to false to override
this.

·         BracesForTryCatchFinally rule (formatting) - Checks the location
of the opening brace ({) for try statements. By default, requires them on
the line, but the sameLine property can be set to false to override this.

·         ClassJavadoc rule (formatting) - Makes sure each class and
interface definition is preceded by javadoc. Enum definitions are not
checked, due to strange behavior in the Groovy AST.

·         GrailsDomainHasToString rule (grails) - Checks that Grails domain
classes redefine toString()

·         GrailsDomainHasEquals rule (grails) - Checks that Grails domain
classes redefine equals().

·         JdbcConnectionReference rule (jdbc) - Check for direct use of
java.sql.Connection, which is discouraged and almost never necessary in
application code.

·         JdbcResultSetReference rule (jdbc) - Check for direct use of
java.sql.ResultSet, which is not necessary if using the Groovy Sql facility
or an ORM framework such as Hibernate.

·         JdbcStatementReference rule (jdbc) - Check for direct use of
java.sql.Statement, java.sql.PreparedStatement, or
java.sql.CallableStatement, which is not necessary if using the Groovy Sql
facility or an ORM framework such as Hibernate.

·         IllegalClassReference rule (generic) - Checks for reference to any
of the classes configured in classNames.

 

Bug Fixes and Enhancements 

·         #3325147: Fix for running CodeNarc with a Groovy 1.8 runtime.
There should no longer be StackOverflowExceptions. 

·         #3317632: CloneableWithoutClone - false positive.

·         #3315990: StaticXxxField false positive on initializer:
StaticSimpleDateFormatField, StaticDateFormatField, StaticCalendarField.

·         #3314773: UnnecessaryGroovyImportRule: false positive on static
imports

·         #3315992: ClosureAsLastMethodParameter - false positive, when
method call surrounded by parentheses.

·         #3307699: Fixed a typo and made some "Violation" strings
lowercase, so the log messages are consistent. (Fixed by René Scheibe)

·         #3315946: Cmdline runner does not respect -includes and -excludes.
(Fixed by René Scheibe)

·         #3314576: UnnecessaryPublicModifierRule: MissingPropertyException.
(Fixed by René Scheibe)

·         #3322395: JUnitTestMethodWithoutAssert - Added support for
parameters in the @Test annotation. E.g.: @Test(expected =
IllegalArgumentException) and @Test(timeout = 1000).   (Fixed by René
Scheibe)

·         #3310381: Added test for all rules (in AbstractRuleTestCase) to
verify that any values specified for (doNot)applyToFilesMatching are valid
regular expressions.

·         #3325049: Change StatelessClassRule (generic) to require
applyToClassNames, applyToFileNames or applyToFilesMatching to be
configured.

·         #3361263: IllegalPackageReferenceRule: Also check constructor
parameter types and type coercion (x as Type).

·         #3315991: Unnecessary*Instantiation (including
UnnecessaryBigDecimalInstantiation): Duplicate violations.

·         #3351964: Include rules w/ priority > 4 in HTML report. Add
getViolations() to Results interface.

·         #3375718: UnusedPrivateField: Recognize references to static
fields through the class name.

·         #3380494: Automatically create report output folders.

·         #3376518: UnnecessaryBigDecimalInstantiation should not produce
violations for new BigDecimal(42), new BigDecimal(42L) or new
BigDecimal("42") - i.e., when the parameter evaluates to an integer/long.

·         #3376576: UnnecessaryParenthesesForMethodCallWithClosureRule:
IllegalArgumentException: Start and end indexes are one based and have to be
greater than zero.

·         #3384056: Unnecessary* rules should be priority 3.

Thanks 

*	Thanks to René Scheibe for the
UnnecessaryDefInVariableDeclarationRule and enhancements to
UnnecessaryDefInMethodDeclarationRule;   as well as the many bug fixes.
*	Thanks to Dean Del Ponte for the UnnecessaryDotClass rule.
*	Thanks to Nick Larson, Juan Vazquez, and Jon DeJong for the
AssignCollectionUnique rule. 
*	Thanks to Jeff Beck for the BitwiseOperatorInConditional rule. 
*	Thanks to Geli Crick and Rafael Luque for the BracesForClass,
LineLength, GrailsDomainHasToString,GrailsDomainHasEquals,
BracesForIfElseRule, BracesForMethod, BracesForTryCatchFinally and
ClassJavadoc rules.

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

 

Re: [Codenarc-developer] Running CodeNarc with a Groovy 1.8 Runtime

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

Lets not delay 0.15. I won't have much time in the next few weeks. I'd be
interested to hear what Rene and the other contributors think of the idea.

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

On Aug 1, 2011 3:01 PM, <chr...@we...> wrote:
> I am fine with that. It seems like a good idea. Would you want to delay
the 0.15 release for that?
>
> From: Hamlet D'Arcy [mailto:ham...@gm...]
> Sent: Monday, August 01, 2011 8:43 AM
> To: Mair, Christopher
> Cc: Cod...@li...
> Subject: Re: [Codenarc-developer] Running CodeNarc with a Groovy 1.8
Runtime
>
>
> I would rewrite just the abstract classes and ASTUtil class. Probably 4
classes max.
>
> --
> Hamlet D'Arcy
> ham...@gm...<mailto:ham...@gm...>
>
> On Aug 1, 2011 1:52 PM, <chr...@we...<mailto:
chr...@we...>> wrote:
>>>> I am tempted to rewrite our AST visitor classes and ASTUtil classes in
Java,
>>>> and the rules themselves can be left in Groovy.
>>
>> Do you mean all of the AST visitor classes -- 200+ -- one for almost
every rule? That would be a major effort, right?
>>
>> -----Original Message-----
>> From: Hamlet D'Arcy [mailto:ham...@gm...<mailto:
ham...@gm...>]
>> Sent: Monday, August 01, 2011 3:25 AM
>> To: Cod...@li...<mailto:
Cod...@li...>;
Cod...@li...<mailto:
Cod...@li...>
>> Subject: [Codenarc-developer] Running CodeNarc with a Groovy 1.8 Runtime
>>
>> Hi all,
>>
>> As many know, running CodeNarc 0.14 with a Groovy 1.8 runtime produces
>> many stack overflow exceptions. This issue is fixed in the next
>> release, 0.15.
>>
>> The problem is a base problem with Groovy. Method dispatch to the
>> super class is subtly broken in some class hierarchies when the parent
>> class is compiled Java. It would be nice if you would vote for the
>> issue so that we can remove the workaround from our codebase:
>> http://jira.codehaus.org/browse/GROOVY-4922
>>
>> Note for CodeNarc Developers: I am tempted to rewrite our AST visitor
>> classes and ASTUtil classes in Java, and the rules themselves can be
>> left in Groovy. The underlying problem of method dispatch between code
>> compiled with 1.7 and running with 1.8 remains and is worrying. The
>> rewrite of that small part of CodeNarc would fix the problem for good
>> and also give some nice performance improvements. I feel like CodeNarc
>> is at the same place Gradle was about 2 years ago... the core is
>> implemented in Groovy but as the project grows the benefits of a Java
>> core start to show themselves. With a Java core we'll have a little
>> more safety, a little better performance, and a little more room to
>> grow. What do you think?
>>
>> Thanks,
>>
>> --
>> Hamlet D'Arcy
>> ham...@gm...<mailto:ham...@gm...>
>>
>>
------------------------------------------------------------------------------
>> Got Input? Slashdot Needs You.
>> Take our quick survey online. Come on, we don't ask for help often.
>> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
>> http://p.sf.net/sfu/slashdot-survey
>> _______________________________________________
>> Codenarc-developer mailing list
>> Cod...@li...<mailto:
Cod...@li...>
>> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>>
>>
------------------------------------------------------------------------------
>> Got Input? Slashdot Needs You.
>> Take our quick survey online. Come on, we don't ask for help often.
>> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
>> http://p.sf.net/sfu/slashdot-survey
>> _______________________________________________
>> Codenarc-developer mailing list
>> Cod...@li...<mailto:
Cod...@li...>
>> https://lists.sourceforge.net/lists/listinfo/codenarc-developer

Re: [Codenarc-developer] Running CodeNarc with a Groovy 1.8 Runtime

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

I am fine with that. It seems like a good idea. Would you want to delay the 0.15 release for that?

From: Hamlet D'Arcy [mailto:ham...@gm...]
Sent: Monday, August 01, 2011 8:43 AM
To: Mair, Christopher
Cc: Cod...@li...
Subject: Re: [Codenarc-developer] Running CodeNarc with a Groovy 1.8 Runtime


I would rewrite just the abstract classes and ASTUtil class. Probably 4 classes max.

--
Hamlet D'Arcy
ham...@gm...<mailto:ham...@gm...>

On Aug 1, 2011 1:52 PM, <chr...@we...<mailto:chr...@we...>> wrote:
>>> I am tempted to rewrite our AST visitor classes and ASTUtil classes in Java,
>>> and the rules themselves can be left in Groovy.
>
> Do you mean all of the AST visitor classes -- 200+ -- one for almost every rule? That would be a major effort, right?
>
> -----Original Message-----
> From: Hamlet D'Arcy [mailto:ham...@gm...<mailto:ham...@gm...>]
> Sent: Monday, August 01, 2011 3:25 AM
> To: Cod...@li...<mailto:Cod...@li...>; Cod...@li...<mailto:Cod...@li...>
> Subject: [Codenarc-developer] Running CodeNarc with a Groovy 1.8 Runtime
>
> Hi all,
>
> As many know, running CodeNarc 0.14 with a Groovy 1.8 runtime produces
> many stack overflow exceptions. This issue is fixed in the next
> release, 0.15.
>
> The problem is a base problem with Groovy. Method dispatch to the
> super class is subtly broken in some class hierarchies when the parent
> class is compiled Java. It would be nice if you would vote for the
> issue so that we can remove the workaround from our codebase:
> http://jira.codehaus.org/browse/GROOVY-4922
>
> Note for CodeNarc Developers: I am tempted to rewrite our AST visitor
> classes and ASTUtil classes in Java, and the rules themselves can be
> left in Groovy. The underlying problem of method dispatch between code
> compiled with 1.7 and running with 1.8 remains and is worrying. The
> rewrite of that small part of CodeNarc would fix the problem for good
> and also give some nice performance improvements. I feel like CodeNarc
> is at the same place Gradle was about 2 years ago... the core is
> implemented in Groovy but as the project grows the benefits of a Java
> core start to show themselves. With a Java core we'll have a little
> more safety, a little better performance, and a little more room to
> grow. What do you think?
>
> Thanks,
>
> --
> Hamlet D'Arcy
> ham...@gm...<mailto:ham...@gm...>
>
> ------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...<mailto:Cod...@li...>
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>
> ------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...<mailto:Cod...@li...>
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer

Re: [Codenarc-developer] Running CodeNarc with a Groovy 1.8 Runtime

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

I would rewrite just the abstract classes and ASTUtil class. Probably 4
classes max.

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

On Aug 1, 2011 1:52 PM, <chr...@we...> wrote:
>>> I am tempted to rewrite our AST visitor classes and ASTUtil classes in
Java,
>>> and the rules themselves can be left in Groovy.
>
> Do you mean all of the AST visitor classes -- 200+ -- one for almost every
rule? That would be a major effort, right?
>
> -----Original Message-----
> From: Hamlet D'Arcy [mailto:ham...@gm...]
> Sent: Monday, August 01, 2011 3:25 AM
> To: Cod...@li...;
Cod...@li...
> Subject: [Codenarc-developer] Running CodeNarc with a Groovy 1.8 Runtime
>
> Hi all,
>
> As many know, running CodeNarc 0.14 with a Groovy 1.8 runtime produces
> many stack overflow exceptions. This issue is fixed in the next
> release, 0.15.
>
> The problem is a base problem with Groovy. Method dispatch to the
> super class is subtly broken in some class hierarchies when the parent
> class is compiled Java. It would be nice if you would vote for the
> issue so that we can remove the workaround from our codebase:
> http://jira.codehaus.org/browse/GROOVY-4922
>
> Note for CodeNarc Developers: I am tempted to rewrite our AST visitor
> classes and ASTUtil classes in Java, and the rules themselves can be
> left in Groovy. The underlying problem of method dispatch between code
> compiled with 1.7 and running with 1.8 remains and is worrying. The
> rewrite of that small part of CodeNarc would fix the problem for good
> and also give some nice performance improvements. I feel like CodeNarc
> is at the same place Gradle was about 2 years ago... the core is
> implemented in Groovy but as the project grows the benefits of a Java
> core start to show themselves. With a Java core we'll have a little
> more safety, a little better performance, and a little more room to
> grow. What do you think?
>
> Thanks,
>
> --
> Hamlet D'Arcy
> ham...@gm...
>
>
------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>
>
------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer

Re: [Codenarc-developer] Running CodeNarc with a Groovy 1.8 Runtime

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

>> I am tempted to rewrite our AST visitor classes and ASTUtil classes in Java, 
>> and the rules themselves can be left in Groovy.

Do you mean all of the AST visitor classes -- 200+ -- one for almost every rule? That would be a major effort, right?

-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Monday, August 01, 2011 3:25 AM
To: Cod...@li...; Cod...@li...
Subject: [Codenarc-developer] Running CodeNarc with a Groovy 1.8 Runtime

Hi all,

As many know, running CodeNarc 0.14 with a Groovy 1.8 runtime produces
many stack overflow exceptions. This issue is fixed in the next
release, 0.15.

The problem is a base problem with Groovy. Method dispatch to the
super class is subtly broken in some class hierarchies when the parent
class is compiled Java. It would be nice if you would vote for the
issue so that we can remove the workaround from our codebase:
http://jira.codehaus.org/browse/GROOVY-4922

Note for CodeNarc Developers: I am tempted to rewrite our AST visitor
classes and ASTUtil classes in Java, and the rules themselves can be
left in Groovy. The underlying problem of method dispatch between code
compiled with 1.7 and running with 1.8 remains and is worrying. The
rewrite of that small part of CodeNarc would fix the problem for good
and also give some nice performance improvements. I feel like CodeNarc
is at the same place Gradle was about 2 years ago... the core is
implemented in Groovy but as the project grows the benefits of a Java
core start to show themselves. With a Java core we'll have a little
more safety, a little better performance, and a little more room to
grow. What do you think?

Thanks,

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

------------------------------------------------------------------------------
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

[Codenarc-developer] Running CodeNarc with a Groovy 1.8 Runtime

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

Hi all,

As many know, running CodeNarc 0.14 with a Groovy 1.8 runtime produces
many stack overflow exceptions. This issue is fixed in the next
release, 0.15.

The problem is a base problem with Groovy. Method dispatch to the
super class is subtly broken in some class hierarchies when the parent
class is compiled Java. It would be nice if you would vote for the
issue so that we can remove the workaround from our codebase:
http://jira.codehaus.org/browse/GROOVY-4922

Note for CodeNarc Developers: I am tempted to rewrite our AST visitor
classes and ASTUtil classes in Java, and the rules themselves can be
left in Groovy. The underlying problem of method dispatch between code
compiled with 1.7 and running with 1.8 remains and is worrying. The
rewrite of that small part of CodeNarc would fix the problem for good
and also give some nice performance improvements. I feel like CodeNarc
is at the same place Gradle was about 2 years ago... the core is
implemented in Groovy but as the project grows the benefits of a Java
core start to show themselves. With a Java core we'll have a little
more safety, a little better performance, and a little more room to
grow. What do you think?

Thanks,

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

[Codenarc-developer] new BigDecimal(42)

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

Regarding this issue:

 

https://sourceforge.net/tracker/?func=detail
<https://sourceforge.net/tracker/?func=detail&aid=3376518&group_id=250145&at
id=1126573> &aid=3376518&group_id=250145&atid=1126573

 

The UnnecessaryBigDecimalInstantiation recommends rewriting new
BigDecimal("42") as 42G, but this will produce a BigInteger, not a
BigDecimal.
The same issue exists for new BigDecimal(42) and BigDecimal(42L). Both
recommend replacing with 42G.

 

I am inclined to have the UnnecessaryBigDecimalInstantiation not produce
violations for new BigDecimal(42), new BigDecimal(42L) or new
BigDecimal("42") - i.e., when the parameter evaluates to an integer/long.

 

Any objection?

 

Chris

[Codenarc-developer] CodeNarc 0.15 timeline?

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

Any thoughts on the scope and timeline for CodeNarc 0.15?

 

We already have 20+ new rules and a bunch of bug fixes and features. I would
be inclined to wrap up what we have and call that 0.15.

 

Chris

Re: [Codenarc-developer] Some additional rules

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

I'd love to hear more ideas for Grails rules. What are the grails best
practices that get enforced during code reviews?

On Mon, Jul 4, 2011 at 6:03 PM, Rafael Luque Leiva
<raf...@os...> wrote:
>
> Hi Hamlet,
>
> Great news! We're proud to contribute to the project and we'd like to
> develop more additional rules in the future.
>
> We will take a look to your changes (mainly to learn from them). I've
> noticed that you have ported also GrailsDomainHasEqualsRule and
> GrailsDomainHasToStringRule.
>
> Thank you.
>
> Rafael Luque
>
> 2011/7/2 Hamlet DArcy <ham...@ca...>
>>
>> Hi Everyone,
>>
>> I checked in all of the rules from the extra-codenarc-rules project into
>> CodeNarc 0.15 branch.
>>
>> They are all here:
>> http://codenarc.svn.sourceforge.net/viewvc/codenarc/trunk/src/main/groovy/org/codenarc/rule/formatting/
>>
>> The original author should take a look at my changes. I expanded most of
>> the rules. Among the things I added:
>> * explicit support for the @SuppressWarnings annotation
>> * better handling of multi-line elements (such as when a method
>> declaration spans multiple lines)
>> * some parameters, like if Javadoc is required on inner classes.
>> * swapped some parameters from default false to default true (by default,
>> braces should appear on same line)
>>
>> This was really great work. Thank you for letting us merge it to 0.15.
>>
>>
>>
>>
>> ----- Original Message -----
>> > What is the copyright on this stuff?
>> >
>> > Some of the files say:
>> > /*
>> >  * Copyright 2009, Osoco. All Rights Reserved.
>> >  */
>> >
>> >
>> > Is this open source or copyright of Osoco?
>> >
>> >
>> >
>> > ----- Original Message -----
>> > > Thank you Hamlet.
>> > >
>> > > And, you are right about the CopyrightComment rule.
>> > >
>> > > Bests,
>> > >
>> > > Rafael Luque
>> > >
>> > >
>> > > 2011/6/22 Hamlet DArcy < ham...@ca... >
>> > >
>> > >
>> > > Very cool, I am sure we can use these.
>> > >
>> > > However, the CopyrightComment.groovy can be replaced by the
>> > > standard
>> > > "RequiredRegex" rule.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > ----- Original Message -----
>> > > >
>> > > >
>> > > > Hi all,
>> > > >
>> > > > At OSOCO we are using CodeNarc some time ago and our intention is
>> > > > to
>> > > > be able to write our corporate coding conventions as a CodeNarc
>> > > > ruleset. For that purpose we have written some extra rules that
>> > > > we
>> > > > need and have pushed them to our public repo at GitHub:
>> > > >
>> > > > https://github.com/osoco/extra-codenarc-rules
>> > > >
>> > > > Perhaps you can find some of these rules useful in a general way
>> > > > and
>> > > > we can contribute them to the project.
>> > > >
>> > > > Best regards,
>> > > >
>> > > > Rafael Luque
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > ------------------------------------------------------------------------------
>> > > > Simplify data backup and recovery for your virtual environment
>> > > > with
>> > > > vRanger.
>> > > > Installation's a snap, and flexible recovery options mean your
>> > > > data
>> > > > is safe,
>> > > > secure and there when you need it. Data protection magic?
>> > > > Nope - It's vRanger. Get your free trial download today.
>> > > > http://p.sf.net/sfu/quest-sfdev2dev
>> > > > _______________________________________________
>> > > > Codenarc-developer mailing list
>> > > > Cod...@li...
>> > > > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>> > > >
>> > >
>> > >
>> >
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>
>



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

Re: [Codenarc-developer] Some additional rules

[Rafael L. L. <raf...@os...>]

Hi Hamlet,

Great news! We're proud to contribute to the project and we'd like to
develop more additional rules in the future.

We will take a look to your changes (mainly to learn from them). I've
noticed that you have ported also GrailsDomainHasEqualsRule and
GrailsDomainHasToStringRule.

Thank you.

Rafael Luque

2011/7/2 Hamlet DArcy <ham...@ca...>

> Hi Everyone,
>
> I checked in all of the rules from the extra-codenarc-rules project into
> CodeNarc 0.15 branch.
>
> They are all here:
> http://codenarc.svn.sourceforge.net/viewvc/codenarc/trunk/src/main/groovy/org/codenarc/rule/formatting/
>
> The original author should take a look at my changes. I expanded most of
> the rules. Among the things I added:
> * explicit support for the @SuppressWarnings annotation
> * better handling of multi-line elements (such as when a method declaration
> spans multiple lines)
> * some parameters, like if Javadoc is required on inner classes.
> * swapped some parameters from default false to default true (by default,
> braces should appear on same line)
>
> This was really great work. Thank you for letting us merge it to 0.15.
>
>
>
>
> ----- Original Message -----
> > What is the copyright on this stuff?
> >
> > Some of the files say:
> > /*
> >  * Copyright 2009, Osoco. All Rights Reserved.
> >  */
> >
> >
> > Is this open source or copyright of Osoco?
> >
> >
> >
> > ----- Original Message -----
> > > Thank you Hamlet.
> > >
> > > And, you are right about the CopyrightComment rule.
> > >
> > > Bests,
> > >
> > > Rafael Luque
> > >
> > >
> > > 2011/6/22 Hamlet DArcy < ham...@ca... >
> > >
> > >
> > > Very cool, I am sure we can use these.
> > >
> > > However, the CopyrightComment.groovy can be replaced by the
> > > standard
> > > "RequiredRegex" rule.
> > >
> > >
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > At OSOCO we are using CodeNarc some time ago and our intention is
> > > > to
> > > > be able to write our corporate coding conventions as a CodeNarc
> > > > ruleset. For that purpose we have written some extra rules that
> > > > we
> > > > need and have pushed them to our public repo at GitHub:
> > > >
> > > > https://github.com/osoco/extra-codenarc-rules
> > > >
> > > > Perhaps you can find some of these rules useful in a general way
> > > > and
> > > > we can contribute them to the project.
> > > >
> > > > Best regards,
> > > >
> > > > Rafael Luque
> > > >
> > > >
> > > >
> > > >
> ------------------------------------------------------------------------------
> > > > Simplify data backup and recovery for your virtual environment
> > > > with
> > > > vRanger.
> > > > Installation's a snap, and flexible recovery options mean your
> > > > data
> > > > is safe,
> > > > secure and there when you need it. Data protection magic?
> > > > Nope - It's vRanger. Get your free trial download today.
> > > > http://p.sf.net/sfu/quest-sfdev2dev
> > > > _______________________________________________
> > > > Codenarc-developer mailing list
> > > > Cod...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> > > >
> > >
> > >
> >
>

Re: [Codenarc-developer] Some additional rules

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

Hi Everyone, 

I checked in all of the rules from the extra-codenarc-rules project into CodeNarc 0.15 branch. 

They are all here: http://codenarc.svn.sourceforge.net/viewvc/codenarc/trunk/src/main/groovy/org/codenarc/rule/formatting/

The original author should take a look at my changes. I expanded most of the rules. Among the things I added: 
* explicit support for the @SuppressWarnings annotation
* better handling of multi-line elements (such as when a method declaration spans multiple lines)
* some parameters, like if Javadoc is required on inner classes. 
* swapped some parameters from default false to default true (by default, braces should appear on same line)

This was really great work. Thank you for letting us merge it to 0.15. 




----- Original Message -----
> What is the copyright on this stuff?
> 
> Some of the files say:
> /*
>  * Copyright 2009, Osoco. All Rights Reserved.
>  */
> 
> 
> Is this open source or copyright of Osoco?
> 
> 
> 
> ----- Original Message -----
> > Thank you Hamlet.
> > 
> > And, you are right about the CopyrightComment rule.
> > 
> > Bests,
> > 
> > Rafael Luque
> > 
> > 
> > 2011/6/22 Hamlet DArcy < ham...@ca... >
> > 
> > 
> > Very cool, I am sure we can use these.
> > 
> > However, the CopyrightComment.groovy can be replaced by the
> > standard
> > "RequiredRegex" rule.
> > 
> > 
> > 
> > 
> > 
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > Hi all,
> > > 
> > > At OSOCO we are using CodeNarc some time ago and our intention is
> > > to
> > > be able to write our corporate coding conventions as a CodeNarc
> > > ruleset. For that purpose we have written some extra rules that
> > > we
> > > need and have pushed them to our public repo at GitHub:
> > > 
> > > https://github.com/osoco/extra-codenarc-rules
> > > 
> > > Perhaps you can find some of these rules useful in a general way
> > > and
> > > we can contribute them to the project.
> > > 
> > > Best regards,
> > > 
> > > Rafael Luque
> > > 
> > > 
> > > 
> > > ------------------------------------------------------------------------------
> > > Simplify data backup and recovery for your virtual environment
> > > with
> > > vRanger.
> > > Installation's a snap, and flexible recovery options mean your
> > > data
> > > is safe,
> > > secure and there when you need it. Data protection magic?
> > > Nope - It's vRanger. Get your free trial download today.
> > > http://p.sf.net/sfu/quest-sfdev2dev
> > > _______________________________________________
> > > Codenarc-developer mailing list
> > > Cod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> > > 
> > 
> > 
> 

Re: [Codenarc-developer] Some additional rules

[Rafael L. L. <raf...@os...>]

Hamlet,

We've just replaced all these copyright comment, so now they refer to the
Apache License 2.0.

Thank you,

Rafael Luque

2011/6/30 Hamlet DArcy <ham...@ca...>

> What is the copyright on this stuff?
>
> Some of the files say:
> /*
>  * Copyright 2009, Osoco. All Rights Reserved.
>  */
>
>
> Is this open source or copyright of Osoco?
>
>
>
> ----- Original Message -----
> > Thank you Hamlet.
> >
> > And, you are right about the CopyrightComment rule.
> >
> > Bests,
> >
> > Rafael Luque
> >
> >
> > 2011/6/22 Hamlet DArcy < ham...@ca... >
> >
> >
> > Very cool, I am sure we can use these.
> >
> > However, the CopyrightComment.groovy can be replaced by the standard
> > "RequiredRegex" rule.
> >
> >
> >
> >
> >
> >
> > ----- Original Message -----
> > >
> > >
> > > Hi all,
> > >
> > > At OSOCO we are using CodeNarc some time ago and our intention is
> > > to
> > > be able to write our corporate coding conventions as a CodeNarc
> > > ruleset. For that purpose we have written some extra rules that we
> > > need and have pushed them to our public repo at GitHub:
> > >
> > > https://github.com/osoco/extra-codenarc-rules
> > >
> > > Perhaps you can find some of these rules useful in a general way
> > > and
> > > we can contribute them to the project.
> > >
> > > Best regards,
> > >
> > > Rafael Luque
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > Simplify data backup and recovery for your virtual environment with
> > > vRanger.
> > > Installation's a snap, and flexible recovery options mean your data
> > > is safe,
> > > secure and there when you need it. Data protection magic?
> > > Nope - It's vRanger. Get your free trial download today.
> > > http://p.sf.net/sfu/quest-sfdev2dev
> > > _______________________________________________
> > > Codenarc-developer mailing list
> > > Cod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> > >
> >
> >
>

Re: [Codenarc-developer] Some additional rules

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

What is the copyright on this stuff? 

Some of the files say: 
/*
 * Copyright 2009, Osoco. All Rights Reserved.
 */


Is this open source or copyright of Osoco? 



----- Original Message -----
> Thank you Hamlet.
> 
> And, you are right about the CopyrightComment rule.
> 
> Bests,
> 
> Rafael Luque
> 
> 
> 2011/6/22 Hamlet DArcy < ham...@ca... >
> 
> 
> Very cool, I am sure we can use these.
> 
> However, the CopyrightComment.groovy can be replaced by the standard
> "RequiredRegex" rule.
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> > 
> > 
> > Hi all,
> > 
> > At OSOCO we are using CodeNarc some time ago and our intention is
> > to
> > be able to write our corporate coding conventions as a CodeNarc
> > ruleset. For that purpose we have written some extra rules that we
> > need and have pushed them to our public repo at GitHub:
> > 
> > https://github.com/osoco/extra-codenarc-rules
> > 
> > Perhaps you can find some of these rules useful in a general way
> > and
> > we can contribute them to the project.
> > 
> > Best regards,
> > 
> > Rafael Luque
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > Simplify data backup and recovery for your virtual environment with
> > vRanger.
> > Installation's a snap, and flexible recovery options mean your data
> > is safe,
> > secure and there when you need it. Data protection magic?
> > Nope - It's vRanger. Get your free trial download today.
> > http://p.sf.net/sfu/quest-sfdev2dev
> > _______________________________________________
> > Codenarc-developer mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> > 
> 
> 

[Codenarc-developer] grails plugin is 0.12?

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

The grails plugin page shows the codenarc plugin as version 0.12:
http://www.grails.org/plugin/codenarc

But the source code looks like it is upgraded to 0.14

Is there something that needs to be done to release the plugin?

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