codenarc-user — CodeNarc Users

[Codenarc-user] [ANN] Announcing CodeNarc 2.0.0

[Chris M. <cm...@gm...>]

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

CodeNarc <https://codenarc.org/> is a static analysis tool for Groovy
source code.

Version *2.0.0* includes 3 new rules, lots of enhancements and bug fixes. See
the full details in the release notes
<https://github.com/CodeNarc/CodeNarc/blob/master/CHANGELOG.md>.

*Significant Changes*

   - Upgrade to Java 1.7 and Groovy 2.5.
   - 3 New rules checking for *Optionals* field types, parameter types, or
   a method return type of *Optional<**collection*>.
   - You can now disable (most) rules from comments
   <https://codenarc.org/codenarc-configuring-rules.html#disabling-rules-from-comments>
   .
   - New CodeNarc *Plugin *mechanism; see the release notes. *Flux
   capacitor* <https://www.oreillyauto.com/flux-500.html> integration being
   considered.
   - JSON rulesets.

Check us out on GitHub <https://github.com/CodeNarc/CodeNarc>!

NOTE: The Grails 2.x CodeNarc Plugin <http://grails.org/plugin/codenarc> has
not been updated, since the Grails 2.x branch is still on Groovy 2.4, and
CodeNarc 2.0 has upgraded to Groovy 2.5.

[Codenarc-user] [ANN] Announcing CodeNarc 1.6

[Chris M. <cm...@gm...>]

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

CodeNarc <http://codenarc.org/> is a static analysis tool for Groovy source
code.

Version *1.6* includes 2 new rules, and several enhancements and bug fixes,
and improved Groovy 3.0 support. See the full details in the release notes
<https://github.com/CodeNarc/CodeNarc/blob/master/CHANGELOG.md>.

*New Rules*

   - *ImplicitReturnStatement* rule (convention). Checks for non-void
   methods that are missing an explicit return statement.
   - *GrailsDomainGormMethods* rule (convention) - Checks for use of GORM
   methods.

Check us out on GitHub <https://github.com/CodeNarc/CodeNarc>!

The Grails CodeNarc Plugin <http://grails.org/plugin/codenarc> has been
updated to version *1.6* as well.

[Codenarc-user] [ANN] Announcing CodeNarc 1.4

[Chris M. <cm...@gm...>]

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

CodeNarc <http://codenarc.org/> is a static analysis tool for Groovy source
code.

Version *1.4* includes 4 new rules, and several enhancements and bug fixes. See
the full details in the release notes
<https://github.com/CodeNarc/CodeNarc/blob/master/CHANGELOG.md>.

*New Rules*

   - *CompileStatic* rule (convention) - Enforces all classes are annotated
   with @CompileStatic, @GrailsCompileStatic or @CompileDynamic annotations.
   - *JavadocMissingParamDescription* rule (comments) - Checks for missing
   description within @param javadoc tags.
   - *JavadocMissingThrowsDescription* rule (comments). Checks for missing
   description within @throws javadoc tags.
   - *JavadocMissingExceptionDescription* rule (comments). Checks for
   missing description within @exception javadoc tags.

Check us out on GitHub <https://github.com/CodeNarc/CodeNarc>!

The Grails CodeNarc Plugin <http://grails.org/plugin/codenarc> has been
updated to version *1.4* as well.

[Codenarc-user] [ANN] Announcing CodeNarc 1.3

[Chris M. <cm...@gm...>]

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

CodeNarc <http://codenarc.org/> is a static analysis tool for Groovy source
code.

Version *1.3* includes 14 new rules (and a new "comments" ruleset), and
several enhancements and bug fixes. See the full details in the release
notes <https://github.com/CodeNarc/CodeNarc/blob/master/CHANGELOG.md>.

*New Rules*

   - ClassEndsWithBlankLine rule (formatting) - Check whether the class
   ends with a blank line.
   - ClassStartsWithBlankLine rule (formatting) - Check whether the class
   starts with a blank line.
   - ExplicitCallToPutAtMethod rule - Detects when the map.putAt(k, v) method
   is called directly rather than using map[k] = v.
   - JavadocEmptyFirstLine rule (comments) - Check for javadoc comments
   with an empty top line.
   - JavadocEmptyLastLine rule (comments) - Check for javadoc comments with
   an empty line at the bottom.
   - JavadocConsecutiveEmptyLines rule (comments) - Checks for javadoc
   comments with more than one consecutive empty line.
   - JavadocEmptySeeTag rule (comments) - Checks for empty @see tags within
   javadoc.
   - JavadocEmptyParamTag rule (comments) - Checks for empty @param tags
   within javadoc.
   - JavadocEmptyReturnTag rule (comments) - Checks for empty @return tags
   within javadoc.
   - JavadocEmptyThrowsTag rule (comments) - Checks for empty @throws tag
   within javadoc.
   - JavadocEmptyExceptionTag rule (comments) - Checks for empty @exception
   tag within javadoc.
   - JavadocEmptyAuthorTag rule (comments) - Checks for empty @author tags
   within javadoc.
   - JavadocEmptySinceTag rule (comments) - Checks for empty @since tags
   within javadoc.
   - JavadocEmptyVersionTag rule (comments) - Checks for empty @version
   tags within javadoc.

Check us out on GitHub <https://github.com/CodeNarc/CodeNarc>!

The Grails CodeNarc Plugin <http://grails.org/plugin/codenarc> has been
updated to version *1.3* as well.

Re: [Codenarc-user] [ANN] Announcing CodeNarc 1.2

[Remko P. <rem...@gm...>]

Blogged:
https://blogs.apache.org/groovy/entry/announce-announcing-codenarc-1-2


On Tue, Jul 10, 2018 at 3:46 AM, <chr...@we...> wrote:

> The *CodeNarc** Team *is proud to announce the release of version *1.**2*.
>
> *CodeNarc* <http://codenarc.org/> is a static analysis tool for Groovy
> source code.
>
> Version *1.**2* includes 5 new rules and several enhancements and bug
> fixes. See the full details in the *release notes*
> <https://github.com/CodeNarc/CodeNarc/blob/master/CHANGELOG.md>.
>
> *New Rules*
>
>    - *StaticFieldsBeforeInstanceFields* rule (convention) - Enforce that
>    all static fields are above all instance fields within a class.
>    - *StaticMethodsBeforeInstanceMethods* rule (convention) - Enforce
>    that all static methods within each visibility level (public, protected,
>    private) are above all instance methods within that same visibility level.
>    - *PublicMethodsBeforeNonPublicMethods* rule (convention) - Enforce
>    that all public methods are above protected and private methods.
>    - *GrailsDomainStringPropertyMaxSize* rule (grails) - String
>    properties in Grails domain classes have to define maximum size otherwise
>    the property is mapped to VARCHAR(255) causing runtime exceptions to occur.
>    - *NoJavaUtilDate* rule (convention) - Do not use java.util.Date.
>    Prefer the classes in the java.time.* packages. Checks for construction of
>    new java.util.Date objects.
>
> Check us out on *GitHub* <https://github.com/CodeNarc/CodeNarc>!
>
> The *Grails **CodeNarc** Plugin* <http://grails.org/plugin/codenarc> has
> been updated to version *1.**2* as well.
>
>
>
>

[Codenarc-user] [ANN] Announcing CodeNarc 1.2

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

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

CodeNarc<http://codenarc.org/> is a static analysis tool for Groovy source code.

Version 1.2 includes 5 new rules and several enhancements and bug fixes. See the full details in the release notes<https://github.com/CodeNarc/CodeNarc/blob/master/CHANGELOG.md>.

New Rules
*       StaticFieldsBeforeInstanceFields rule (convention) - Enforce that all static fields are above all instance fields within a class.
*       StaticMethodsBeforeInstanceMethods rule (convention) - Enforce that all static methods within each visibility level (public, protected, private) are above all instance methods within that same visibility level.
*       PublicMethodsBeforeNonPublicMethods rule (convention) - Enforce that all public methods are above protected and private methods.
*       GrailsDomainStringPropertyMaxSize rule (grails) - String properties in Grails domain classes have to define maximum size otherwise the property is mapped to VARCHAR(255) causing runtime exceptions to occur.
*       NoJavaUtilDate rule (convention) - Do not use java.util.Date. Prefer the classes in the java.time.* packages. Checks for construction of new java.util.Date objects.
Check us out on GitHub<https://github.com/CodeNarc/CodeNarc>!

The Grails CodeNarc Plugin<http://grails.org/plugin/codenarc> has been updated to version 1.2 as well.

Re: [Codenarc-user] success stories?

[Chris M. <cm...@gm...>]

Philip,

*I have applied static analysis to a few codebases over the years, some
more challenging than others. *

*For greenfield projects, I tend to start strict and loosen up as necessary
-- enable all the rules you think you want, and then be willing to disable
when a rule is more trouble than it’s worth.*

*For an existing large codebase, I tend to start small and grow as able.
Select the small, core set of rules, fix the violations, and then expand
the ruleset incrementally as you have the opportunity. I’d probably rather
have a smaller ruleset with developer buy-in and acceptance, rather than a
larger ruleset with resentment.*

I don't know if it is helpful, but this blog post discusses using CodeNarc
*generic* rules for some custom, non-standard use cases, that might be
attractive to senior devs:
https://tenpercentnotcrap.wordpress.com/2013/08/04/codenarc-hidden-gems-using-codenarcs-generic-rules/


Good luck.

Chris

On Wed, Mar 7, 2018 at 3:01 AM, Philip Yurchuk <
phi...@ma...> wrote:

> Hi Marcin,
>
> Thanks for the encouragement! I think I've got a lot of points to justify
> it's use and endorsements from famous programmers, which will help. My
> challenge is demonstrating how to implement it. The big complaint is that
> such tools are too noisy, and I understand that viewpoint. I tried this on
> a personal project and got over 3,000 warnings or errors. My approach:
>
>
>    - Change the scope to remove config files, which have DSLs and idioms
>    that can clash with rules. Your config files should be carefully peer
>    reviewed anyway.
>    - Change the templates of your code generators (including in your IDE)
>    to produce compliant code. If you can't, exclude it in the scope.
>    - If you must, limit the scope to changed files, just to spur adoption.
>       - Code is read more than it is written, so a big benefit is gained
>    from everyone's code looking identical in style and idiom. (This is a key
>    point from my programmer productivity talk.) It takes less time and mental
>    effort to make the code compliant with the rules than it does to justify
>    why it doesn't need to change.
>    - Most of the time it's better to suppress a warning than kill the
>    rule.
>    - Corollary: if removing rules encourages adoption without adding
>       risk, give yourself permission to so.
>
> I'm very open to feedback ideas. Another challenge is to properly address
> the talk. I think this is hugely beneficial to junior devs, as learning the
> rules will accelerate your path to senior. So going over the rules that
> catch newbie bugs is very enlightening. But senior devs have the power to
> enforce it's use, and I don't want to bore them covering elementary rules
> on hashcode, equals, serialization, etc. I think CodeNarc's idiom
> enforcement is truly excellent for advanced developers, and I'm still going
> through them but I'm not seeing them as much in PMD or SpotBugs. The latter
> does have the advantage of bytecode analysis of files across the project.
>
> Thanks,
> Philip
>
>
> On 3/6/2018 11:58 AM, Marcin Erdmann wrote:
>
> Hi Philip,
>
> I'm a big fan of CodeNarc and use it where I can. Unfortunately I do not
> have any success stories but a generic observation that over the years I've
> encountered a lot of resistance from others when trying to add CodeNarc to
> projects. Maybe you need to have a certain level of OCD in you to
> appreciate how good it is at keeping the codebase consistent (for me that
> characteristic of CodeNarc is even more important that helping to spot
> bugs).
>
> Anyhow, good luck with your talk. I'd appreciate you sharing a link if a
> recording of it is made public. :)
>
> Marcin
>
> On Fri, Feb 16, 2018 at 12:35 AM, Philip Yurchuk <
> phi...@ma...> wrote:
>
>> Hi all,
>>
>> Big thanks to the developers for this tool! I'll be giving a talk to the
>> OCJUG next month about static code analysis, and being a Groovy guy,
>> CodeNarc will feature prominently. Maybe I'll get some Groovy converts, but
>> the purpose is to get people to start using these tools.
>>
>> Are there any great success stories with using these tools? How are you
>> persuading people to use them? I'm invoking an John Carmack (Doom, Quake,
>> Oculus VR), who is a huge proponent of such tools and admits his own code
>> is "riddled with errors." He also mentioned a multi-developer, multi-day
>> bug hunt that ended up being an error that the analysis tool flagged, but
>> he hadn't had a chance to fix.
>>
>> I'll also be showing how it fits Larry Wall's three virtues of a great
>> programmer. But specific success stories would be great to have. I do think
>> the rules themselves show how strong the tooling has become and will be
>> going over many.
>>
>> Thanks much,
>> Philip
>>
>> --
>>
>> [image: Made Up Name] <http://MadeUpName.com>
>>
>> Philip Yurchuk <http://linkedin.com/in/philipyurchuk/> / CEO
>> 714-585-5756 <%28714%29%20585-5756>
>>
>> Software Development and Staffing
>> http://MadeUpName.com
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Codenarc-user mailing list
>> Cod...@li...
>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>
>>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
>

