codenarc-user Mailing List for CodeNarc (Page 4)
Brought to you by:
chrismair
Menu
▾
▴
codenarc-user — CodeNarc Users
This list is closed, nobody may subscribe to it.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(14) |
May
(9) |
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(11) |
Nov
(29) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(27) |
Feb
(8) |
Mar
(26) |
Apr
(9) |
May
(27) |
Jun
(8) |
Jul
(24) |
Aug
(27) |
Sep
|
Oct
(4) |
Nov
(7) |
Dec
(19) |
| 2012 |
Jan
|
Feb
(7) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2013 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
|
| 2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(10) |
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(10) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: LeClaire G. <gar...@gm...> - 2012-02-17 17:14:29
|
The biggest update is that it uses the latest version of CodeNarc (0.16.1). I added the ability to control the maxheap size use by the plugin. Check the documentation over for any short comings. Give it try and send back any feedback. If it all goes well I can release it. Regards, Garvin LeClaire gar...@gm... On Feb 17, 2012, at 1:32 AM, Hamlet DArcy wrote: > What did you update? > > Is there documentation on your new features anywhere? > > -- > Hamlet > > ----- Original Message ----- >> I have updated the Maven plugin at >> http://mojo.codehaus.org/codenarc-maven-plugin/ >> Try it and give any feedback. It is still a SNAPSHOT. See >> http://mojo.codehaus.org/using-sandbox-plugins.html for information >> on using SNAPSHOT plugins. >> >> >> Regards, >> >> Garvin LeClaire >> >> Sent from my iPad >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Codenarc-user mailing list >> Cod...@li... >> https://lists.sourceforge.net/lists/listinfo/codenarc-user >> |
|
From: Hamlet D. <ham...@ca...> - 2012-02-17 06:33:09
|
What did you update? Is there documentation on your new features anywhere? -- Hamlet ----- Original Message ----- > I have updated the Maven plugin at > http://mojo.codehaus.org/codenarc-maven-plugin/ > Try it and give any feedback. It is still a SNAPSHOT. See > http://mojo.codehaus.org/using-sandbox-plugins.html for information > on using SNAPSHOT plugins. > > > Regards, > > Garvin LeClaire > > Sent from my iPad > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Codenarc-user mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codenarc-user > |
|
From: Gmail <gar...@gm...> - 2012-02-16 22:44:49
|
I have updated the Maven plugin at http://mojo.codehaus.org/codenarc-maven-plugin/ Try it and give any feedback. It is still a SNAPSHOT. See http://mojo.codehaus.org/using-sandbox-plugins.html for information on using SNAPSHOT plugins. Regards, Garvin LeClaire Sent from my iPad |
|
From: Roshan D. <ros...@gm...> - 2011-12-16 03:05:12
|
On Fri, Dec 16, 2011 at 12:23 AM, <chr...@we...> wrote: > > > I am just concerned about casting too wide a net (and missing true > violations of statelessness). So, I would be inclined to only ignore > “properties” declared with “def”.**** > > ** ** > > So, public/private/protected fields, or fields with specific types (e.g., > String, int, MyClass) would still cause violations. Is that ok? > Yes, Chris. That sounds ok. In addition, I would suggest, the rule can skip fields with specific types / visibility annotations also if those are annotated as @Inject. I have filed the bug here: https://sourceforge.net/tracker/?func=detail&aid=3460463&group_id=250145&atid=1126573 > ** ** > > >> Spring 3.x also has this annotation called @Inject.**** > > ** ** > > We could consider supporting that. We only check the name of the > annotation (“Inject”), not the type, so in that case there would be no > runtime dependency. > Great! If it can skip on the basis of @Inject without having a runtime dependency. Thanks. -- Roshan http://roshandawrani.wordpress.com/ |
|
From: <chr...@we...> - 2011-12-15 18:54:04
|
>> ignoring fields with "no initialized value" seems like a good idea to me. It should help with fields that are tied to Spring - injected or pulled in afterPropertiesSet(), etc.
I am just concerned about casting too wide a net (and missing true violations of statelessness). So, I would be inclined to only ignore "properties" declared with "def".
So, public/private/protected fields, or fields with specific types (e.g., String, int, MyClass) would still cause violations. Is that ok?
>> Spring 3.x also has this annotation called @Inject.
We could consider supporting that. We only check the name of the annotation ("Inject"), not the type, so in that case there would be no runtime dependency.
Chris
|
|
From: Roshan D. <ros...@gm...> - 2011-12-15 16:55:37
|
On Thu, Dec 15, 2011 at 10:16 PM, <chr...@we...> wrote: > >> It will be unfortunate to disable the rule because it cannot anyhow > handle bean depedencies and bean properties. **** > > ** ** > > Agreed.**** > > ** ** > > What about enhancing the rule to ignore fields that are declared as “def” > (i.e., java.lang.Object), public, and with no initialized value. Would that > be appropriate? > ignoring fields with "no initialized value" seems like a good idea to me. It should help with fields that are tied to Spring - injected or pulled in afterPropertiesSet(), etc. > Can you think of any better way to determine whether a field is injected? > Spring 3.x also has this annotation called @Inject. I won't mind flagging my dependency fields as @Inject, but I don't know how closely CodeNarc wants to be tied with a new-ish Spring version. |
|
From: Roshan D. <ros...@gm...> - 2011-12-15 16:51:47
|
On Thu, Dec 15, 2011 at 10:14 PM, Corum, Michael <mc...@rg...> wrote: > Yes, and it still calls them out. So, if the intent is to ignore final > fields, perhaps it has a bug in that area. Now that I think about it > though, we just upgraded from 0.12 to 0.16.1. Perhaps 0.12 had the bug. I > haven’t checked since our upgrade. > I am currently using 0.16.1 and it does not seem to be calling out final fields anymore. So constants may not have an issue anymore. |
|
From: <chr...@we...> - 2011-12-15 16:46:32
|
>> It will be unfortunate to disable the rule because it cannot anyhow handle bean depedencies and bean properties. Agreed. What about enhancing the rule to ignore fields that are declared as "def" (i.e., java.lang.Object), public, and with no initialized value. Would that be appropriate? Can you think of any better way to determine whether a field is injected? |
|
From: Roshan D. <ros...@gm...> - 2011-12-15 16:41:15
|
On Thu, Dec 15, 2011 at 9:22 PM, Corum, Michael <mc...@rg...> wrote: > We’ve been forced to turn off the stateless service warning because it hit > too many categories of issues for us. One is the injected services. For > instance, a service may have another service injected. > It will be unfortunate to disable the rule because it cannot anyhow handle bean depedencies and bean properties. The other option to list everything down against fields-to-ignore is also quite inconvenient, because that list may be quite large for us and it is a maintenance headache. |
|
From: Corum, M. <mc...@rg...> - 2011-12-15 16:05:32
|
We've been forced to turn off the stateless service warning because it hit too many categories of issues for us. One is the injected services. For instance, a service may have another service injected. Another is constants. While there may be a philosophical discussion there (move constants somewhere else, an interface maybe), having this gank us for a constant basically encourages programmers to move away from good refactorings and leave "magic constants" or "magic strings" all through the code, a practice I consider to be much worse than having constants as fields in a service. In essence, codenarc is encouraging duplication there so that is not acceptable if you are doing extreme programming or true test-driven development.
Mike
From: Roshan Dawrani [mailto:ros...@gm...]
Sent: Thursday, December 15, 2011 9:49 AM
To: chr...@we...
Cc: cod...@li...
Subject: Re: [Codenarc-user] GrailsStatelessService - bean properties and dependencies
There are many services for us with many dependencies (very many of them do not have a common type) and it's a pain maintaining a long list in codenarc.properties.
Can there be a better way of informing CodeNarc that "it is an injected property and do not complain about it"?
On Thu, Dec 15, 2011 at 9:13 PM, <chr...@we...<mailto:chr...@we...>> wrote:
You can set the addToIgnoreFieldNames property of the rule to add your own custom field names, either in the ruleset definition or in "codenarc.properties".
e.g.
GrailsStatelessService {
addToIgnoreFieldNames = '*Holder, fooHelper, thing1, thing2'
}
You can also ignore fields by type using the ignoreFieldTypes property. See http://codenarc.sourceforge.net/codenarc-rules-grails.html for more info on these properties.
Chris
From: Roshan Dawrani [mailto:ros...@gm...<mailto:ros...@gm...>]
Sent: Thursday, December 15, 2011 5:21 AM
To: cod...@li...<mailto:cod...@li...>
Subject: [Codenarc-user] GrailsStatelessService - bean properties and dependencies
Hi,
I am trying to use CodeNarc on a Grails app. The Grails services have other dependencies - some are injected through the app context configuration, and others that need more logic are set in afterPropertiesSet(), etc.
CodeNarc gives (GrailsStatelessService ) warnings for the fields defined to hold these dependencies.
I don't want to turn the rule off.
McAfee SiteAdvisor Warning
This e-mail message contains potentially unsafe links to these sites:
lucy.me<http://lucy.me> [data:image/gif;base64,R0lGODlhEgASAPeIAOF2iN1pfdI3VeylruzAwOaPnLUDA/C2vNdPaMEsLNVCXuSCksIvL9pbcvfk5LQCAs0jQ+mapb8mJsxRUf34+P7//8MzM8UZMM8+UtNsbP78/Pns7M1MTsU8PNVxcfjm5/nk5cIcKMMZKuSTl7sxN+apqe6wtboXF9FUWvDT0+J+jdNscv/+/uesrLgNDdhXbfbf39FBVdhWbNltc8g2OscyNsYhMsIxMcI3Od12gf/9/td3d85MVfrw8MAuMPz19t96hrYICM5bW/rt7ssgP8sgPvLS0vnp6chERMtOTsMYKf35+fPS0/fc3cI2N89QVvXd3dx3fdNfYrwdHbcKCsQ4ONh7gbYJCeF/h8InK+m0tMpMTPzv8Pbg4vPb3cUYL8IwMN50fdJbXuvExtx1e7cMDPTY2PXc3NVwcM5SU+WVmr4kJPjr68IiJunBwsUfMPPY2bYjKboVFdFaYrURE+u6uuzLyshGRuN+jr8wMLYWGNmAgNpzeLgPD8EuLv79/e2utLwMGLsYGP77+88sTO6utrQBAf///////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAIgALAAAAAASABIAAAj/ABEJHEiwoEFEDjyAoWLIUBkLO44crCNBihoTBw4AGiGGAYGCWgRFKUSyJEk+Uz4KhLKGzICGhga8bDhgRgIHAoWgiGAoDZcaDWno4GAowpMMAiUAKWBoyCEQYbAMOtTEUIEcfgQGwbPAUJYuh8KyYNLG0AIVVwQaAsDW0JwfYT/wWNtWbYC7hqxQCLthhaG7AQwJdPGigSEnh5bA8XKohw9DDWT0EcggBgJDFQ6NiUMixSE2hhBgqCIQTQgFhnC4odNQj508hhQ82CPwTwcbAmAKyN1QwJs7GgYaSSCCkPHjxpXcMFPwDJJAF4hAgFDky4MtMA4iKpFEjgEDJya0BdBO3mBAADs=] <http://www.siteadvisor.com/sites/lucy.me?pip=false&premium=true&client_uid=1010617928&client_ver=3.4.0.143&client_type=IEPlugin&suite=true&aff_id=0&locale=en_au&ui=1&os_ver=6.1.1.0>
Is there a way to tell CodeNarc that these fields do not make "state" in typical sense but actually dependencies satisfied through Spring?
--
Roshan
Lucy.me: http://www.lucy.me/roshan
Blog: http://roshandawrani.wordpress.com/
--
Roshan
Lucy.me: http://www.lucy.me/roshan
Blog: http://roshandawrani.wordpress.com/
|
|
From: Roshan D. <ros...@gm...> - 2011-12-15 15:48:42
|
There are many services for us with many dependencies (very many of them do
not have a common type) and it's a pain maintaining a long list in
codenarc.properties.
Can there be a better way of informing CodeNarc that "it is an injected
property and do not complain about it"?
On Thu, Dec 15, 2011 at 9:13 PM, <chr...@we...> wrote:
> You can set the *addToIgnoreFieldNames* property of the rule to add your
> own custom field names, either in the ruleset definition or in
> “codenarc.properties”.****
>
> e.g.****
>
> GrailsStatelessService {****
>
> addToIgnoreFieldNames = ‘*Holder, fooHelper, thing1, thing2’**
> **
>
> }****
>
> ** **
>
> You can also ignore fields by type using the *ignoreFieldTypes* property.
> See http://codenarc.sourceforge.net/codenarc-rules-grails.html for more
> info on these properties.****
>
> ** **
>
> Chris****
>
> ** **
>
> *From:* Roshan Dawrani [mailto:ros...@gm...]
> *Sent:* Thursday, December 15, 2011 5:21 AM
> *To:* cod...@li...
> *Subject:* [Codenarc-user] GrailsStatelessService - bean properties and
> dependencies****
>
> ** **
>
> Hi,****
>
> ** **
>
> I am trying to use CodeNarc on a Grails app. The Grails services have
> other dependencies - some are injected through the app context
> configuration, and others that need more logic are set in
> afterPropertiesSet(), etc.****
>
> ** **
>
> CodeNarc gives (GrailsStatelessService ) warnings for the fields defined
> to hold these dependencies.****
>
> ** **
>
> I don't want to turn the rule off. ****
>
> ** **
> McAfee SiteAdvisor Warning
> This e-mail message contains potentially unsafe links to these sites:
> lucy.me [image: more info...]<http://www.siteadvisor.com/sites/lucy.me?pip=false&premium=true&client_uid=1010617928&client_ver=3.4.0.143&client_type=IEPlugin&suite=true&aff_id=0&locale=en_au&ui=1&os_ver=6.1.1.0>
>
> Is there a way to tell CodeNarc that these fields do not make "state" in
> typical sense but actually dependencies satisfied through Spring?
> ****
>
> ** **
>
> --
> Roshan****
>
> Lucy.me: http://www.lucy.me/roshan
> Blog: http://roshandawrani.wordpress.com/****
>
> ** **
>
--
Roshan
Lucy.me: http://www.lucy.me/roshan
Blog: http://roshandawrani.wordpress.com/
|
|
From: <chr...@we...> - 2011-12-15 15:44:23
|
You can set the addToIgnoreFieldNames property of the rule to add your own custom field names, either in the ruleset definition or in "codenarc.properties".
e.g.
GrailsStatelessService {
addToIgnoreFieldNames = '*Holder, fooHelper, thing1, thing2'
}
You can also ignore fields by type using the ignoreFieldTypes property. See http://codenarc.sourceforge.net/codenarc-rules-grails.html for more info on these properties.
Chris
From: Roshan Dawrani [mailto:ros...@gm...]
Sent: Thursday, December 15, 2011 5:21 AM
To: cod...@li...
Subject: [Codenarc-user] GrailsStatelessService - bean properties and dependencies
Hi,
I am trying to use CodeNarc on a Grails app. The Grails services have other dependencies - some are injected through the app context configuration, and others that need more logic are set in afterPropertiesSet(), etc.
CodeNarc gives (GrailsStatelessService ) warnings for the fields defined to hold these dependencies.
I don't want to turn the rule off.
Is there a way to tell CodeNarc that these fields do not make "state" in typical sense but actually dependencies satisfied through Spring?
--
Roshan
Lucy.me: http://www.lucy.me/roshan
Blog: http://roshandawrani.wordpress.com/
|
|
From: Roshan D. <ros...@gm...> - 2011-12-15 12:57:59
|
On Thu, Dec 15, 2011 at 6:16 PM, Hamlet D'Arcy <ham...@gm...> wrote: > Feel free to file an issue. I will do it later if you don't have time. > Filed the issue here<https://sourceforge.net/tracker/?func=detail&aid=3459996&group_id=250145&atid=1126573>. Thanks. |
|
From: Hamlet D'A. <ham...@gm...> - 2011-12-15 12:47:07
|
Feel free to file an issue. I will do it later if you don't have time. -- Hamlet D'Arcy ham...@gm... On Dec 15, 2011 1:44 PM, "Roshan Dawrani" <ros...@gm...> wrote: > On Thu, Dec 15, 2011 at 6:07 PM, Hamlet D'Arcy <ham...@gm...>wrote: > >> Ah, I see. I had it backwards. The rule should ignore this by default. >> > Does it seem worth filing an issue then? where? > > >> In the meantime, does @SuppressWarnings solve the problem? >> > > I have worked around it in a different way for now. > >> -- >> Hamlet D'Arcy >> ham...@gm... >> >> On Dec 15, 2011 1:34 PM, "Roshan Dawrani" <ros...@gm...> >> wrote: >> >>> User @Override in class A? Does that make sense? I am not overriding a >>> superclass method in A.foo(). >>> >>> On Thu, Dec 15, 2011 at 6:02 PM, Hamlet D'Arcy <ham...@gm...>wrote: >>> >>>> Use the @Override to make it go away. In general, codenarc expects >>>> @Override to be used. There are other rules that expect it too. >>>> >>>> -- >>>> Hamlet D'Arcy >>>> ham...@gm... >>>> >>>> On Dec 15, 2011 1:03 PM, "Roshan Dawrani" <ros...@gm...> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> For the code below, CodeNarc complains that A.foo() does not use >>>>> method parameter 'x'. In the base implementation, there is no need to use >>>>> 'x', but the subclasses do. >>>>> >>>>> Is there any way I can avoid this warning for class A? >>>>> >>>>> McAfee SiteAdvisor Warning >>>>> This e-mail message contains potentially unsafe links to these sites: >>>>> lucy.me [image: more info...]<http://www.siteadvisor.com/sites/lucy.me?pip=false&premium=true&client_uid=1010617928&client_ver=3.4.0.143&client_type=IEPlugin&suite=true&aff_id=0&locale=en_au&ui=1&os_ver=6.1.1.0> >>>>> McAfee SiteAdvisor Warning >>>>> This e-mail message contains potentially unsafe links to these sites: >>>>> lucy.me [image: more info...]<http://www.siteadvisor.com/sites/lucy.me?pip=false&premium=true&client_uid=1010617928&client_ver=3.4.0.143&client_type=IEPlugin&suite=true&aff_id=0&locale=en_au&ui=1&os_ver=6.1.1.0> >>>>> class A { >>>>> protected foo(x) { >>>>> // base implementation leaves x unused >>>>> } >>>>> } >>>>> >>>>> class B extends A { >>>>> protected foo(x) { >>>>> // this overridden implementation uses x >>>>> } >>>>> } >>>>> >>>>> -- >>>>> Roshan >>>>> Lucy.me: http://www.lucy.me/roshan >>>>> Blog: http://roshandawrani.wordpress.com/ >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> 10 Tips for Better Server Consolidation >>>>> Server virtualization is being driven by many needs. >>>>> But none more important than the need to reduce IT complexity >>>>> while improving strategic productivity. Learn More! >>>>> http://www.accelacomm.com/jaw/sdnl/114/51507609/ >>>>> _______________________________________________ >>>>> Codenarc-user mailing list >>>>> Cod...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/codenarc-user >>>>> >>>>> >>> > > > -- > Roshan > Lucy.me: http://www.lucy.me/roshan > Blog: http://roshandawrani.wordpress.com/ > > |
|
From: Roshan D. <ros...@gm...> - 2011-12-15 12:45:04
|
On Thu, Dec 15, 2011 at 6:07 PM, Hamlet D'Arcy <ham...@gm...> wrote: > Ah, I see. I had it backwards. The rule should ignore this by default. > Does it seem worth filing an issue then? where? > In the meantime, does @SuppressWarnings solve the problem? > I have worked around it in a different way for now. > -- > Hamlet D'Arcy > ham...@gm... > > On Dec 15, 2011 1:34 PM, "Roshan Dawrani" <ros...@gm...> wrote: > >> User @Override in class A? Does that make sense? I am not overriding a >> superclass method in A.foo(). >> >> On Thu, Dec 15, 2011 at 6:02 PM, Hamlet D'Arcy <ham...@gm...>wrote: >> >>> Use the @Override to make it go away. In general, codenarc expects >>> @Override to be used. There are other rules that expect it too. >>> >>> -- >>> Hamlet D'Arcy >>> ham...@gm... >>> >>> On Dec 15, 2011 1:03 PM, "Roshan Dawrani" <ros...@gm...> >>> wrote: >>> >>>> Hi, >>>> >>>> For the code below, CodeNarc complains that A.foo() does not use method >>>> parameter 'x'. In the base implementation, there is no need to use 'x', but >>>> the subclasses do. >>>> >>>> Is there any way I can avoid this warning for class A? >>>> >>>> McAfee SiteAdvisor Warning >>>> This e-mail message contains potentially unsafe links to these sites: >>>> lucy.me [image: more info...]<http://www.siteadvisor.com/sites/lucy.me?pip=false&premium=true&client_uid=1010617928&client_ver=3.4.0.143&client_type=IEPlugin&suite=true&aff_id=0&locale=en_au&ui=1&os_ver=6.1.1.0> >>>> McAfee SiteAdvisor Warning >>>> This e-mail message contains potentially unsafe links to these sites: >>>> lucy.me [image: more info...]<http://www.siteadvisor.com/sites/lucy.me?pip=false&premium=true&client_uid=1010617928&client_ver=3.4.0.143&client_type=IEPlugin&suite=true&aff_id=0&locale=en_au&ui=1&os_ver=6.1.1.0> >>>> class A { >>>> protected foo(x) { >>>> // base implementation leaves x unused >>>> } >>>> } >>>> >>>> class B extends A { >>>> protected foo(x) { >>>> // this overridden implementation uses x >>>> } >>>> } >>>> >>>> -- >>>> Roshan >>>> Lucy.me: http://www.lucy.me/roshan >>>> Blog: http://roshandawrani.wordpress.com/ >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> 10 Tips for Better Server Consolidation >>>> Server virtualization is being driven by many needs. >>>> But none more important than the need to reduce IT complexity >>>> while improving strategic productivity. Learn More! >>>> http://www.accelacomm.com/jaw/sdnl/114/51507609/ >>>> _______________________________________________ >>>> Codenarc-user mailing list >>>> Cod...@li... >>>> https://lists.sourceforge.net/lists/listinfo/codenarc-user >>>> >>>> >> -- Roshan Lucy.me: http://www.lucy.me/roshan Blog: http://roshandawrani.wordpress.com/ |
|
From: Hamlet D'A. <ham...@gm...> - 2011-12-15 12:37:42
|
Ah, I see. I had it backwards. The rule should ignore this by default. In the meantime, does @SuppressWarnings solve the problem? -- Hamlet D'Arcy ham...@gm... On Dec 15, 2011 1:34 PM, "Roshan Dawrani" <ros...@gm...> wrote: > User @Override in class A? Does that make sense? I am not overriding a > superclass method in A.foo(). > > On Thu, Dec 15, 2011 at 6:02 PM, Hamlet D'Arcy <ham...@gm...>wrote: > >> Use the @Override to make it go away. In general, codenarc expects >> @Override to be used. There are other rules that expect it too. >> >> -- >> Hamlet D'Arcy >> ham...@gm... >> >> On Dec 15, 2011 1:03 PM, "Roshan Dawrani" <ros...@gm...> >> wrote: >> >>> Hi, >>> >>> For the code below, CodeNarc complains that A.foo() does not use method >>> parameter 'x'. In the base implementation, there is no need to use 'x', but >>> the subclasses do. >>> >>> Is there any way I can avoid this warning for class A? >>> >>> McAfee SiteAdvisor Warning >>> This e-mail message contains potentially unsafe links to these sites: >>> lucy.me [image: more info...]<http://www.siteadvisor.com/sites/lucy.me?pip=false&premium=true&client_uid=1010617928&client_ver=3.4.0.143&client_type=IEPlugin&suite=true&aff_id=0&locale=en_au&ui=1&os_ver=6.1.1.0> >>> class A { >>> protected foo(x) { >>> // base implementation leaves x unused >>> } >>> } >>> >>> class B extends A { >>> protected foo(x) { >>> // this overridden implementation uses x >>> } >>> } >>> >>> -- >>> Roshan >>> Lucy.me: http://www.lucy.me/roshan >>> Blog: http://roshandawrani.wordpress.com/ >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 10 Tips for Better Server Consolidation >>> Server virtualization is being driven by many needs. >>> But none more important than the need to reduce IT complexity >>> while improving strategic productivity. Learn More! >>> http://www.accelacomm.com/jaw/sdnl/114/51507609/ >>> _______________________________________________ >>> Codenarc-user mailing list >>> Cod...@li... >>> https://lists.sourceforge.net/lists/listinfo/codenarc-user >>> >>> > |
|
From: Roshan D. <ros...@gm...> - 2011-12-15 12:34:17
|
User @Override in class A? Does that make sense? I am not overriding a superclass method in A.foo(). On Thu, Dec 15, 2011 at 6:02 PM, Hamlet D'Arcy <ham...@gm...> wrote: > Use the @Override to make it go away. In general, codenarc expects > @Override to be used. There are other rules that expect it too. > > -- > Hamlet D'Arcy > ham...@gm... > > On Dec 15, 2011 1:03 PM, "Roshan Dawrani" <ros...@gm...> wrote: > >> Hi, >> >> For the code below, CodeNarc complains that A.foo() does not use method >> parameter 'x'. In the base implementation, there is no need to use 'x', but >> the subclasses do. >> >> Is there any way I can avoid this warning for class A? >> >> McAfee SiteAdvisor Warning >> This e-mail message contains potentially unsafe links to these sites: >> lucy.me [image: more info...]<http://www.siteadvisor.com/sites/lucy.me?pip=false&premium=true&client_uid=1010617928&client_ver=3.4.0.143&client_type=IEPlugin&suite=true&aff_id=0&locale=en_au&ui=1&os_ver=6.1.1.0> >> class A { >> protected foo(x) { >> // base implementation leaves x unused >> } >> } >> >> class B extends A { >> protected foo(x) { >> // this overridden implementation uses x >> } >> } >> >> -- >> Roshan >> Lucy.me: http://www.lucy.me/roshan >> Blog: http://roshandawrani.wordpress.com/ >> >> >> >> ------------------------------------------------------------------------------ >> 10 Tips for Better Server Consolidation >> Server virtualization is being driven by many needs. >> But none more important than the need to reduce IT complexity >> while improving strategic productivity. Learn More! >> http://www.accelacomm.com/jaw/sdnl/114/51507609/ >> _______________________________________________ >> Codenarc-user mailing list >> Cod...@li... >> https://lists.sourceforge.net/lists/listinfo/codenarc-user >> >> |
|
From: Hamlet D'A. <ham...@gm...> - 2011-12-15 12:32:43
|
Use the @Override to make it go away. In general, codenarc expects
@Override to be used. There are other rules that expect it too.
--
Hamlet D'Arcy
ham...@gm...
On Dec 15, 2011 1:03 PM, "Roshan Dawrani" <ros...@gm...> wrote:
> Hi,
>
> For the code below, CodeNarc complains that A.foo() does not use method
> parameter 'x'. In the base implementation, there is no need to use 'x', but
> the subclasses do.
>
> Is there any way I can avoid this warning for class A?
>
> class A {
> protected foo(x) {
> // base implementation leaves x unused
> }
> }
>
> class B extends A {
> protected foo(x) {
> // this overridden implementation uses x
> }
> }
>
> --
> Roshan
> Lucy.me: http://www.lucy.me/roshan
> Blog: http://roshandawrani.wordpress.com/
>
>
>
> ------------------------------------------------------------------------------
> 10 Tips for Better Server Consolidation
> Server virtualization is being driven by many needs.
> But none more important than the need to reduce IT complexity
> while improving strategic productivity. Learn More!
> http://www.accelacomm.com/jaw/sdnl/114/51507609/
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
>
|
|
From: Roshan D. <ros...@gm...> - 2011-12-15 12:03:43
|
Hi,
For the code below, CodeNarc complains that A.foo() does not use method
parameter 'x'. In the base implementation, there is no need to use 'x', but
the subclasses do.
Is there any way I can avoid this warning for class A?
class A {
protected foo(x) {
// base implementation leaves x unused
}
}
class B extends A {
protected foo(x) {
// this overridden implementation uses x
}
}
--
Roshan
Lucy.me: http://www.lucy.me/roshan
Blog: http://roshandawrani.wordpress.com/
|
|
From: Roshan D. <ros...@gm...> - 2011-12-15 10:21:37
|
Hi, I am trying to use CodeNarc on a Grails app. The Grails services have other dependencies - some are injected through the app context configuration, and others that need more logic are set in afterPropertiesSet(), etc. CodeNarc gives (GrailsStatelessService ) warnings for the fields defined to hold these dependencies. I don't want to turn the rule off. Is there a way to tell CodeNarc that these fields do not make "state" in typical sense but actually dependencies satisfied through Spring? -- Roshan Lucy.me: http://www.lucy.me/roshan Blog: http://roshandawrani.wordpress.com/ |
|
From: Evgeny G. <ev...@gm...> - 2011-11-21 00:29:14
|
Hello, In my case there are no import or package statements in a script but this worked just fine: FileCreateTempFile ( doNotApplyToFileNames : 'Script.groovy' ) Thanks for the tip! On Sat, Nov 19, 2011 at 20:30, Hamlet D'Arcy <ham...@gm...> wrote: > An import or package annotation is supposed to work. > > -- > Hamlet D'Arcy > ham...@gm... > > On Nov 18, 2011 9:37 PM, "Evgeny Goldin" <ev...@gm...> wrote: > >> Hi, >> >> Is it possible to somehow specify @SuppressWarnings for a regular Groovy >> script? I have my scripts scanned with CodeNarc as well, and doesn't >> want to disable the whole rule that I'd rather not fix in one of the >> scripts. >> Just stating it in the script body has no effect. If it's not possible - >> is there any workaround you can think of? >> >> >> Warm regards, >> Evgeny >> >> >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> _______________________________________________ >> Codenarc-user mailing list >> Cod...@li... >> https://lists.sourceforge.net/lists/listinfo/codenarc-user >> >> |
|
From: Hamlet D'A. <ham...@gm...> - 2011-11-19 18:30:34
|
An import or package annotation is supposed to work. -- Hamlet D'Arcy ham...@gm... On Nov 18, 2011 9:37 PM, "Evgeny Goldin" <ev...@gm...> wrote: > Hi, > > Is it possible to somehow specify @SuppressWarnings for a regular Groovy > script? I have my scripts scanned with CodeNarc as well, and doesn't want > to disable the whole rule that I'd rather not fix in one of the scripts. > Just stating it in the script body has no effect. If it's not possible - > is there any workaround you can think of? > > > Warm regards, > Evgeny > > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Codenarc-user mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codenarc-user > > |
|
From: Chris M. <chr...@ea...> - 2011-11-19 18:09:51
|
Evgeny, As a workaround, you could disable the rule(s) just for the script files, using the doNotApplyToFileNames (name with optional wildcards) or doNotApplyToFilesMatching (regular expression) properties, either within your ruleset, or within “codenarc.properties”. http://codenarc.sourceforge.net/codenarc-configuring-rules.html#Standard_Properties_for_Configuring_Rules Perhaps Hamlet has ideas about the @SuppressWarnings support within scripts. Chris From: Evgeny Goldin [mailto:ev...@gm...] Sent: Friday, November 18, 2011 3:36 PM To: cod...@li... Subject: [Codenarc-user] @SuppressWarnings for Groovy scripts? Hi, Is it possible to somehow specify @SuppressWarnings for a regular Groovy script? I have my scripts scanned with CodeNarc as well, and doesn't want to disable the whole rule that I'd rather not fix in one of the scripts. Just stating it in the script body has no effect. If it's not possible - is there any workaround you can think of? Warm regards, Evgeny |
|
From: Evgeny G. <ev...@gm...> - 2011-11-18 20:36:54
|
Hi, Is it possible to somehow specify @SuppressWarnings for a regular Groovy script? I have my scripts scanned with CodeNarc as well, and doesn't want to disable the whole rule that I'd rather not fix in one of the scripts. Just stating it in the script body has no effect. If it's not possible - is there any workaround you can think of? Warm regards, Evgeny |
|
From: Chris M. <chr...@ea...> - 2011-11-13 18:56:27
|
Version 0.16.1 contains a fix for a Groovy 1.8 compatibility issue. Bug Fix . #3393179: StackOverflowError when running CodeNarc with a Groovy 1.8 runtime. This is a workaround for a known groovy issue: http://jira.codehaus.org/browse/GROOVY-4922. Visit the CodeNarc Home Page <http://codenarc.sourceforge.net/> |
6 messages has been excluded from this view by a project administrator.