Re: [Codenarc-user] success stories?

[Philip Y. <phi...@ma...>]

Hi Marcin,

Thanks for the encouragement! I think I've got a lot of points to 
justify it's use and endorsements from famous programmers, which will 
help. My challenge is demonstrating how to implement it. The big 
complaint is that such tools are too noisy, and I understand that 
viewpoint. I tried this on a personal project and got over 3,000 
warnings or errors. My approach:

  * Change the scope to remove config files, which have DSLs and idioms
    that can clash with rules. Your config files should be carefully
    peer reviewed anyway.
  * Change the templates of your code generators (including in your IDE)
    to produce compliant code. If you can't, exclude it in the scope.
      o If you must, limit the scope to changed files, just to spur
        adoption.
  * Code is read more than it is written, so a big benefit is gained
    from everyone's code looking identical in style and idiom. (This is
    a key point from my programmer productivity talk.) It takes less
    time and mental effort to make the code compliant with the rules
    than it does to justify why it doesn't need to change.
  * Most of the time it's better to suppress a warning than kill the rule.
      o Corollary: if removing rules encourages adoption without adding
        risk, give yourself permission to so.

I'm very open to feedback ideas. Another challenge is to properly 
address the talk. I think this is hugely beneficial to junior devs, as 
learning the rules will accelerate your path to senior. So going over 
the rules that catch newbie bugs is very enlightening. But senior devs 
have the power to enforce it's use, and I don't want to bore them 
covering elementary rules on hashcode, equals, serialization, etc. I 
think CodeNarc's idiom enforcement is truly excellent for advanced 
developers, and I'm still going through them but I'm not seeing them as 
much in PMD or SpotBugs. The latter does have the advantage of bytecode 
analysis of files across the project.

Thanks,
Philip


On 3/6/2018 11:58 AM, Marcin Erdmann wrote:
> Hi Philip,
>
> I'm a big fan of CodeNarc and use it where I can. Unfortunately I do 
> not have any success stories but a generic observation that over the 
> years I've encountered a lot of resistance from others when trying to 
> add CodeNarc to projects. Maybe you need to have a certain level of 
> OCD in you to appreciate how good it is at keeping the codebase 
> consistent (for me that characteristic of CodeNarc is even more 
> important that helping to spot bugs).
>
> Anyhow, good luck with your talk. I'd appreciate you sharing a link if 
> a recording of it is made public. :)
>
> Marcin
>
> On Fri, Feb 16, 2018 at 12:35 AM, Philip Yurchuk 
> <phi...@ma... <mailto:phi...@ma...>> 
> wrote:
>
>     Hi all,
>
>     Big thanks to the developers for this tool! I'll be giving a talk
>     to the OCJUG next month about static code analysis, and being a
>     Groovy guy, CodeNarc will feature prominently. Maybe I'll get some
>     Groovy converts, but the purpose is to get people to start using
>     these tools.
>
>     Are there any great success stories with using these tools? How
>     are you persuading people to use them? I'm invoking an John
>     Carmack (Doom, Quake, Oculus VR), who is a huge proponent of such
>     tools and admits his own code is "riddled with errors." He also
>     mentioned a multi-developer, multi-day bug hunt that ended up
>     being an error that the analysis tool flagged, but he hadn't had a
>     chance to fix.
>
>     I'll also be showing how it fits Larry Wall's three virtues of a
>     great programmer. But specific success stories would be great to
>     have. I do think the rules themselves show how strong the tooling
>     has become and will be going over many.
>
>     Thanks much,
>     Philip
>
>     -- 
>
>     Made Up Name <http://MadeUpName.com>
>
>     	
>
>     Philip Yurchuk <http://linkedin.com/in/philipyurchuk/> / CEO
>     714-585-5756 <tel:%28714%29%20585-5756>
>
>     Software Development and Staffing
>     http://MadeUpName.com
>
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     Codenarc-user mailing list
>     Cod...@li... <http://sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
>

Re: [Codenarc-user] success stories?

[Marcin E. <mar...@pr...>]

Hi Philip,

I'm a big fan of CodeNarc and use it where I can. Unfortunately I do not
have any success stories but a generic observation that over the years I've
encountered a lot of resistance from others when trying to add CodeNarc to
projects. Maybe you need to have a certain level of OCD in you to
appreciate how good it is at keeping the codebase consistent (for me that
characteristic of CodeNarc is even more important that helping to spot
bugs).

Anyhow, good luck with your talk. I'd appreciate you sharing a link if a
recording of it is made public. :)

Marcin

On Fri, Feb 16, 2018 at 12:35 AM, Philip Yurchuk <
phi...@ma...> wrote:

> Hi all,
>
> Big thanks to the developers for this tool! I'll be giving a talk to the
> OCJUG next month about static code analysis, and being a Groovy guy,
> CodeNarc will feature prominently. Maybe I'll get some Groovy converts, but
> the purpose is to get people to start using these tools.
>
> Are there any great success stories with using these tools? How are you
> persuading people to use them? I'm invoking an John Carmack (Doom, Quake,
> Oculus VR), who is a huge proponent of such tools and admits his own code
> is "riddled with errors." He also mentioned a multi-developer, multi-day
> bug hunt that ended up being an error that the analysis tool flagged, but
> he hadn't had a chance to fix.
>
> I'll also be showing how it fits Larry Wall's three virtues of a great
> programmer. But specific success stories would be great to have. I do think
> the rules themselves show how strong the tooling has become and will be
> going over many.
>
> Thanks much,
> Philip
>
> --
>
> [image: Made Up Name] <http://MadeUpName.com>
>
> Philip Yurchuk <http://linkedin.com/in/philipyurchuk/> / CEO
> 714-585-5756 <(714)%20585-5756>
>
> Software Development and Staffing
> http://MadeUpName.com
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
>

[Codenarc-user] success stories?

[Philip Y. <phi...@ma...>]

Hi all,

Big thanks to the developers for this tool! I'll be giving a talk to the 
OCJUG next month about static code analysis, and being a Groovy guy, 
CodeNarc will feature prominently. Maybe I'll get some Groovy converts, 
but the purpose is to get people to start using these tools.

Are there any great success stories with using these tools? How are you 
persuading people to use them? I'm invoking an John Carmack (Doom, 
Quake, Oculus VR), who is a huge proponent of such tools and admits his 
own code is "riddled with errors." He also mentioned a multi-developer, 
multi-day bug hunt that ended up being an error that the analysis tool 
flagged, but he hadn't had a chance to fix.

I'll also be showing how it fits Larry Wall's three virtues of a great 
programmer. But specific success stories would be great to have. I do 
think the rules themselves show how strong the tooling has become and 
will be going over many.

Thanks much,
Philip

-- 

Made Up Name <http://MadeUpName.com>

	

Philip Yurchuk <http://linkedin.com/in/philipyurchuk/> / CEO
714-585-5756

Software Development and Staffing
http://MadeUpName.com

[Codenarc-user] [ANN] Announcing CodeNarc 1.1

[Chris M. <cm...@gm...>]

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

CodeNarc <http://codenarc.org/> is a static analysis tool for Groovy source
code.

Version *1.1* includes 9 new rules and several enhancements and bug fixes. See
the full details in the release notes
<https://github.com/CodeNarc/CodeNarc/blob/master/CHANGELOG.md>.

*New Rules*

   - MissingOverrideAnnotation rule (enhanced) - Checks for methods that
   override a method in a super class or implement a method in an interface
   but are not annotated with @Override.
   - Indentation rule (formatting) - Check indentation for class, method
   and field declarations and initial statements.
   - InvertedCondition rule (convention) - An inverted condition is one
   where a constant expression is used on the left hand side of the equals
   comparision. Such conditions can be confusing especially when used in
   assertions where the expected value is by convention placed on the right
   hand side of the comparision.
   - MethodReturnTypeRequired rule (convention) - Checks that method return
   types are not dynamic, that is they are explicitly stated (and not using
   *def*).
   - MethodParameterTypeRequired rule (convention) - Checks that method
   parameters are not dynamically typed, that is they are explicitly
   stated (and not using *def*).
   - FieldTypeRequired rule (convention) - Checks that field types are
   explicitly specified (and not using *def*)
   - VariableTypeRequired rule (convention) - Checks that variable types
   are explicitly specified in declarations (and not using *def*)
   - BlockStartsWithBlankLine rule (formatting) - Checks that code blocks
   such as method bodies, closures and control structure bodies do not start
   with an empty line.
   - BlockEndsWithBlankLine rule (formatting) - Checks that code blocks
   such as method bodies, closures and control structure bodies do not end
   with an empty line.

Check us out on GitHub <https://github.com/CodeNarc/CodeNarc>!

The Grails CodeNarc Plugin <http://grails.org/plugin/codenarc> has been
updated to version *1.1* as well.

[Codenarc-user] [ANN] Announcing CodeNarc 1.0

[Chris M. <cm...@gm...>]

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

CodeNarc <http://codenarc.org/> is a static analysis tool for Groovy source
code.

Version *1.0* includes two new rules and several enhancements and bug fixes.
It also removes two deprecated rules and several deprecated classes. See
the full details in the release notes
<https://github.com/CodeNarc/CodeNarc/blob/master/CHANGELOG.md>.

*New Rules*

   - CouldBeSwitchStatement rule (convention) - Checks for multiple if
   statements that could be converted to a switch.
   - UnnecessarySetter rule (unnecessary) - Checks for explicit calls to
   setter methods which can be replaced by assignment to property.

Check us out on GitHub <https://github.com/CodeNarc/CodeNarc>!

The Grails CodeNarc Plugin <http://grails.org/plugin/codenarc> has been
updated to version *1.0* as well.

[Codenarc-user] Maven Plugin

[Darius C. <dar...@gm...>]

With Codehaus gone, has development stopped on the Maven plugin, or has
someone else taken it over?
(We have a project that uses Groovy extensively, and we use Maven.)
thanks

Re: [Codenarc-user] Running rules which require compilerPhase > Phases.CONVERSION using Gradle's CodeNarc plugin

[Marcin E. <mar...@pr...>]

That's great, thanks a lot.

Marcin

On Sat, 18 Mar 2017 at 16:16, Chris Mair <cm...@gm...> wrote:

> I have released and published *CodeNarc* v0.27.0, which includes your
> changes,
>
> Thanks.
> Chris
> On Sun, Mar 12, 2017 at 5:12 PM, Marcin Erdmann <mar...@pr...
> > wrote:
>
> Chris,
>
> I decided to get the necessary changes into CodeNarc first (
> https://github.com/CodeNarc/CodeNarc/pull/192) and then simply submit a
> PR for the Gradle side of things. Hopefully it will be small and obvious to
> the Gradle guys and get accepted without a need for much explanation from
> my side.
>
> Cheers,
> Marcin
>
> On Fri, Mar 10, 2017 at 6:13 PM, Chris Mair <cm...@gm...> wrote:
>
> Marcin,
>
> Yes, your proposal seems reasonable, and I am okay putting out a CodeNarc
> release afterward.
>
> Thanks for your in-depth analysis.
>
> Chris
>
> On Fri, Mar 10, 2017 at 9:53 AM, Marcin Erdmann <mar...@pr...
> > wrote:
>
> So I had a look and this is my current thinking:
>
> 1. Add a new *classpath* nested element and *classpathref* property to
> CodeNarc's ant task. They would be analogous to the ones with the same
> names defined for groovyc ant task (
> http://groovy-lang.org/groovyc.html#_ant_task) and thus use a way of
> defining classpaths ant users are familiar with (by being backed with
> org.apache.tools.ant.types.Path).
> 2. Use the newly added classpath definition to create a new
> *UrlClassLoader* with current context classloader as it's parent in
> *CodeNarcTask.execute()*. Set the newly created classloader as the
> context classloader around the call to *CodeNarcRunner.execute()*.
> 3. Get a new version of CodeNarc released so that the new functionality
> can be integrated with Gradle's CodeNarc plugin.
> 4. Add a new *FileCollection compilationClasspath* property to Gradle's
> CodeNarc task that will be used to configure *classpath* nested element
> of *CodeNarcTask* in *CodeNarcInvoker*. If the *compilationClasspath* property
> is not set then *classpath* nested element is not configured allowing for
> backwards compatibility with older CodeNarc versions.
>
> Another option would be to change which classloader is used when CodeNarc
> compiles analysed code to the one that was used to load its classes, but
> I'd rather not do that because:
> - it's a potentially breaking change
> - you should not be forced to use the same classpath for both the tool
> (Codenarc) and the classes you compile
>
> Chris, I would highly appreciate if you could confirm that you would be ok
> with such change and would be happy to do a release after it's merged in to
> unlock integrating the change with Gradle. Upon receiving a go ahead from
> you I will send a message to Gradle dev list asking if they are ok with my
> proposed change in point 4.
>
> Cheers,
> Marcin
>
> On Wed, Mar 8, 2017 at 7:56 AM, Marcin Erdmann <mar...@pr...>
> wrote:
>
> Thanks for your response, Chris.
>
> It's good to understand that using the context classloader when compiling
> analysed code is not a conscious design decision but just the way it works
> at the moment.
>
> I will do some more digging around on Friday which is my OSS day at work.
> I will check what the context classloader is set to when the extended rules
> are tested within CodeNarc's test suite and investigate if specifying a
> classpath to be used for the context classloader as part of CodeNarc's ant
> task is an option and how we would deal with that backwards incompatible
> change in Gradle's CodeNarc plugin.
>
> Cheers,
> Marcin
>
> On Wed, 8 Mar 2017 at 02:32, Chris Mair <cm...@gm...> wrote:
>
> Ugh. Sorry for the delayed response. I wasn't sure how to respond, and I
> was hoping that maybe someone else might have some useful input.
>
> I am not very familiar with the internals of the Gradle CodeNarc plugin,
> so I'm not sure what to suggest from that side.
>
> I am not philosophically opposed to changing the CodeNarc classloader, but
> I am nervous about unintended consequences. Support for the "enhanced"
> rules was a later addition, and presumably less used, though I'm still
> surprised no one else has complained about this.
>
> On Fri, Mar 3, 2017 at 8:39 AM, Marcin Erdmann <mar...@pr...>
> wrote:
>
> Hi,
>
> I wrote a custom rule which requires SEMANTIC_ANALYSIS compiler phase and
> I'm trying to run it using Gradle. Unfortunately I'm getting compilation
> errors upon analysis telling me that compiler cannot load any of the
> classes imported by the analysed code, even though I checked and they are
> available in the codenarc configuration of my project which is added by
> Gradle's CodeNarc plugin and used to load CodeNarc classes, see:
>
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/CodeNarcPlugin.java#L72
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/CodeNarcPlugin.java#L89
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/CodeNarc.java#L104
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/internal/CodeNarcInvoker.groovy#L45
>
> I then dug around and realised that when CodeNarc compiles analysed code
> it uses the context class loader, see:
> -
> https://github.com/CodeNarc/CodeNarc/blob/v0.26.0/src/main/groovy/org/codenarc/source/AbstractSourceCode.groovy#L88
> -
> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/main/org/codehaus/groovy/control/CompilationUnit.java#L94
>
> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/main/org/codehaus/groovy/control/CompilationUnit.java#L136
> -
> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/main/org/codehaus/groovy/control/ProcessingUnit.java#L64
> -
> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/main/org/codehaus/groovy/control/ProcessingUnit.java#L103
>
> And I finally realised that Gradle's BasicAntBuilder replaces the context
> class loader to only contain Ant classes which means that not even Groovy
> classes are available on the compilation classpath when CodeNarc compiles
> the analysed code:
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/internal/CodeNarcInvoker.groovy#L45
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/java/org/gradle/api/internal/project/antbuilder/DefaultIsolatedAntBuilder.java#L151
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/java/org/gradle/api/internal/project/ant/BasicAntBuilder.java#L76
>
> Given the above, here are my questions:
>
> 1. Has anybody ever managed to get their projects set up correctly and get
> violations for one of the built-in CodeNarc Enhanced Classpath Rules,
> e.g. CloneWithoutCloneable? If that's the case can they please explain how
> they achieved it? If one is to believe comments in Gradle's codebase (e.g.
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/java/org/gradle/api/internal/project/antbuilder/DefaultIsolatedAntBuilder.java#L140)
> then it looks like a similar problem to the one occurring when using Gradle
> would occur when using Ant.
>
> 2. Is there a reason for CodeNarc to use the context class loader instead
> of the class loader that loaded CodeNarc when compiling the analysed code?
> Given that it is a breaking change, would a PR changing that class loader
> to the one which loaded CodeNarc be a valid option? It is a breaking change
> but I don't see a reason why somebody would depend on current behaviour as
> it actually prevents usage of Enhanced Classpath Rules. Or should I look
> into changing Gradle's CodeNarc plugin to set the context class loader as
> per CodeNarc's expectations?
>
> Cheers,
> Marcin
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
>
>
>
>
>

Re: [Codenarc-user] Running rules which require compilerPhase > Phases.CONVERSION using Gradle's CodeNarc plugin

[Chris M. <cm...@gm...>]

I have released and published *CodeNarc* v0.27.0, which includes your
changes,

Thanks.
Chris

On Sun, Mar 12, 2017 at 5:12 PM, Marcin Erdmann <mar...@pr...>
wrote:

> Chris,
>
> I decided to get the necessary changes into CodeNarc first (
> https://github.com/CodeNarc/CodeNarc/pull/192) and then simply submit a
> PR for the Gradle side of things. Hopefully it will be small and obvious to
> the Gradle guys and get accepted without a need for much explanation from
> my side.
>
> Cheers,
> Marcin
>
> On Fri, Mar 10, 2017 at 6:13 PM, Chris Mair <cm...@gm...> wrote:
>
>> Marcin,
>>
>> Yes, your proposal seems reasonable, and I am okay putting out a CodeNarc
>> release afterward.
>>
>> Thanks for your in-depth analysis.
>>
>> Chris
>>
>> On Fri, Mar 10, 2017 at 9:53 AM, Marcin Erdmann <
>> mar...@pr...> wrote:
>>
>>> So I had a look and this is my current thinking:
>>>
>>> 1. Add a new *classpath* nested element and *classpathref* property to
>>> CodeNarc's ant task. They would be analogous to the ones with the same
>>> names defined for groovyc ant task (http://groovy-lang.org/groovy
>>> c.html#_ant_task) and thus use a way of defining classpaths ant users
>>> are familiar with (by being backed with org.apache.tools.ant.types.Pat
>>> h).
>>> 2. Use the newly added classpath definition to create a new
>>> *UrlClassLoader* with current context classloader as it's parent in
>>> *CodeNarcTask.execute()*. Set the newly created classloader as the
>>> context classloader around the call to *CodeNarcRunner.execute()*.
>>> 3. Get a new version of CodeNarc released so that the new functionality
>>> can be integrated with Gradle's CodeNarc plugin.
>>> 4. Add a new *FileCollection compilationClasspath* property to Gradle's
>>> CodeNarc task that will be used to configure *classpath* nested element
>>> of *CodeNarcTask* in *CodeNarcInvoker*. If the *compilationClasspath* property
>>> is not set then *classpath* nested element is not configured allowing
>>> for backwards compatibility with older CodeNarc versions.
>>>
>>> Another option would be to change which classloader is used when
>>> CodeNarc compiles analysed code to the one that was used to load its
>>> classes, but I'd rather not do that because:
>>> - it's a potentially breaking change
>>> - you should not be forced to use the same classpath for both the tool
>>> (Codenarc) and the classes you compile
>>>
>>> Chris, I would highly appreciate if you could confirm that you would be
>>> ok with such change and would be happy to do a release after it's merged in
>>> to unlock integrating the change with Gradle. Upon receiving a go ahead
>>> from you I will send a message to Gradle dev list asking if they are ok
>>> with my proposed change in point 4.
>>>
>>> Cheers,
>>> Marcin
>>>
>>> On Wed, Mar 8, 2017 at 7:56 AM, Marcin Erdmann <
>>> mar...@pr...> wrote:
>>>
>>>> Thanks for your response, Chris.
>>>>
>>>> It's good to understand that using the context classloader when
>>>> compiling analysed code is not a conscious design decision but just the way
>>>> it works at the moment.
>>>>
>>>> I will do some more digging around on Friday which is my OSS day at
>>>> work. I will check what the context classloader is set to when the extended
>>>> rules are tested within CodeNarc's test suite and investigate if specifying
>>>> a classpath to be used for the context classloader as part of CodeNarc's
>>>> ant task is an option and how we would deal with that backwards
>>>> incompatible change in Gradle's CodeNarc plugin.
>>>>
>>>> Cheers,
>>>> Marcin
>>>>
>>>> On Wed, 8 Mar 2017 at 02:32, Chris Mair <cm...@gm...> wrote:
>>>>
>>>>> Ugh. Sorry for the delayed response. I wasn't sure how to respond, and
>>>>> I was hoping that maybe someone else might have some useful input.
>>>>>
>>>>> I am not very familiar with the internals of the Gradle CodeNarc
>>>>> plugin, so I'm not sure what to suggest from that side.
>>>>>
>>>>> I am not philosophically opposed to changing the CodeNarc classloader,
>>>>> but I am nervous about unintended consequences. Support for the "enhanced"
>>>>> rules was a later addition, and presumably less used, though I'm still
>>>>> surprised no one else has complained about this.
>>>>>
>>>>> On Fri, Mar 3, 2017 at 8:39 AM, Marcin Erdmann <
>>>>> mar...@pr...> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I wrote a custom rule which requires SEMANTIC_ANALYSIS compiler phase
>>>>> and I'm trying to run it using Gradle. Unfortunately I'm getting
>>>>> compilation errors upon analysis telling me that compiler cannot load any
>>>>> of the classes imported by the analysed code, even though I checked and
>>>>> they are available in the codenarc configuration of my project which is
>>>>> added by Gradle's CodeNarc plugin and used to load CodeNarc classes, see:
>>>>>
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/cod
>>>>> e-quality/src/main/groovy/org/gradle/api/plugins/quality/Cod
>>>>> eNarcPlugin.java#L72
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/C
>>>>> odeNarcPlugin.java#L89
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/C
>>>>> odeNarc.java#L104
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/i
>>>>> nternal/CodeNarcInvoker.groovy#L45
>>>>>
>>>>> I then dug around and realised that when CodeNarc compiles analysed
>>>>> code it uses the context class loader, see:
>>>>> - https://github.com/CodeNarc/CodeNarc/blob/v0.26.0/src/main/g
>>>>> roovy/org/codenarc/source/AbstractSourceCode.groovy#L88
>>>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>>>> c/main/org/codehaus/groovy/control/CompilationUnit.java#L94
>>>>> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/
>>>>> main/org/codehaus/groovy/control/CompilationUnit.java#L136
>>>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>>>> c/main/org/codehaus/groovy/control/ProcessingUnit.java#L64
>>>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>>>> c/main/org/codehaus/groovy/control/ProcessingUnit.java#L103
>>>>>
>>>>> And I finally realised that Gradle's BasicAntBuilder replaces the
>>>>> context class loader to only contain Ant classes which means that not even
>>>>> Groovy classes are available on the compilation classpath when CodeNarc
>>>>> compiles the analysed code:
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/i
>>>>> nternal/CodeNarcInvoker.groovy#L45
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>> ore/src/main/java/org/gradle/api/internal/project/antbuilder
>>>>> /DefaultIsolatedAntBuilder.java#L151
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>> ore/src/main/java/org/gradle/api/internal/project/ant/BasicA
>>>>> ntBuilder.java#L76
>>>>>
>>>>> Given the above, here are my questions:
>>>>>
>>>>> 1. Has anybody ever managed to get their projects set up correctly and
>>>>> get violations for one of the built-in CodeNarc Enhanced Classpath Rules,
>>>>> e.g. CloneWithoutCloneable? If that's the case can they please explain how
>>>>> they achieved it? If one is to believe comments in Gradle's codebase (e.g.
>>>>> https://github.com/gradle/gradle/blob/v3.3.0/subprojec
>>>>> ts/core/src/main/java/org/gradle/api/internal/project/antbui
>>>>> lder/DefaultIsolatedAntBuilder.java#L140) then it looks like a
>>>>> similar problem to the one occurring when using Gradle would occur when
>>>>> using Ant.
>>>>>
>>>>> 2. Is there a reason for CodeNarc to use the context class loader
>>>>> instead of the class loader that loaded CodeNarc when compiling the
>>>>> analysed code? Given that it is a breaking change, would a PR changing that
>>>>> class loader to the one which loaded CodeNarc be a valid option? It is a
>>>>> breaking change but I don't see a reason why somebody would depend on
>>>>> current behaviour as it actually prevents usage of Enhanced Classpath
>>>>> Rules. Or should I look into changing Gradle's CodeNarc plugin to set the
>>>>> context class loader as per CodeNarc's expectations?
>>>>>
>>>>> Cheers,
>>>>> Marcin
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Codenarc-user mailing list
>>>>> Cod...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>>>>
>>>>>
>>>>>
>>>
>>
>

Re: [Codenarc-user] Running rules which require compilerPhase > Phases.CONVERSION using Gradle's CodeNarc plugin

[Marcin E. <mar...@pr...>]

Thanks, Chris, that was swift.

There's no real rush with the release, I won't be able to work on the
Gradle PR before Friday anyway but I will indeed need you to make a release
to unblock me and enable me to work on it.

Cheers,
Marcin

On Sun, Mar 12, 2017 at 11:29 PM, Chris Mair <cm...@gm...> wrote:

> Marcin,
>
> I have accepted the pull request. Thanks for the contribution.
>
> Are you now wanting me to do a CodeNarc release with this ASAP?
>
> Chris
>
> On Sun, Mar 12, 2017 at 5:12 PM, Marcin Erdmann <mar...@pr...
> > wrote:
>
>> Chris,
>>
>> I decided to get the necessary changes into CodeNarc first (
>> https://github.com/CodeNarc/CodeNarc/pull/192) and then simply submit a
>> PR for the Gradle side of things. Hopefully it will be small and obvious to
>> the Gradle guys and get accepted without a need for much explanation from
>> my side.
>>
>> Cheers,
>> Marcin
>>
>> On Fri, Mar 10, 2017 at 6:13 PM, Chris Mair <cm...@gm...> wrote:
>>
>>> Marcin,
>>>
>>> Yes, your proposal seems reasonable, and I am okay putting out a
>>> CodeNarc release afterward.
>>>
>>> Thanks for your in-depth analysis.
>>>
>>> Chris
>>>
>>> On Fri, Mar 10, 2017 at 9:53 AM, Marcin Erdmann <
>>> mar...@pr...> wrote:
>>>
>>>> So I had a look and this is my current thinking:
>>>>
>>>> 1. Add a new *classpath* nested element and *classpathref* property to
>>>> CodeNarc's ant task. They would be analogous to the ones with the same
>>>> names defined for groovyc ant task (http://groovy-lang.org/groovy
>>>> c.html#_ant_task) and thus use a way of defining classpaths ant users
>>>> are familiar with (by being backed with org.apache.tools.ant.types.Pat
>>>> h).
>>>> 2. Use the newly added classpath definition to create a new
>>>> *UrlClassLoader* with current context classloader as it's parent in
>>>> *CodeNarcTask.execute()*. Set the newly created classloader as the
>>>> context classloader around the call to *CodeNarcRunner.execute()*.
>>>> 3. Get a new version of CodeNarc released so that the new functionality
>>>> can be integrated with Gradle's CodeNarc plugin.
>>>> 4. Add a new *FileCollection compilationClasspath* property to
>>>> Gradle's CodeNarc task that will be used to configure *classpath* nested
>>>> element of *CodeNarcTask* in *CodeNarcInvoker*. If the
>>>> *compilationClasspath* property is not set then *classpath* nested
>>>> element is not configured allowing for backwards compatibility with older
>>>> CodeNarc versions.
>>>>
>>>> Another option would be to change which classloader is used when
>>>> CodeNarc compiles analysed code to the one that was used to load its
>>>> classes, but I'd rather not do that because:
>>>> - it's a potentially breaking change
>>>> - you should not be forced to use the same classpath for both the tool
>>>> (Codenarc) and the classes you compile
>>>>
>>>> Chris, I would highly appreciate if you could confirm that you would be
>>>> ok with such change and would be happy to do a release after it's merged in
>>>> to unlock integrating the change with Gradle. Upon receiving a go ahead
>>>> from you I will send a message to Gradle dev list asking if they are ok
>>>> with my proposed change in point 4.
>>>>
>>>> Cheers,
>>>> Marcin
>>>>
>>>> On Wed, Mar 8, 2017 at 7:56 AM, Marcin Erdmann <
>>>> mar...@pr...> wrote:
>>>>
>>>>> Thanks for your response, Chris.
>>>>>
>>>>> It's good to understand that using the context classloader when
>>>>> compiling analysed code is not a conscious design decision but just the way
>>>>> it works at the moment.
>>>>>
>>>>> I will do some more digging around on Friday which is my OSS day at
>>>>> work. I will check what the context classloader is set to when the extended
>>>>> rules are tested within CodeNarc's test suite and investigate if specifying
>>>>> a classpath to be used for the context classloader as part of CodeNarc's
>>>>> ant task is an option and how we would deal with that backwards
>>>>> incompatible change in Gradle's CodeNarc plugin.
>>>>>
>>>>> Cheers,
>>>>> Marcin
>>>>>
>>>>> On Wed, 8 Mar 2017 at 02:32, Chris Mair <cm...@gm...> wrote:
>>>>>
>>>>>> Ugh. Sorry for the delayed response. I wasn't sure how to respond,
>>>>>> and I was hoping that maybe someone else might have some useful input.
>>>>>>
>>>>>> I am not very familiar with the internals of the Gradle CodeNarc
>>>>>> plugin, so I'm not sure what to suggest from that side.
>>>>>>
>>>>>> I am not philosophically opposed to changing the CodeNarc
>>>>>> classloader, but I am nervous about unintended consequences. Support for
>>>>>> the "enhanced" rules was a later addition, and presumably less used, though
>>>>>> I'm still surprised no one else has complained about this.
>>>>>>
>>>>>> On Fri, Mar 3, 2017 at 8:39 AM, Marcin Erdmann <
>>>>>> mar...@pr...> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I wrote a custom rule which requires SEMANTIC_ANALYSIS compiler phase
>>>>>> and I'm trying to run it using Gradle. Unfortunately I'm getting
>>>>>> compilation errors upon analysis telling me that compiler cannot load any
>>>>>> of the classes imported by the analysed code, even though I checked and
>>>>>> they are available in the codenarc configuration of my project which is
>>>>>> added by Gradle's CodeNarc plugin and used to load CodeNarc classes, see:
>>>>>>
>>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/cod
>>>>>> e-quality/src/main/groovy/org/gradle/api/plugins/quality/Cod
>>>>>> eNarcPlugin.java#L72
>>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/C
>>>>>> odeNarcPlugin.java#L89
>>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/C
>>>>>> odeNarc.java#L104
>>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/i
>>>>>> nternal/CodeNarcInvoker.groovy#L45
>>>>>>
>>>>>> I then dug around and realised that when CodeNarc compiles analysed
>>>>>> code it uses the context class loader, see:
>>>>>> - https://github.com/CodeNarc/CodeNarc/blob/v0.26.0/src/main/g
>>>>>> roovy/org/codenarc/source/AbstractSourceCode.groovy#L88
>>>>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>>>>> c/main/org/codehaus/groovy/control/CompilationUnit.java#L94
>>>>>> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/
>>>>>> main/org/codehaus/groovy/control/CompilationUnit.java#L136
>>>>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>>>>> c/main/org/codehaus/groovy/control/ProcessingUnit.java#L64
>>>>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>>>>> c/main/org/codehaus/groovy/control/ProcessingUnit.java#L103
>>>>>>
>>>>>> And I finally realised that Gradle's BasicAntBuilder replaces the
>>>>>> context class loader to only contain Ant classes which means that not even
>>>>>> Groovy classes are available on the compilation classpath when CodeNarc
>>>>>> compiles the analysed code:
>>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/i
>>>>>> nternal/CodeNarcInvoker.groovy#L45
>>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>>> ore/src/main/java/org/gradle/api/internal/project/antbuilder
>>>>>> /DefaultIsolatedAntBuilder.java#L151
>>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>>> ore/src/main/java/org/gradle/api/internal/project/ant/BasicA
>>>>>> ntBuilder.java#L76
>>>>>>
>>>>>> Given the above, here are my questions:
>>>>>>
>>>>>> 1. Has anybody ever managed to get their projects set up correctly
>>>>>> and get violations for one of the built-in CodeNarc Enhanced Classpath
>>>>>> Rules, e.g. CloneWithoutCloneable? If that's the case can they please
>>>>>> explain how they achieved it? If one is to believe comments in Gradle's
>>>>>> codebase (e.g. https://github.com/gradle/gradle/blob/v3.3.0/subprojec
>>>>>> ts/core/src/main/java/org/gradle/api/internal/project/antbui
>>>>>> lder/DefaultIsolatedAntBuilder.java#L140) then it looks like a
>>>>>> similar problem to the one occurring when using Gradle would occur when
>>>>>> using Ant.
>>>>>>
>>>>>> 2. Is there a reason for CodeNarc to use the context class loader
>>>>>> instead of the class loader that loaded CodeNarc when compiling the
>>>>>> analysed code? Given that it is a breaking change, would a PR changing that
>>>>>> class loader to the one which loaded CodeNarc be a valid option? It is a
>>>>>> breaking change but I don't see a reason why somebody would depend on
>>>>>> current behaviour as it actually prevents usage of Enhanced Classpath
>>>>>> Rules. Or should I look into changing Gradle's CodeNarc plugin to set the
>>>>>> context class loader as per CodeNarc's expectations?
>>>>>>
>>>>>> Cheers,
>>>>>> Marcin
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------
>>>>>> ------------------
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>>> _______________________________________________
>>>>>> Codenarc-user mailing list
>>>>>> Cod...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>

Re: [Codenarc-user] Running rules which require compilerPhase > Phases.CONVERSION using Gradle's CodeNarc plugin

[Chris M. <cm...@gm...>]

Marcin,

I have accepted the pull request. Thanks for the contribution.

Are you now wanting me to do a CodeNarc release with this ASAP?

Chris

On Sun, Mar 12, 2017 at 5:12 PM, Marcin Erdmann <mar...@pr...>
wrote:

> Chris,
>
> I decided to get the necessary changes into CodeNarc first (
> https://github.com/CodeNarc/CodeNarc/pull/192) and then simply submit a
> PR for the Gradle side of things. Hopefully it will be small and obvious to
> the Gradle guys and get accepted without a need for much explanation from
> my side.
>
> Cheers,
> Marcin
>
> On Fri, Mar 10, 2017 at 6:13 PM, Chris Mair <cm...@gm...> wrote:
>
>> Marcin,
>>
>> Yes, your proposal seems reasonable, and I am okay putting out a CodeNarc
>> release afterward.
>>
>> Thanks for your in-depth analysis.
>>
>> Chris
>>
>> On Fri, Mar 10, 2017 at 9:53 AM, Marcin Erdmann <
>> mar...@pr...> wrote:
>>
>>> So I had a look and this is my current thinking:
>>>
>>> 1. Add a new *classpath* nested element and *classpathref* property to
>>> CodeNarc's ant task. They would be analogous to the ones with the same
>>> names defined for groovyc ant task (http://groovy-lang.org/groovy
>>> c.html#_ant_task) and thus use a way of defining classpaths ant users
>>> are familiar with (by being backed with org.apache.tools.ant.types.Pat
>>> h).
>>> 2. Use the newly added classpath definition to create a new
>>> *UrlClassLoader* with current context classloader as it's parent in
>>> *CodeNarcTask.execute()*. Set the newly created classloader as the
>>> context classloader around the call to *CodeNarcRunner.execute()*.
>>> 3. Get a new version of CodeNarc released so that the new functionality
>>> can be integrated with Gradle's CodeNarc plugin.
>>> 4. Add a new *FileCollection compilationClasspath* property to Gradle's
>>> CodeNarc task that will be used to configure *classpath* nested element
>>> of *CodeNarcTask* in *CodeNarcInvoker*. If the *compilationClasspath* property
>>> is not set then *classpath* nested element is not configured allowing
>>> for backwards compatibility with older CodeNarc versions.
>>>
>>> Another option would be to change which classloader is used when
>>> CodeNarc compiles analysed code to the one that was used to load its
>>> classes, but I'd rather not do that because:
>>> - it's a potentially breaking change
>>> - you should not be forced to use the same classpath for both the tool
>>> (Codenarc) and the classes you compile
>>>
>>> Chris, I would highly appreciate if you could confirm that you would be
>>> ok with such change and would be happy to do a release after it's merged in
>>> to unlock integrating the change with Gradle. Upon receiving a go ahead
>>> from you I will send a message to Gradle dev list asking if they are ok
>>> with my proposed change in point 4.
>>>
>>> Cheers,
>>> Marcin
>>>
>>> On Wed, Mar 8, 2017 at 7:56 AM, Marcin Erdmann <
>>> mar...@pr...> wrote:
>>>
>>>> Thanks for your response, Chris.
>>>>
>>>> It's good to understand that using the context classloader when
>>>> compiling analysed code is not a conscious design decision but just the way
>>>> it works at the moment.
>>>>
>>>> I will do some more digging around on Friday which is my OSS day at
>>>> work. I will check what the context classloader is set to when the extended
>>>> rules are tested within CodeNarc's test suite and investigate if specifying
>>>> a classpath to be used for the context classloader as part of CodeNarc's
>>>> ant task is an option and how we would deal with that backwards
>>>> incompatible change in Gradle's CodeNarc plugin.
>>>>
>>>> Cheers,
>>>> Marcin
>>>>
>>>> On Wed, 8 Mar 2017 at 02:32, Chris Mair <cm...@gm...> wrote:
>>>>
>>>>> Ugh. Sorry for the delayed response. I wasn't sure how to respond, and
>>>>> I was hoping that maybe someone else might have some useful input.
>>>>>
>>>>> I am not very familiar with the internals of the Gradle CodeNarc
>>>>> plugin, so I'm not sure what to suggest from that side.
>>>>>
>>>>> I am not philosophically opposed to changing the CodeNarc classloader,
>>>>> but I am nervous about unintended consequences. Support for the "enhanced"
>>>>> rules was a later addition, and presumably less used, though I'm still
>>>>> surprised no one else has complained about this.
>>>>>
>>>>> On Fri, Mar 3, 2017 at 8:39 AM, Marcin Erdmann <
>>>>> mar...@pr...> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I wrote a custom rule which requires SEMANTIC_ANALYSIS compiler phase
>>>>> and I'm trying to run it using Gradle. Unfortunately I'm getting
>>>>> compilation errors upon analysis telling me that compiler cannot load any
>>>>> of the classes imported by the analysed code, even though I checked and
>>>>> they are available in the codenarc configuration of my project which is
>>>>> added by Gradle's CodeNarc plugin and used to load CodeNarc classes, see:
>>>>>
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/cod
>>>>> e-quality/src/main/groovy/org/gradle/api/plugins/quality/Cod
>>>>> eNarcPlugin.java#L72
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/C
>>>>> odeNarcPlugin.java#L89
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/C
>>>>> odeNarc.java#L104
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/i
>>>>> nternal/CodeNarcInvoker.groovy#L45
>>>>>
>>>>> I then dug around and realised that when CodeNarc compiles analysed
>>>>> code it uses the context class loader, see:
>>>>> - https://github.com/CodeNarc/CodeNarc/blob/v0.26.0/src/main/g
>>>>> roovy/org/codenarc/source/AbstractSourceCode.groovy#L88
>>>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>>>> c/main/org/codehaus/groovy/control/CompilationUnit.java#L94
>>>>> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/
>>>>> main/org/codehaus/groovy/control/CompilationUnit.java#L136
>>>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>>>> c/main/org/codehaus/groovy/control/ProcessingUnit.java#L64
>>>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>>>> c/main/org/codehaus/groovy/control/ProcessingUnit.java#L103
>>>>>
>>>>> And I finally realised that Gradle's BasicAntBuilder replaces the
>>>>> context class loader to only contain Ant classes which means that not even
>>>>> Groovy classes are available on the compilation classpath when CodeNarc
>>>>> compiles the analysed code:
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/i
>>>>> nternal/CodeNarcInvoker.groovy#L45
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>> ore/src/main/java/org/gradle/api/internal/project/antbuilder
>>>>> /DefaultIsolatedAntBuilder.java#L151
>>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>>> ore/src/main/java/org/gradle/api/internal/project/ant/BasicA
>>>>> ntBuilder.java#L76
>>>>>
>>>>> Given the above, here are my questions:
>>>>>
>>>>> 1. Has anybody ever managed to get their projects set up correctly and
>>>>> get violations for one of the built-in CodeNarc Enhanced Classpath Rules,
>>>>> e.g. CloneWithoutCloneable? If that's the case can they please explain how
>>>>> they achieved it? If one is to believe comments in Gradle's codebase (e.g.
>>>>> https://github.com/gradle/gradle/blob/v3.3.0/subprojec
>>>>> ts/core/src/main/java/org/gradle/api/internal/project/antbui
>>>>> lder/DefaultIsolatedAntBuilder.java#L140) then it looks like a
>>>>> similar problem to the one occurring when using Gradle would occur when
>>>>> using Ant.
>>>>>
>>>>> 2. Is there a reason for CodeNarc to use the context class loader
>>>>> instead of the class loader that loaded CodeNarc when compiling the
>>>>> analysed code? Given that it is a breaking change, would a PR changing that
>>>>> class loader to the one which loaded CodeNarc be a valid option? It is a
>>>>> breaking change but I don't see a reason why somebody would depend on
>>>>> current behaviour as it actually prevents usage of Enhanced Classpath
>>>>> Rules. Or should I look into changing Gradle's CodeNarc plugin to set the
>>>>> context class loader as per CodeNarc's expectations?
>>>>>
>>>>> Cheers,
>>>>> Marcin
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Codenarc-user mailing list
>>>>> Cod...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>>>>
>>>>>
>>>>>
>>>
>>
>

Re: [Codenarc-user] Running rules which require compilerPhase > Phases.CONVERSION using Gradle's CodeNarc plugin

[Marcin E. <mar...@pr...>]

Chris,

I decided to get the necessary changes into CodeNarc first (
https://github.com/CodeNarc/CodeNarc/pull/192) and then simply submit a PR
for the Gradle side of things. Hopefully it will be small and obvious to
the Gradle guys and get accepted without a need for much explanation from
my side.

Cheers,
Marcin

On Fri, Mar 10, 2017 at 6:13 PM, Chris Mair <cm...@gm...> wrote:

> Marcin,
>
> Yes, your proposal seems reasonable, and I am okay putting out a CodeNarc
> release afterward.
>
> Thanks for your in-depth analysis.
>
> Chris
>
> On Fri, Mar 10, 2017 at 9:53 AM, Marcin Erdmann <mar...@pr...
> > wrote:
>
>> So I had a look and this is my current thinking:
>>
>> 1. Add a new *classpath* nested element and *classpathref* property to
>> CodeNarc's ant task. They would be analogous to the ones with the same
>> names defined for groovyc ant task (http://groovy-lang.org/groovy
>> c.html#_ant_task) and thus use a way of defining classpaths ant users
>> are familiar with (by being backed with org.apache.tools.ant.types.Path).
>> 2. Use the newly added classpath definition to create a new
>> *UrlClassLoader* with current context classloader as it's parent in
>> *CodeNarcTask.execute()*. Set the newly created classloader as the
>> context classloader around the call to *CodeNarcRunner.execute()*.
>> 3. Get a new version of CodeNarc released so that the new functionality
>> can be integrated with Gradle's CodeNarc plugin.
>> 4. Add a new *FileCollection compilationClasspath* property to Gradle's
>> CodeNarc task that will be used to configure *classpath* nested element
>> of *CodeNarcTask* in *CodeNarcInvoker*. If the *compilationClasspath* property
>> is not set then *classpath* nested element is not configured allowing
>> for backwards compatibility with older CodeNarc versions.
>>
>> Another option would be to change which classloader is used when CodeNarc
>> compiles analysed code to the one that was used to load its classes, but
>> I'd rather not do that because:
>> - it's a potentially breaking change
>> - you should not be forced to use the same classpath for both the tool
>> (Codenarc) and the classes you compile
>>
>> Chris, I would highly appreciate if you could confirm that you would be
>> ok with such change and would be happy to do a release after it's merged in
>> to unlock integrating the change with Gradle. Upon receiving a go ahead
>> from you I will send a message to Gradle dev list asking if they are ok
>> with my proposed change in point 4.
>>
>> Cheers,
>> Marcin
>>
>> On Wed, Mar 8, 2017 at 7:56 AM, Marcin Erdmann <mar...@pr...
>> > wrote:
>>
>>> Thanks for your response, Chris.
>>>
>>> It's good to understand that using the context classloader when
>>> compiling analysed code is not a conscious design decision but just the way
>>> it works at the moment.
>>>
>>> I will do some more digging around on Friday which is my OSS day at
>>> work. I will check what the context classloader is set to when the extended
>>> rules are tested within CodeNarc's test suite and investigate if specifying
>>> a classpath to be used for the context classloader as part of CodeNarc's
>>> ant task is an option and how we would deal with that backwards
>>> incompatible change in Gradle's CodeNarc plugin.
>>>
>>> Cheers,
>>> Marcin
>>>
>>> On Wed, 8 Mar 2017 at 02:32, Chris Mair <cm...@gm...> wrote:
>>>
>>>> Ugh. Sorry for the delayed response. I wasn't sure how to respond, and
>>>> I was hoping that maybe someone else might have some useful input.
>>>>
>>>> I am not very familiar with the internals of the Gradle CodeNarc
>>>> plugin, so I'm not sure what to suggest from that side.
>>>>
>>>> I am not philosophically opposed to changing the CodeNarc classloader,
>>>> but I am nervous about unintended consequences. Support for the "enhanced"
>>>> rules was a later addition, and presumably less used, though I'm still
>>>> surprised no one else has complained about this.
>>>>
>>>> On Fri, Mar 3, 2017 at 8:39 AM, Marcin Erdmann <
>>>> mar...@pr...> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I wrote a custom rule which requires SEMANTIC_ANALYSIS compiler phase
>>>> and I'm trying to run it using Gradle. Unfortunately I'm getting
>>>> compilation errors upon analysis telling me that compiler cannot load any
>>>> of the classes imported by the analysed code, even though I checked and
>>>> they are available in the codenarc configuration of my project which is
>>>> added by Gradle's CodeNarc plugin and used to load CodeNarc classes, see:
>>>>
>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/cod
>>>> e-quality/src/main/groovy/org/gradle/api/plugins/quality/
>>>> CodeNarcPlugin.java#L72
>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/
>>>> CodeNarcPlugin.java#L89
>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/
>>>> CodeNarc.java#L104
>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/
>>>> internal/CodeNarcInvoker.groovy#L45
>>>>
>>>> I then dug around and realised that when CodeNarc compiles analysed
>>>> code it uses the context class loader, see:
>>>> - https://github.com/CodeNarc/CodeNarc/blob/v0.26.0/src/main/g
>>>> roovy/org/codenarc/source/AbstractSourceCode.groovy#L88
>>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>>> c/main/org/codehaus/groovy/control/CompilationUnit.java#L94
>>>> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/
>>>> main/org/codehaus/groovy/control/CompilationUnit.java#L136
>>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>>> c/main/org/codehaus/groovy/control/ProcessingUnit.java#L64
>>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>>> c/main/org/codehaus/groovy/control/ProcessingUnit.java#L103
>>>>
>>>> And I finally realised that Gradle's BasicAntBuilder replaces the
>>>> context class loader to only contain Ant classes which means that not even
>>>> Groovy classes are available on the compilation classpath when CodeNarc
>>>> compiles the analysed code:
>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>> ode-quality/src/main/groovy/org/gradle/api/plugins/quality/
>>>> internal/CodeNarcInvoker.groovy#L45
>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>> ore/src/main/java/org/gradle/api/internal/project/antbuilder
>>>> /DefaultIsolatedAntBuilder.java#L151
>>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/c
>>>> ore/src/main/java/org/gradle/api/internal/project/ant/BasicA
>>>> ntBuilder.java#L76
>>>>
>>>> Given the above, here are my questions:
>>>>
>>>> 1. Has anybody ever managed to get their projects set up correctly and
>>>> get violations for one of the built-in CodeNarc Enhanced Classpath Rules,
>>>> e.g. CloneWithoutCloneable? If that's the case can they please explain how
>>>> they achieved it? If one is to believe comments in Gradle's codebase (e.g.
>>>> https://github.com/gradle/gradle/blob/v3.3.0/subprojec
>>>> ts/core/src/main/java/org/gradle/api/internal/project/antbui
>>>> lder/DefaultIsolatedAntBuilder.java#L140) then it looks like a similar
>>>> problem to the one occurring when using Gradle would occur when using Ant.
>>>>
>>>> 2. Is there a reason for CodeNarc to use the context class loader
>>>> instead of the class loader that loaded CodeNarc when compiling the
>>>> analysed code? Given that it is a breaking change, would a PR changing that
>>>> class loader to the one which loaded CodeNarc be a valid option? It is a
>>>> breaking change but I don't see a reason why somebody would depend on
>>>> current behaviour as it actually prevents usage of Enhanced Classpath
>>>> Rules. Or should I look into changing Gradle's CodeNarc plugin to set the
>>>> context class loader as per CodeNarc's expectations?
>>>>
>>>> Cheers,
>>>> Marcin
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Codenarc-user mailing list
>>>> Cod...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>>>
>>>>
>>>>
>>
>

Re: [Codenarc-user] Running rules which require compilerPhase > Phases.CONVERSION using Gradle's CodeNarc plugin

[Chris M. <cm...@gm...>]

Marcin,

Yes, your proposal seems reasonable, and I am okay putting out a CodeNarc
release afterward.

Thanks for your in-depth analysis.

Chris

On Fri, Mar 10, 2017 at 9:53 AM, Marcin Erdmann <mar...@pr...>
wrote:

> So I had a look and this is my current thinking:
>
> 1. Add a new *classpath* nested element and *classpathref* property to
> CodeNarc's ant task. They would be analogous to the ones with the same
> names defined for groovyc ant task (http://groovy-lang.org/
> groovyc.html#_ant_task) and thus use a way of defining classpaths ant
> users are familiar with (by being backed with org.apache.tools.ant.types.
> Path).
> 2. Use the newly added classpath definition to create a new
> *UrlClassLoader* with current context classloader as it's parent in
> *CodeNarcTask.execute()*. Set the newly created classloader as the
> context classloader around the call to *CodeNarcRunner.execute()*.
> 3. Get a new version of CodeNarc released so that the new functionality
> can be integrated with Gradle's CodeNarc plugin.
> 4. Add a new *FileCollection compilationClasspath* property to Gradle's
> CodeNarc task that will be used to configure *classpath* nested element
> of *CodeNarcTask* in *CodeNarcInvoker*. If the *compilationClasspath* property
> is not set then *classpath* nested element is not configured allowing for
> backwards compatibility with older CodeNarc versions.
>
> Another option would be to change which classloader is used when CodeNarc
> compiles analysed code to the one that was used to load its classes, but
> I'd rather not do that because:
> - it's a potentially breaking change
> - you should not be forced to use the same classpath for both the tool
> (Codenarc) and the classes you compile
>
> Chris, I would highly appreciate if you could confirm that you would be ok
> with such change and would be happy to do a release after it's merged in to
> unlock integrating the change with Gradle. Upon receiving a go ahead from
> you I will send a message to Gradle dev list asking if they are ok with my
> proposed change in point 4.
>
> Cheers,
> Marcin
>
> On Wed, Mar 8, 2017 at 7:56 AM, Marcin Erdmann <mar...@pr...>
> wrote:
>
>> Thanks for your response, Chris.
>>
>> It's good to understand that using the context classloader when compiling
>> analysed code is not a conscious design decision but just the way it works
>> at the moment.
>>
>> I will do some more digging around on Friday which is my OSS day at work.
>> I will check what the context classloader is set to when the extended rules
>> are tested within CodeNarc's test suite and investigate if specifying a
>> classpath to be used for the context classloader as part of CodeNarc's ant
>> task is an option and how we would deal with that backwards incompatible
>> change in Gradle's CodeNarc plugin.
>>
>> Cheers,
>> Marcin
>>
>> On Wed, 8 Mar 2017 at 02:32, Chris Mair <cm...@gm...> wrote:
>>
>>> Ugh. Sorry for the delayed response. I wasn't sure how to respond, and I
>>> was hoping that maybe someone else might have some useful input.
>>>
>>> I am not very familiar with the internals of the Gradle CodeNarc plugin,
>>> so I'm not sure what to suggest from that side.
>>>
>>> I am not philosophically opposed to changing the CodeNarc classloader,
>>> but I am nervous about unintended consequences. Support for the "enhanced"
>>> rules was a later addition, and presumably less used, though I'm still
>>> surprised no one else has complained about this.
>>>
>>> On Fri, Mar 3, 2017 at 8:39 AM, Marcin Erdmann <
>>> mar...@pr...> wrote:
>>>
>>> Hi,
>>>
>>> I wrote a custom rule which requires SEMANTIC_ANALYSIS compiler phase
>>> and I'm trying to run it using Gradle. Unfortunately I'm getting
>>> compilation errors upon analysis telling me that compiler cannot load any
>>> of the classes imported by the analysed code, even though I checked and
>>> they are available in the codenarc configuration of my project which is
>>> added by Gradle's CodeNarc plugin and used to load CodeNarc classes, see:
>>>
>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/
>>> code-quality/src/main/groovy/org/gradle/api/plugins/
>>> quality/CodeNarcPlugin.java#L72
>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/
>>> code-quality/src/main/groovy/org/gradle/api/plugins/
>>> quality/CodeNarcPlugin.java#L89
>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/
>>> code-quality/src/main/groovy/org/gradle/api/plugins/
>>> quality/CodeNarc.java#L104
>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/
>>> code-quality/src/main/groovy/org/gradle/api/plugins/
>>> quality/internal/CodeNarcInvoker.groovy#L45
>>>
>>> I then dug around and realised that when CodeNarc compiles analysed code
>>> it uses the context class loader, see:
>>> - https://github.com/CodeNarc/CodeNarc/blob/v0.26.0/src/main/
>>> groovy/org/codenarc/source/AbstractSourceCode.groovy#L88
>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>> c/main/org/codehaus/groovy/control/CompilationUnit.java#L94
>>> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/
>>> main/org/codehaus/groovy/control/CompilationUnit.java#L136
>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>> c/main/org/codehaus/groovy/control/ProcessingUnit.java#L64
>>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/sr
>>> c/main/org/codehaus/groovy/control/ProcessingUnit.java#L103
>>>
>>> And I finally realised that Gradle's BasicAntBuilder replaces the
>>> context class loader to only contain Ant classes which means that not even
>>> Groovy classes are available on the compilation classpath when CodeNarc
>>> compiles the analysed code:
>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/
>>> code-quality/src/main/groovy/org/gradle/api/plugins/
>>> quality/internal/CodeNarcInvoker.groovy#L45
>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/
>>> core/src/main/java/org/gradle/api/internal/project/
>>> antbuilder/DefaultIsolatedAntBuilder.java#L151
>>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/
>>> core/src/main/java/org/gradle/api/internal/project/ant/
>>> BasicAntBuilder.java#L76
>>>
>>> Given the above, here are my questions:
>>>
>>> 1. Has anybody ever managed to get their projects set up correctly and
>>> get violations for one of the built-in CodeNarc Enhanced Classpath Rules,
>>> e.g. CloneWithoutCloneable? If that's the case can they please explain how
>>> they achieved it? If one is to believe comments in Gradle's codebase (e.g.
>>> https://github.com/gradle/gradle/blob/v3.3.0/subprojec
>>> ts/core/src/main/java/org/gradle/api/internal/project/
>>> antbuilder/DefaultIsolatedAntBuilder.java#L140) then it looks like a
>>> similar problem to the one occurring when using Gradle would occur when
>>> using Ant.
>>>
>>> 2. Is there a reason for CodeNarc to use the context class loader
>>> instead of the class loader that loaded CodeNarc when compiling the
>>> analysed code? Given that it is a breaking change, would a PR changing that
>>> class loader to the one which loaded CodeNarc be a valid option? It is a
>>> breaking change but I don't see a reason why somebody would depend on
>>> current behaviour as it actually prevents usage of Enhanced Classpath
>>> Rules. Or should I look into changing Gradle's CodeNarc plugin to set the
>>> context class loader as per CodeNarc's expectations?
>>>
>>> Cheers,
>>> Marcin
>>>
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Codenarc-user mailing list
>>> Cod...@li...
>>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>>
>>>
>>>
>

Re: [Codenarc-user] Running rules which require compilerPhase > Phases.CONVERSION using Gradle's CodeNarc plugin

[Marcin E. <mar...@pr...>]

So I had a look and this is my current thinking:

1. Add a new *classpath* nested element and *classpathref* property to
CodeNarc's ant task. They would be analogous to the ones with the same
names defined for groovyc ant task (
http://groovy-lang.org/groovyc.html#_ant_task) and thus use a way of
defining classpaths ant users are familiar with (by being backed with
org.apache.tools.ant.types.Path).
2. Use the newly added classpath definition to create a new *UrlClassLoader*
with current context classloader as it's parent in *CodeNarcTask.execute()*.
Set the newly created classloader as the context classloader around the
call to *CodeNarcRunner.execute()*.
3. Get a new version of CodeNarc released so that the new functionality can
be integrated with Gradle's CodeNarc plugin.
4. Add a new *FileCollection compilationClasspath* property to Gradle's
CodeNarc task that will be used to configure *classpath* nested element of
*CodeNarcTask* in *CodeNarcInvoker*. If the *compilationClasspath* property
is not set then *classpath* nested element is not configured allowing for
backwards compatibility with older CodeNarc versions.

Another option would be to change which classloader is used when CodeNarc
compiles analysed code to the one that was used to load its classes, but
I'd rather not do that because:
- it's a potentially breaking change
- you should not be forced to use the same classpath for both the tool
(Codenarc) and the classes you compile

Chris, I would highly appreciate if you could confirm that you would be ok
with such change and would be happy to do a release after it's merged in to
unlock integrating the change with Gradle. Upon receiving a go ahead from
you I will send a message to Gradle dev list asking if they are ok with my
proposed change in point 4.

Cheers,
Marcin

On Wed, Mar 8, 2017 at 7:56 AM, Marcin Erdmann <mar...@pr...>
wrote:

> Thanks for your response, Chris.
>
> It's good to understand that using the context classloader when compiling
> analysed code is not a conscious design decision but just the way it works
> at the moment.
>
> I will do some more digging around on Friday which is my OSS day at work.
> I will check what the context classloader is set to when the extended rules
> are tested within CodeNarc's test suite and investigate if specifying a
> classpath to be used for the context classloader as part of CodeNarc's ant
> task is an option and how we would deal with that backwards incompatible
> change in Gradle's CodeNarc plugin.
>
> Cheers,
> Marcin
>
> On Wed, 8 Mar 2017 at 02:32, Chris Mair <cm...@gm...> wrote:
>
>> Ugh. Sorry for the delayed response. I wasn't sure how to respond, and I
>> was hoping that maybe someone else might have some useful input.
>>
>> I am not very familiar with the internals of the Gradle CodeNarc plugin,
>> so I'm not sure what to suggest from that side.
>>
>> I am not philosophically opposed to changing the CodeNarc classloader,
>> but I am nervous about unintended consequences. Support for the "enhanced"
>> rules was a later addition, and presumably less used, though I'm still
>> surprised no one else has complained about this.
>>
>> On Fri, Mar 3, 2017 at 8:39 AM, Marcin Erdmann <mar...@pr...
>> > wrote:
>>
>> Hi,
>>
>> I wrote a custom rule which requires SEMANTIC_ANALYSIS compiler phase and
>> I'm trying to run it using Gradle. Unfortunately I'm getting compilation
>> errors upon analysis telling me that compiler cannot load any of the
>> classes imported by the analysed code, even though I checked and they are
>> available in the codenarc configuration of my project which is added by
>> Gradle's CodeNarc plugin and used to load CodeNarc classes, see:
>>
>> - https://github.com/gradle/gradle/blob/v3.3.0/
>> subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/
>> CodeNarcPlugin.java#L72
>> - https://github.com/gradle/gradle/blob/v3.3.0/
>> subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/
>> CodeNarcPlugin.java#L89
>> - https://github.com/gradle/gradle/blob/v3.3.0/
>> subprojects/code-quality/src/main/groovy/org/gradle/api/
>> plugins/quality/CodeNarc.java#L104
>> - https://github.com/gradle/gradle/blob/v3.3.0/
>> subprojects/code-quality/src/main/groovy/org/gradle/api/
>> plugins/quality/internal/CodeNarcInvoker.groovy#L45
>>
>> I then dug around and realised that when CodeNarc compiles analysed code
>> it uses the context class loader, see:
>> - https://github.com/CodeNarc/CodeNarc/blob/v0.26.0/src/
>> main/groovy/org/codenarc/source/AbstractSourceCode.groovy#L88
>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/
>> src/main/org/codehaus/groovy/control/CompilationUnit.java#L94
>> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/
>> src/main/org/codehaus/groovy/control/CompilationUnit.java#L136
>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/
>> src/main/org/codehaus/groovy/control/ProcessingUnit.java#L64
>> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/
>> src/main/org/codehaus/groovy/control/ProcessingUnit.java#L103
>>
>> And I finally realised that Gradle's BasicAntBuilder replaces the context
>> class loader to only contain Ant classes which means that not even Groovy
>> classes are available on the compilation classpath when CodeNarc compiles
>> the analysed code:
>> - https://github.com/gradle/gradle/blob/v3.3.0/
>> subprojects/code-quality/src/main/groovy/org/gradle/api/
>> plugins/quality/internal/CodeNarcInvoker.groovy#L45
>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/
>> java/org/gradle/api/internal/project/antbuilder/
>> DefaultIsolatedAntBuilder.java#L151
>> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/
>> java/org/gradle/api/internal/project/ant/BasicAntBuilder.java#L76
>>
>> Given the above, here are my questions:
>>
>> 1. Has anybody ever managed to get their projects set up correctly and
>> get violations for one of the built-in CodeNarc Enhanced Classpath Rules,
>> e.g. CloneWithoutCloneable? If that's the case can they please explain how
>> they achieved it? If one is to believe comments in Gradle's codebase (e.g.
>> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/
>> java/org/gradle/api/internal/project/antbuilder/
>> DefaultIsolatedAntBuilder.java#L140) then it looks like a similar
>> problem to the one occurring when using Gradle would occur when using Ant.
>>
>> 2. Is there a reason for CodeNarc to use the context class loader instead
>> of the class loader that loaded CodeNarc when compiling the analysed code?
>> Given that it is a breaking change, would a PR changing that class loader
>> to the one which loaded CodeNarc be a valid option? It is a breaking change
>> but I don't see a reason why somebody would depend on current behaviour as
>> it actually prevents usage of Enhanced Classpath Rules. Or should I look
>> into changing Gradle's CodeNarc plugin to set the context class loader as
>> per CodeNarc's expectations?
>>
>> Cheers,
>> Marcin
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Codenarc-user mailing list
>> Cod...@li...
>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>
>>
>>

Re: [Codenarc-user] Running rules which require compilerPhase > Phases.CONVERSION using Gradle's CodeNarc plugin

[Marcin E. <mar...@pr...>]

Thanks for your response, Chris.

It's good to understand that using the context classloader when compiling
analysed code is not a conscious design decision but just the way it works
at the moment.

I will do some more digging around on Friday which is my OSS day at work. I
will check what the context classloader is set to when the extended rules
are tested within CodeNarc's test suite and investigate if specifying a
classpath to be used for the context classloader as part of CodeNarc's ant
task is an option and how we would deal with that backwards incompatible
change in Gradle's CodeNarc plugin.

Cheers,
Marcin

On Wed, 8 Mar 2017 at 02:32, Chris Mair <cm...@gm...> wrote:

> Ugh. Sorry for the delayed response. I wasn't sure how to respond, and I
> was hoping that maybe someone else might have some useful input.
>
> I am not very familiar with the internals of the Gradle CodeNarc plugin,
> so I'm not sure what to suggest from that side.
>
> I am not philosophically opposed to changing the CodeNarc classloader, but
> I am nervous about unintended consequences. Support for the "enhanced"
> rules was a later addition, and presumably less used, though I'm still
> surprised no one else has complained about this.
>
> On Fri, Mar 3, 2017 at 8:39 AM, Marcin Erdmann <mar...@pr...>
> wrote:
>
> Hi,
>
> I wrote a custom rule which requires SEMANTIC_ANALYSIS compiler phase and
> I'm trying to run it using Gradle. Unfortunately I'm getting compilation
> errors upon analysis telling me that compiler cannot load any of the
> classes imported by the analysed code, even though I checked and they are
> available in the codenarc configuration of my project which is added by
> Gradle's CodeNarc plugin and used to load CodeNarc classes, see:
>
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/CodeNarcPlugin.java#L72
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/CodeNarcPlugin.java#L89
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/CodeNarc.java#L104
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/internal/CodeNarcInvoker.groovy#L45
>
> I then dug around and realised that when CodeNarc compiles analysed code
> it uses the context class loader, see:
> -
> https://github.com/CodeNarc/CodeNarc/blob/v0.26.0/src/main/groovy/org/codenarc/source/AbstractSourceCode.groovy#L88
> -
> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/main/org/codehaus/groovy/control/CompilationUnit.java#L94
>
> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/main/org/codehaus/groovy/control/CompilationUnit.java#L136
> -
> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/main/org/codehaus/groovy/control/ProcessingUnit.java#L64
> -
> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/main/org/codehaus/groovy/control/ProcessingUnit.java#L103
>
> And I finally realised that Gradle's BasicAntBuilder replaces the context
> class loader to only contain Ant classes which means that not even Groovy
> classes are available on the compilation classpath when CodeNarc compiles
> the analysed code:
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/internal/CodeNarcInvoker.groovy#L45
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/java/org/gradle/api/internal/project/antbuilder/DefaultIsolatedAntBuilder.java#L151
> -
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/java/org/gradle/api/internal/project/ant/BasicAntBuilder.java#L76
>
> Given the above, here are my questions:
>
> 1. Has anybody ever managed to get their projects set up correctly and get
> violations for one of the built-in CodeNarc Enhanced Classpath Rules,
> e.g. CloneWithoutCloneable? If that's the case can they please explain how
> they achieved it? If one is to believe comments in Gradle's codebase (e.g.
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/java/org/gradle/api/internal/project/antbuilder/DefaultIsolatedAntBuilder.java#L140)
> then it looks like a similar problem to the one occurring when using Gradle
> would occur when using Ant.
>
> 2. Is there a reason for CodeNarc to use the context class loader instead
> of the class loader that loaded CodeNarc when compiling the analysed code?
> Given that it is a breaking change, would a PR changing that class loader
> to the one which loaded CodeNarc be a valid option? It is a breaking change
> but I don't see a reason why somebody would depend on current behaviour as
> it actually prevents usage of Enhanced Classpath Rules. Or should I look
> into changing Gradle's CodeNarc plugin to set the context class loader as
> per CodeNarc's expectations?
>
> Cheers,
> Marcin
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
>
>

Re: [Codenarc-user] Running rules which require compilerPhase > Phases.CONVERSION using Gradle's CodeNarc plugin

[Chris M. <cm...@gm...>]

Ugh. Sorry for the delayed response. I wasn't sure how to respond, and I
was hoping that maybe someone else might have some useful input.

I am not very familiar with the internals of the Gradle CodeNarc plugin, so
I'm not sure what to suggest from that side.

I am not philosophically opposed to changing the CodeNarc classloader, but
I am nervous about unintended consequences. Support for the "enhanced"
rules was a later addition, and presumably less used, though I'm still
surprised no one else has complained about this.

On Fri, Mar 3, 2017 at 8:39 AM, Marcin Erdmann <mar...@pr...>
wrote:

> Hi,
>
> I wrote a custom rule which requires SEMANTIC_ANALYSIS compiler phase and
> I'm trying to run it using Gradle. Unfortunately I'm getting compilation
> errors upon analysis telling me that compiler cannot load any of the
> classes imported by the analysed code, even though I checked and they are
> available in the codenarc configuration of my project which is added by
> Gradle's CodeNarc plugin and used to load CodeNarc classes, see:
>
> - https://github.com/gradle/gradle/blob/v3.3.0/
> subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/
> CodeNarcPlugin.java#L72
> - https://github.com/gradle/gradle/blob/v3.3.0/
> subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/
> CodeNarcPlugin.java#L89
> - https://github.com/gradle/gradle/blob/v3.3.0/
> subprojects/code-quality/src/main/groovy/org/gradle/api/
> plugins/quality/CodeNarc.java#L104
> - https://github.com/gradle/gradle/blob/v3.3.0/
> subprojects/code-quality/src/main/groovy/org/gradle/api/
> plugins/quality/internal/CodeNarcInvoker.groovy#L45
>
> I then dug around and realised that when CodeNarc compiles analysed code
> it uses the context class loader, see:
> - https://github.com/CodeNarc/CodeNarc/blob/v0.26.0/src/
> main/groovy/org/codenarc/source/AbstractSourceCode.groovy#L88
> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/
> src/main/org/codehaus/groovy/control/CompilationUnit.java#L94
> https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/
> src/main/org/codehaus/groovy/control/CompilationUnit.java#L136
> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/
> src/main/org/codehaus/groovy/control/ProcessingUnit.java#L64
> - https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/
> src/main/org/codehaus/groovy/control/ProcessingUnit.java#L103
>
> And I finally realised that Gradle's BasicAntBuilder replaces the context
> class loader to only contain Ant classes which means that not even Groovy
> classes are available on the compilation classpath when CodeNarc compiles
> the analysed code:
> - https://github.com/gradle/gradle/blob/v3.3.0/
> subprojects/code-quality/src/main/groovy/org/gradle/api/
> plugins/quality/internal/CodeNarcInvoker.groovy#L45
> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/
> java/org/gradle/api/internal/project/antbuilder/DefaultIsolatedAntBuilder.
> java#L151
> - https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/
> java/org/gradle/api/internal/project/ant/BasicAntBuilder.java#L76
>
> Given the above, here are my questions:
>
> 1. Has anybody ever managed to get their projects set up correctly and get
> violations for one of the built-in CodeNarc Enhanced Classpath Rules,
> e.g. CloneWithoutCloneable? If that's the case can they please explain how
> they achieved it? If one is to believe comments in Gradle's codebase (e.g.
> https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/
> java/org/gradle/api/internal/project/antbuilder/DefaultIsolatedAntBuilder.
> java#L140) then it looks like a similar problem to the one occurring when
> using Gradle would occur when using Ant.
>
> 2. Is there a reason for CodeNarc to use the context class loader instead
> of the class loader that loaded CodeNarc when compiling the analysed code?
> Given that it is a breaking change, would a PR changing that class loader
> to the one which loaded CodeNarc be a valid option? It is a breaking change
> but I don't see a reason why somebody would depend on current behaviour as
> it actually prevents usage of Enhanced Classpath Rules. Or should I look
> into changing Gradle's CodeNarc plugin to set the context class loader as
> per CodeNarc's expectations?
>
> Cheers,
> Marcin
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
>

[Codenarc-user] Running rules which require compilerPhase > Phases.CONVERSION using Gradle's CodeNarc plugin

[Marcin E. <mar...@pr...>]

Hi,

I wrote a custom rule which requires SEMANTIC_ANALYSIS compiler phase and
I'm trying to run it using Gradle. Unfortunately I'm getting compilation
errors upon analysis telling me that compiler cannot load any of the
classes imported by the analysed code, even though I checked and they are
available in the codenarc configuration of my project which is added by
Gradle's CodeNarc plugin and used to load CodeNarc classes, see:

-
https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/CodeNarcPlugin.java#L72
-
https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/CodeNarcPlugin.java#L89
-
https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/CodeNarc.java#L104
-
https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/internal/CodeNarcInvoker.groovy#L45

I then dug around and realised that when CodeNarc compiles analysed code it
uses the context class loader, see:
-
https://github.com/CodeNarc/CodeNarc/blob/v0.26.0/src/main/groovy/org/codenarc/source/AbstractSourceCode.groovy#L88
-
https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/main/org/codehaus/groovy/control/CompilationUnit.java#L94
https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/main/org/codehaus/groovy/control/CompilationUnit.java#L136
-
https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/main/org/codehaus/groovy/control/ProcessingUnit.java#L64
-
https://github.com/groovy/groovy-core/blob/GROOVY_2_1_8/src/main/org/codehaus/groovy/control/ProcessingUnit.java#L103

And I finally realised that Gradle's BasicAntBuilder replaces the context
class loader to only contain Ant classes which means that not even Groovy
classes are available on the compilation classpath when CodeNarc compiles
the analysed code:
-
https://github.com/gradle/gradle/blob/v3.3.0/subprojects/code-quality/src/main/groovy/org/gradle/api/plugins/quality/internal/CodeNarcInvoker.groovy#L45
-
https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/java/org/gradle/api/internal/project/antbuilder/DefaultIsolatedAntBuilder.java#L151
-
https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/java/org/gradle/api/internal/project/ant/BasicAntBuilder.java#L76

Given the above, here are my questions:

1. Has anybody ever managed to get their projects set up correctly and get
violations for one of the built-in CodeNarc Enhanced Classpath Rules,
e.g. CloneWithoutCloneable? If that's the case can they please explain how
they achieved it? If one is to believe comments in Gradle's codebase (e.g.
https://github.com/gradle/gradle/blob/v3.3.0/subprojects/core/src/main/java/org/gradle/api/internal/project/antbuilder/DefaultIsolatedAntBuilder.java#L140)
then it looks like a similar problem to the one occurring when using Gradle
would occur when using Ant.

2. Is there a reason for CodeNarc to use the context class loader instead
of the class loader that loaded CodeNarc when compiling the analysed code?
Given that it is a breaking change, would a PR changing that class loader
to the one which loaded CodeNarc be a valid option? It is a breaking change
but I don't see a reason why somebody would depend on current behaviour as
it actually prevents usage of Enhanced Classpath Rules. Or should I look
into changing Gradle's CodeNarc plugin to set the context class loader as
per CodeNarc's expectations?

Cheers,
Marcin

[Codenarc-user] [ANN] Announcing CodeNarc 0.26.0

[Chris M. <cm...@gm...>]

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

CodeNarc <http://codenarc.sourceforge.net/> is a static analysis tool for
Groovy source code.

Version *0.26.0* includes several bug fixes and other enhancements.

See the full details in the release notes
<https://github.com/CodeNarc/CodeNarc/blob/master/CHANGELOG.txt>. Check us
out on GitHub <https://github.com/CodeNarc/CodeNarc>!

The Grails CodeNarc Plugin <http://grails.org/plugin/codenarc> has been
updated to version *0.26.0* as well.

Re: [Codenarc-user] Writing CodeNarc rules

[<AGo...@cf...>]

I am clearly going to have to get intimately familiar with AstUtil, but I 
don't think that solves my particular need.

The standard I am trying to enforce is that a Grails action should consist 
of a try/catch block that catches java.lang.Exception (debating 
java.lang.Throwable). The idea here is that the controller should at 
minimum log the exception and provide some appropriate user interaction 
when an exception occurs and not throw it back to the Grails 
infrastructure where unfriendly things happen in the UI.

Obviously most anything caught would implement Exception, but that is very 
different from Exception being caught.

Thanks!



From:   "Hamlet D'Arcy" <ham...@gm...>
To:     AGo...@cf...
Cc:     cod...@li...
Date:   09/15/2016 07:57 AM
Subject:        Re: [Codenarc-user] Writing CodeNarc rules



Sounds like you're looking for AstUtils.classNodeImplementsType  :)

    /**
     * This method tells you if a ClassNode implements or extends a 
certain class.
     * @param node
     *      the node
     * @param target
     *      the class
     * @return
     * true if the class node 'is a' target
     */







On Thu, Sep 15, 2016 at 12:14 AM, <AGo...@cf...> wrote:
Thanks to the advice here I have made some good progress. I have a rule 
that is doing pretty much what I want, but I would like to add one more 
thing that is giving me trouble.

I have the TryCatchStatement, and from there I can get the CatchStatement 
list. For each CatchStatement I can get the ClassNode for the exception 
type and from there I can check the ClassNode name to see if what is being 
caught is an Exception.

I would like to go the extra step and confirm that the CatchStatement is 
catching a java.lang.Exception and not just a Throwable someone decided to 
name Exception. Is that possible?

I could add another rule that makes sure none of the compiled code names a 
class "Exception", but it seems like I should be able to check the package 
of the class being caught. If someone writes their own java.lang.Exception 
class then I think we have gone beyond my scope, but there are definitely 
names that get reused across packages and this appears to be an important 
capability.

Thanks!

-Andrew Goodspeed



From:        Andy Goodspeed/IS/CFG
To:        cod...@li...
Date:        09/06/2016 06:32 PM
Subject:        Re: [Codenarc-user] Writing CodeNarc rules


Thanks Hamlet! That should be very helpful. Thanks also to Chris Mair who 
had some helpful suggestions.

I will hope to get a chance to try them both out; still digging out after 
a week off. Once I get back to this I will report back.

Thanks again!

-Andrew Goodspeed




From:        "Hamlet D'Arcy" <ham...@gm...>
To:        AGo...@cf...
Cc:        cod...@li...
Date:        09/01/2016 09:24 AM
Subject:        Re: [Codenarc-user] Writing CodeNarc rules



Not sure if you ever got an answer to this... 

Here is the latest Javadoc for MethodNode: 
http://docs.groovy-lang.org/latest/html/api/org/codehaus/groovy/ast/MethodNode.html


A MethodNode only ever has one Statement! so if your Method has only a 
TryCatchStatement then you know nothing follows it. 
If your method has-a BlockStatement then your method will be several 
statements long. 

The best way to explore is to write more unit tests and just look and see 
what is in the AST! 

On Thu, Aug 18, 2016 at 9:18 PM, <AGo...@cf...> wrote:
Hello all.

I am trying to write a CodeNarc rule and am struggling with just how to 
use the AST code visitor support (or anything else) to get were I want to 
go. Does anyone know of a resource that might be helpful and/or give me 
some firsthand assistance? I have looked at all of the obvious ones from 
the CodeNarc site as well as the distributed rules, google searches, etc.

I am trying to write a rule that checks to make sure the body of 
particular methods consists entirely of a try/catch block where Exception 
is caught. I have gotten as far as verifying the first statement in the 
method is a try/catch statement using an AbstractMethodVisitor but am 
struggling a bit in figuring out how to make sure there is no statement 
following it in the method.

This is where I am on my astVisitorClass.

classMyTestAstVisitor extendsAbstractMethodVisitor  {
    @Override
    voidvisitMethod(MethodNode methodNode) {
        if(Modifier.isPublic(methodNode.modifiers)) {
            if(AstUtil.isEmptyBlock(methodNode.code)) {
                addViolation(methodNode, "Action ${methodNode.name} in ${
currentClassName} is empty")
            } else{
                deftryCatchStatement = methodNode.firstStatement
                if(!(tryCatchStatement instanceofTryCatchStatement)) {
                    addViolation(methodNode, "First statement of action 
${methodNode.name} in ${currentClassName} is ${tryCatchStatement.class.
name}")
                } else{
                    // try/catch statement, but nothing more?
                }
            }
        }
    }
}

I am running with CodeNarc 0.22 and Grails 2.2.4/Groovy 2.0.8.

Thanks for any insight.

-Andrew Goodspeed
NOTICE: This message and all attachments transmitted with it may contain 
sensitive and/or confidential information intended solely for the use of 
the addressee. If the reader of this message is not the intended 
recipient, you are hereby notified that any reading, dissemination, 
distribution, copying, or other use of this message or its attachments is 
strictly prohibited. If you have received this message in error, please 
notify the sender immediately and delete this message and all copies and 
backups thereof. If you choose to communicate with us by email, you should 
be aware that the security of incoming Internet email is not secure. We 
strongly encourage you to use encrypted email when sending sensitive 
and/or confidential information. By sending sensitive or confidential 
email messages that are not encrypted, you accept the risks of such lack 
of security and possible lack of confidentiality. If you elect to 
communicate from your workplace computer, you also should be aware that 
your employer and its agents have access to email communications between 
you and us.

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

_______________________________________________
Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user




-- 
Hamlet D'Arcy 
ham...@gm...
------------------------------------------------------------------------------
_______________________________________________
Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user


NOTICE: This message and all attachments transmitted with it may contain 
sensitive and/or confidential information intended solely for the use of 
the addressee. If the reader of this message is not the intended 
recipient, you are hereby notified that any reading, dissemination, 
distribution, copying, or other use of this message or its attachments is 
strictly prohibited. If you have received this message in error, please 
notify the sender immediately and delete this message and all copies and 
backups thereof. If you choose to communicate with us by email, you should 
be aware that the security of incoming Internet email is not secure. We 
strongly encourage you to use encrypted email when sending sensitive 
and/or confidential information. By sending sensitive or confidential 
email messages that are not encrypted, you accept the risks of such lack 
of security and possible lack of confidentiality. If you elect to 
communicate from your workplace computer, you also should be aware that 
your employer and its agents have access to email communications between 
you and us.

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

_______________________________________________
Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user




-- 
Hamlet D'Arcy 
ham...@gm...
------------------------------------------------------------------------------
_______________________________________________
Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user



NOTICE: This message and all attachments transmitted with it may contain sensitive and/or confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. If you choose to communicate with us by email, you should be aware that the security of incoming Internet email is not secure. We strongly encourage you to use encrypted email when sending sensitive and/or confidential information. By sending sensitive or confidential email messages that are not encrypted, you accept the risks of such lack of security and possible lack of confidentiality. If you elect to communicate from your workplace computer, you also should be aware that your employer and its agents have access to email communications between you and us.