codenarc-developer Mailing List for CodeNarc (Page 12)
Brought to you by:
chrismair
Menu
▾
▴
codenarc-developer — CodeNarc Developers
This list is closed, nobody may subscribe to it.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
(17) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(67) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(23) |
Feb
(19) |
Mar
(15) |
Apr
(7) |
May
(5) |
Jun
(43) |
Jul
(5) |
Aug
(11) |
Sep
(18) |
Oct
(9) |
Nov
(6) |
Dec
|
| 2012 |
Jan
(7) |
Feb
(2) |
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
(17) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2013 |
Jan
|
Feb
(1) |
Mar
(7) |
Apr
|
May
(6) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(6) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Hamlet D'A. <ham...@gm...> - 2010-11-12 19:39:58
|
The console has the bugs fixed. you can now save and publish scripts. Chris are you on twitter? I am HamletDRC > So, is "Hamlet D'Arcy" just a façade for a whole team of "real" developers, > authors and presenters? :-> You should see what happens when I'm between clients :) Which, by the way, if anyone out there needs a groovy consultant here i am!!! -- Hamlet D'Arcy ham...@gm... On Fri, Nov 12, 2010 at 1:34 AM, Chris Mair <chr...@ea...> wrote: > Holy crap! Very nice work. > > So, is "Hamlet D'Arcy" just a façade for a whole team of "real" developers, > authors and presenters? :-> > > -----Original Message----- > From: Hamlet D'Arcy [mailto:ham...@gm...] > Sent: Thursday, November 11, 2010 4:46 PM > To: Cod...@li... > Subject: [Codenarc-user] CodeNarc Web Console > > > You can play with the newest snapshot of CodeNarc online using: > http://meetcodenarc.appspot.com/ > > You cannot save scripts yet or view saved scripts, there is a bug I am > working on. > > But still, it is fun to play with. Code is out on github for those > interested. User name HamletDRC > > -- > Hamlet D'Arcy > ham...@gm... > > ---------------------------------------------------------------------------- > -- > Centralized Desktop Delivery: Dell and VMware Reference Architecture > Simplifying enterprise desktop deployment and management using Dell > EqualLogic storage and VMware View: A highly scalable, end-to-end client > virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev > _______________________________________________ > Codenarc-user mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codenarc-user > > |
|
From: Hamlet D. <ham...@ca...> - 2010-11-11 19:12:13
|
I converted it to something different, but in the end the Ant approach used the least code, so there is no reason to change it. -- Hamlet D'Arcy ham...@ca... Yes, feel free. That would be great if we could simplify that use case -- for us and for others Thanks. Chris Hamlet DArcy <ham...@ca...> 11/11/2010 08:56 AM To codenarc-developer <cod...@li...> cc Subject Re: [Codenarc-developer] does RunCodeNarcAgainstProjectSourceCodeTestneed to use Ant? I think you should stay on the reviews of all the new rules... this can wait. I don't want to hold up the build. I was thinking about cleaning up the test case, then people could use it to run the tests themselves with less boilerplate. I would add to this class the API of "get subversion changelist" and "get git changelist". Just a small but useful thing IMO. -- Hamlet D'Arcy ham...@ca... Hmmm. You know, it never occurred to me that would work -- I assumed that to run an Ant Task, and have it behave properly, you had to run it within the Ant "container". Interesting. When I get a chance, I'll take a look -----Original Message----- From: Hamlet DArcy [mailto:ham...@ca...] Sent: Thursday, November 11, 2010 8:31 AM To: codenarc-developer Subject: Re: [Codenarc-developer] does RunCodeNarcAgainstProjectSourceCodeTestneed to use Ant? But why go through Ant instead of just calling the task directly. Wouldn't def task = new CodeNarcTask() task.properties = ... task.execute() be simpler? -- Hamlet D'Arcy ham...@ca... Ah, I had not seen that page. Perhaps we can close the ticket I opened. Ant creates a lot of noise, but oh well. -- Hamlet D'Arcy ham...@ca... That test was my way of running CodeNarc against its own source code so that I could avoid the irony of having the project source code violate its own rules. We do not have to use Ant for that. I documented it as a mechanism for use by others on the "Run as a Test" page of the online docs. Chris -----Original Message----- From: Hamlet DArcy [mailto:ham...@ca...] Sent: Thursday, November 11, 2010 2:13 AM To: codenarc-developer Subject: [Codenarc-developer] does RunCodeNarcAgainstProjectSourceCodeTestneed to use Ant? Does the test RunCodeNarcAgainstProjectSourceCodeTest Need to be implemented using Ant? Is this testing Ant or CodeNarc? It would run faster and with less verbose output if it were not Ant. That would be good. -- Hamlet D'Arcy ham...@ca... ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev_______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ForwardSourceID:NT000CE5FA |
|
From: Hamlet D. <ham...@ca...> - 2010-11-11 19:11:41
|
i think it seems reasonable to ignore 'this' references like this.add() or just add() , which is the property I added to the rules. -- Hamlet D'Arcy ham...@ca... Hamlet, I'm wondering if changing ExplicitCallToAndMethodRule and ExplicitCallToOrMethodRule to ignore invocations where there is a single Closure parameter would address the typical Grails usage (and other DSLs as well) without hiding "bad" usages. Chris |
|
From: Chris M. <chr...@ea...> - 2010-11-11 18:54:32
|
Hamlet, I'm wondering if changing ExplicitCallToAndMethodRule and ExplicitCallToOrMethodRule to ignore invocations where there is a single Closure parameter would address the typical Grails usage (and other DSLs as well) without hiding "bad" usages. Chris |
|
From: <chr...@wa...> - 2010-11-11 14:06:55
|
Yes, feel free. That would be great if we could simplify that use case -- for us and for others Thanks. Chris Hamlet DArcy <ham...@ca...> 11/11/2010 08:56 AM To codenarc-developer <cod...@li...> cc Subject Re: [Codenarc-developer] does RunCodeNarcAgainstProjectSourceCodeTestneed to use Ant? I think you should stay on the reviews of all the new rules... this can wait. I don't want to hold up the build. I was thinking about cleaning up the test case, then people could use it to run the tests themselves with less boilerplate. I would add to this class the API of "get subversion changelist" and "get git changelist". Just a small but useful thing IMO. -- Hamlet D'Arcy ham...@ca... Hmmm. You know, it never occurred to me that would work -- I assumed that to run an Ant Task, and have it behave properly, you had to run it within the Ant "container". Interesting. When I get a chance, I'll take a look -----Original Message----- From: Hamlet DArcy [mailto:ham...@ca...] Sent: Thursday, November 11, 2010 8:31 AM To: codenarc-developer Subject: Re: [Codenarc-developer] does RunCodeNarcAgainstProjectSourceCodeTestneed to use Ant? But why go through Ant instead of just calling the task directly. Wouldn't def task = new CodeNarcTask() task.properties = ... task.execute() be simpler? -- Hamlet D'Arcy ham...@ca... Ah, I had not seen that page. Perhaps we can close the ticket I opened. Ant creates a lot of noise, but oh well. -- Hamlet D'Arcy ham...@ca... That test was my way of running CodeNarc against its own source code so that I could avoid the irony of having the project source code violate its own rules. We do not have to use Ant for that. I documented it as a mechanism for use by others on the "Run as a Test" page of the online docs. Chris -----Original Message----- From: Hamlet DArcy [mailto:ham...@ca...] Sent: Thursday, November 11, 2010 2:13 AM To: codenarc-developer Subject: [Codenarc-developer] does RunCodeNarcAgainstProjectSourceCodeTestneed to use Ant? Does the test RunCodeNarcAgainstProjectSourceCodeTest Need to be implemented using Ant? Is this testing Ant or CodeNarc? It would run faster and with less verbose output if it were not Ant. That would be good. -- Hamlet D'Arcy ham...@ca... ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ForwardSourceID:NT000CE5FA |
|
From: Hamlet D. <ham...@ca...> - 2010-11-11 13:56:42
|
I think you should stay on the reviews of all the new rules... this can wait. I don't want to hold up the build. I was thinking about cleaning up the test case, then people could use it to run the tests themselves with less boilerplate. I would add to this class the API of "get subversion changelist" and "get git changelist". Just a small but useful thing IMO. -- Hamlet D'Arcy ham...@ca... Message Hmmm. You know, it never occurred to me that would work -- I assumed that to run an Ant Task, and have it behave properly, you had to run it within the Ant "container". Interesting. When I get a chance, I'll take a look -----Original Message----- From: Hamlet DArcy [mailto:ham...@ca...] Sent: Thursday, November 11, 2010 8:31 AM To: codenarc-developer Subject: Re: [Codenarc-developer] does RunCodeNarcAgainstProjectSourceCodeTestneed to use Ant? But why go through Ant instead of just calling the task directly. Wouldn't def task = new CodeNarcTask() task.properties = ... task.execute() be simpler? -- Hamlet D'Arcy ham...@ca... Ah, I had not seen that page. Perhaps we can close the ticket I opened. Ant creates a lot of noise, but oh well. -- Hamlet D'Arcy ham...@ca... That test was my way of running CodeNarc against its own source code so that I could avoid the irony of having the project source code violate its own rules. We do not have to use Ant for that. I documented it as a mechanism for use by others on the "Run as a Test" page of the online docs. Chris -----Original Message----- From: Hamlet DArcy [mailto:ham...@ca...] Sent: Thursday, November 11, 2010 2:13 AM To: codenarc-developer Subject: [Codenarc-developer] does RunCodeNarcAgainstProjectSourceCodeTestneed to use Ant? Does the test RunCodeNarcAgainstProjectSourceCodeTest Need to be implemented using Ant? Is this testing Ant or CodeNarc? It would run faster and with less verbose output if it were not Ant. That would be good. -- Hamlet D'Arcy ham...@ca... |
|
From: Hamlet D. <ham...@ca...> - 2010-11-11 13:31:09
|
But why go through Ant instead of just calling the task directly. Wouldn't def task = new CodeNarcTask() task.properties = ... task.execute() be simpler? -- Hamlet D'Arcy ham...@ca... Ah, I had not seen that page. Perhaps we can close the ticket I opened. Ant creates a lot of noise, but oh well. -- Hamlet D'Arcy ham...@ca... Message That test was my way of running CodeNarc against its own source code so that I could avoid the irony of having the project source code violate its own rules. We do not have to use Ant for that. I documented it as a mechanism for use by others on the "Run as a Test" page of the online docs. Chris -----Original Message----- From: Hamlet DArcy [mailto:ham...@ca...] Sent: Thursday, November 11, 2010 2:13 AM To: codenarc-developer Subject: [Codenarc-developer] does RunCodeNarcAgainstProjectSourceCodeTestneed to use Ant? Does the test RunCodeNarcAgainstProjectSourceCodeTest Need to be implemented using Ant? Is this testing Ant or CodeNarc? It would run faster and with less verbose output if it were not Ant. That would be good. -- Hamlet D'Arcy ham...@ca... |
|
From: Hamlet D. <ham...@ca...> - 2010-11-11 07:12:55
|
Does the test RunCodeNarcAgainstProjectSourceCodeTest Need to be implemented using Ant? Is this testing Ant or CodeNarc? It would run faster and with less verbose output if it were not Ant. That would be good. -- Hamlet D'Arcy ham...@ca... |
|
From: <chr...@wa...> - 2010-11-10 14:37:24
|
Absolutely. Hamlet DArcy <ham...@ca...> 11/10/2010 09:23 AM To chris mair <chr...@wa...> cc Cod...@li... Subject Re: [Codenarc-developer] 0.11 release planning thread Would you mind keeping track of your renames/moves and just sending me a heads up on them? Thanks, -- Hamlet D'Arcy ham...@ca... LOL. Good, I'm glad you prefer the lightweight release. I've still got some reorg to do (moving/renaming), so let's stick with a full release for Sun/Mon. Thanks for doing the first pass at the change log. That new rules list is pretty damn impressive! We also need to call out the need for Groovy 1.7. I can't check in stuff from work, so go ahead and check it in yourself. I'll have some edits later. Chris Hamlet DArcy <ham...@ca...> 11/10/2010 09:02 AM To chris mair <chr...@wa...> cc Cod...@li... Subject Re: [Codenarc-developer] 0.11 release planning thread Let's stick to lightweight releases. I hate branching too. I have the change log and a blog post all ready to go. Changelog is attached. I'll check it in tonight from home or you can make edits now and check it in yourself, whatever. I'd like to release the blog post /before/ the announcement to the mailing lists so have have some extra documentation to reference. I can get my javadoc and documentation reviewed tonight. It's your call. I'd love to release a BETA/RC tonight and full release Sunday/Monday. Or can wait for full release. Either way we get a full release soon and that's always resulted in a happy ending for me. And yes, that's a full release joke in that last sentence. -- Hamlet D'Arcy ham...@ca... Ok. In general, I have been preferring "lightweight" releases -- no branching; just roll changes/fixes into next release; and do next release sooner if necessary. But we can consider this a special case, since it is time-constrained. I'll plan on doing a 0.11-RC1 release, and we can create a branch. Is the weekend ok for that? When do you need it? Chris Hamlet DArcy <ham...@ca...> 11/10/2010 01:25 AM To Chris Mair <chr...@ea...> cc Cod...@li... Subject Re: [Codenarc-developer] 0.11 release planning thread Hmmm, I'll work on the CHANGELOG.txt file and javadoc in AstUtil. That way no new rules get checked in today. Perhaps it is best to build and upload 0.11 RC1 or Beta1 and branch the codebase. Then we have time to clean up false positives and issues while still allowing early adopters to check out the new work (and help with the bug reports!) -- Hamlet D'Arcy ham...@ca... Hamlet, In addition to the items in your list, I typically: A) Create a snapshot release and run that against several large Groovy projects at work, and examine the violations. In almost every release that has ended up revealing an issue or two -- often a false negative or false positive in a new rule. B) Run the new code version against the open source projects (Grails, Griffon, Gradle) and pull in the resulting reports. C) Deploy to the Maven Central Repo after the release D) Tag the project version in SVN I will plan to do all of the above. I will also do #3 (Grails plugin) from your list - usually a a few days after the release. You are more than welcome to do #2, #4 (I do not have Gradle commit rights) and #5. For #6 (email announcements), I was intending on collaborating with you. For #0 (Change log), if you want to do a draft version in the "CHANGELOG.txt" version that would be great, but not required. I will have a few additions of my own. To be honest, I am struggling to keep up with all of the recent additions/changes (though I am absolutely NOT complaining!!!). I don't have a lot of time to work on this each day. It will take me at least a few days to catch up and get my own changes done before the release. Are you pretty much done with your changes? Thanks a lot. Chris -----Original Message----- From: Hamlet D'Arcy [mailto:ham...@gm...] Sent: Tuesday, November 09, 2010 2:57 PM To: Cod...@li... Subject: [Codenarc-developer] 0.11 release planning thread Chris, You're the owner, so it is of course up to you to run the 0.11 release the way you want. As a list of todos, we need to: 0. Create the Changelog 1. Build and upload new version 2. Update Griffon plugin (i have commit rights and can do this) 3. UPdate Grails plugin (do you have commit rights?) 4. Update Gradle plugin (do you have commit rights?) 5. Publish a blogpost/page with more info about all the new rules (i can do this) 6. Send email announcements to groovy, griffon, grails, & hackergarten lists Which do you need the most help with? What is missing? -- Hamlet D'Arcy ham...@gm... ---------------------------------------------------------------------------- -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev_______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ForwardSourceID:NT000CE31E ForwardSourceID:NT000CE392 ForwardSourceID:NT000CE39E |
|
From: Hamlet D. <ham...@ca...> - 2010-11-10 14:23:34
|
Would you mind keeping track of your renames/moves and just sending me a heads up on them? Thanks, -- Hamlet D'Arcy ham...@ca... LOL. Good, I'm glad you prefer the lightweight release. I've still got some reorg to do (moving/renaming), so let's stick with a full release for Sun/Mon. Thanks for doing the first pass at the change log. That new rules list is pretty damn impressive! We also need to call out the need for Groovy 1.7. I can't check in stuff from work, so go ahead and check it in yourself. I'll have some edits later. Chris Hamlet DArcy <ham...@ca...> 11/10/2010 09:02 AM To chris mair <chr...@wa...> cc Cod...@li... Subject Re: [Codenarc-developer] 0.11 release planning thread Let's stick to lightweight releases. I hate branching too. I have the change log and a blog post all ready to go. Changelog is attached. I'll check it in tonight from home or you can make edits now and check it in yourself, whatever. I'd like to release the blog post /before/ the announcement to the mailing lists so have have some extra documentation to reference. I can get my javadoc and documentation reviewed tonight. It's your call. I'd love to release a BETA/RC tonight and full release Sunday/Monday. Or can wait for full release. Either way we get a full release soon and that's always resulted in a happy ending for me. And yes, that's a full release joke in that last sentence. -- Hamlet D'Arcy ham...@ca... Ok. In general, I have been preferring "lightweight" releases -- no branching; just roll changes/fixes into next release; and do next release sooner if necessary. But we can consider this a special case, since it is time-constrained. I'll plan on doing a 0.11-RC1 release, and we can create a branch. Is the weekend ok for that? When do you need it? Chris Hamlet DArcy <ham...@ca...> 11/10/2010 01:25 AM To Chris Mair <chr...@ea...> cc Cod...@li... Subject Re: [Codenarc-developer] 0.11 release planning thread Hmmm, I'll work on the CHANGELOG.txt file and javadoc in AstUtil. That way no new rules get checked in today. Perhaps it is best to build and upload 0.11 RC1 or Beta1 and branch the codebase. Then we have time to clean up false positives and issues while still allowing early adopters to check out the new work (and help with the bug reports!) -- Hamlet D'Arcy ham...@ca... Hamlet, In addition to the items in your list, I typically: A) Create a snapshot release and run that against several large Groovy projects at work, and examine the violations. In almost every release that has ended up revealing an issue or two -- often a false negative or false positive in a new rule. B) Run the new code version against the open source projects (Grails, Griffon, Gradle) and pull in the resulting reports. C) Deploy to the Maven Central Repo after the release D) Tag the project version in SVN I will plan to do all of the above. I will also do #3 (Grails plugin) from your list - usually a a few days after the release. You are more than welcome to do #2, #4 (I do not have Gradle commit rights) and #5. For #6 (email announcements), I was intending on collaborating with you. For #0 (Change log), if you want to do a draft version in the "CHANGELOG.txt" version that would be great, but not required. I will have a few additions of my own. To be honest, I am struggling to keep up with all of the recent additions/changes (though I am absolutely NOT complaining!!!). I don't have a lot of time to work on this each day. It will take me at least a few days to catch up and get my own changes done before the release. Are you pretty much done with your changes? Thanks a lot. Chris -----Original Message----- From: Hamlet D'Arcy [mailto:ham...@gm...] Sent: Tuesday, November 09, 2010 2:57 PM To: Cod...@li... Subject: [Codenarc-developer] 0.11 release planning thread Chris, You're the owner, so it is of course up to you to run the 0.11 release the way you want. As a list of todos, we need to: 0. Create the Changelog 1. Build and upload new version 2. Update Griffon plugin (i have commit rights and can do this) 3. UPdate Grails plugin (do you have commit rights?) 4. Update Gradle plugin (do you have commit rights?) 5. Publish a blogpost/page with more info about all the new rules (i can do this) 6. Send email announcements to groovy, griffon, grails, & hackergarten lists Which do you need the most help with? What is missing? -- Hamlet D'Arcy ham...@gm... ---------------------------------------------------------------------------- -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev_______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ForwardSourceID:NT000CE31E ForwardSourceID:NT000CE392 |
|
From: <chr...@wa...> - 2010-11-10 14:12:20
|
CodeNarc Change Log ------------------------------------------------------------------------------- http://www.codenarc.org Changes in version 0.11 (November 2010) ------------------------------------------- NEW FEATURES - @SuppressWarnings support. All rules now recognize the java.lang.SuppressWarnings annotation on fields, methods, and classes. If this annotation is added then there will be no violations produced. Just as in Java, the annotation requires a String or List<String> parameter. For example, annotating a class with @SuppressWarnings('UnusedPrivateField') will ignore the rule for that class. Annotating a method with @SuppressWarnings(['UnusedPrivateField', 'UnnecessaryIfStatementRule']) will ignore both rules for the annotated method. - Better "codenarc create-rule" support. You can create a new rule by running "codenarc create-rule" from the root of the CodeNarc codebase. This script has been updated to properly format Javadoc, prompt for the author name, and update the Maven Site .apt documentation. NEW RULES BooleanMethodReturnsNull Rule (basic) : Checks for a method with Boolean return type that returns an explicit null. DeadCode Rule (basic) : Checks for dead code that appears after a return statement or after an exception is thrown. DoubleNegative Rule (basic) : Checks for using a double negative, which is always positive. DuplicateCaseStatement Rule (basic) : Check for duplicate case statements in a switch block, such as two equal integers or strings. ExplicitCallToAndMethod Rule (basic) : This rule detects when the and(Object) method is called directly in code instead of using the & operator. ExplicitCallToCompareToMethod Rule (basic) : This rule detects when the compareTo(Object) method is called directly in code instead of using the <=>, >, >=, <, and <= operators. ExplicitCallToDivMethod Rule (basic) : This rule detects when the div(Object) method is called directly in code instead of using the / operator. ExplicitCallToEqualsMethod Rule (basic) : This rule detects when the equals(Object) method is called directly in code instead of using the == or != operator. ExplicitCallToGetAtMethod Rule (basic) : This rule detects when the getAt(Object) method is called directly in code instead of using the [] index operator. ExplicitCallToLeftShiftMethod Rule (basic) : This rule detects when the leftShift(Object) method is called directly in code instead of using the \<\< operator. ExplicitCallToMinusMethod Rule (basic) : This rule detects when the minus(Object) method is called directly in code instead of using the - operator. ExplicitCallToMultiplyMethod Rule (basic) : This rule detects when the multiply(Object) method is called directly in code instead of using the * operator. ExplicitCallToModMethod Rule (basic) : This rule detects when the mod(Object) method is called directly in code instead of using the % operator. ExplicitCallToOrMethod Rule (basic) : This rule detects when the or(Object) method is called directly in code instead of using the | operator. ExplicitCallToPlusMethod Rule (basic) : This rule detects when the plus(Object) method is called directly in code instead of using the + operator. ExplicitCallToPowerMethod Rule (basic) : This rule detects when the power(Object) method is called directly in code instead of using the ** operator. ExplicitCallToRightShiftMethod Rule (basic) : This rule detects when the rightShift(Object) method is called directly in code instead of using the \>\> operator. ExplicitCallToXorMethod Rule (basic) : This rule detects when the xor(Object) method is called directly in code instead of using the ^ operator. ExplicitCreationOfArrayList Rule (basic) : This rule checks for the explicit instantiation of an ArrayList. In Groovy, it is best to write new ArrayList() as [], which creates the same object. ExplicitCreationOfHashMap Rule (basic) : This rule checks for the explicit instantiation of a HashMap. In Groovy, it is best to write new HashMap() as [:], which creates the same object. ExplicitCreationOfHashSet Rule (basic) : This rule checks for the explicit instantiation of a HashSet. In Groovy, it is best to write new HashSet() as [] as Set, which creates the same object. ExplicitCreationOfLinkedList Rule (basic) : This rule checks for the explicit instantiation of a LinkedList. In Groovy, it is best to write new LinkedList() as [] as Queue, which creates the same object. ExplicitCreationOfStack Rule (basic) : This rule checks for the explicit instantiation of a Stack. In Groovy, it is best to write new Stack() as [] as Stack, which creates the same object. ExplicitCreationOfTreeSet Rule (basic) : This rule checks for the explicit instantiation of a TreeSet. In Groovy, it is best to write new TreeSet()>> as [] as SortedSet, which creates the same object. GStringAsMapKey Rule A GString should not be used as a map key since its hashcode is not guaranteed to be stable. InvertedIfElse Rule (basic) : An inverted if-else statement is one in which there is a single if statement with a single else branch and the boolean test of the if is negated. RemoveAllOnSelf Rule (basic) : Don't use removeAll to clear a collection. ReturnsNullInsteadOfEmptyArray Rule (basic) : If you have a method or closure that returns an array, then when there are no results return a zero-length (empty) array rather than null. ReturnsNullInsteadOfEmptyCollection Rule (basic) : If you have a method or closure that returns a collection, then when there are no results return a zero-length (empty) collection rather than null. SerialVersionUID Rule (basic) : A serialVersionUID is normally intended to be used with Serialization. It needs to be of type long, static, and final. UnnecessaryConstructor Rule (basic) : This rule detects when a constructor is not necessary; i.e., when there's only one constructor, it's public, has an empty body, and takes no arguments. UselessCollectionCall Rule (basic) : Checks for useless calls to collections. UselessOverridingMethod Rule (basic) : Checks for an overriding method that merely calls the same method defined in a superclass. UnnecessaryReturnKeyword Rule (basic) : In Groovy, the return keyword is often optional. SynchronizedOnGetClass Rule (concurrency) : Checks for synchronization on getClass() rather than class literal. UseOfNotifyMethod Rule (concurrency) : Checks for code that calls notify() rather than notifyAll(). DuplicateNumberLiteral Rule (dry) : This rule checks for duplicate number literals within the current class. DuplicateStringLiteral Rule (dry) : This rule checks for duplicate String literals within the current class. CatchIllegalMonitorStateException Rule (exceptions) : Dubious catching of IllegalMonitorStateException. ConfusingClassNamedException Rule (exceptions) : This class is not derived from another exception, but ends with 'Exception'. ReturnNullFromCatchBlock Rule (exceptions) : Returning null from a catch block often masks errors and requires the client to handle error codes. UseAssertEqualsInsteadOfAssertTrue Rule (junit) : This rule detects JUnit assertions in object equality. UseAssertTrueInsteadOfAssertEqualsRule Rule (junit) : This rule detects JUnit calling assertEquals where the first parameter is a boolean. UseAssertNullInsteadOfAssertEquals Rule (junit) : This rule detects JUnit calling assertEquals where the first or second parameter is null. UseAssertSameInsteadOfAssertTrue Rule (junit) : This rule detects JUnit calling assertTrue or assertFalse where the first or second parameter is an Object#is() call testing for reference equality. UseFailWithMessageInsteadOfWithout Rule (junit) : This rule detects JUnit calling the fail() method without an argument. UsingJUnitStyleAssertions Rule (junit) : This rule detects calling JUnit style assertions like assertEquals, assertTrue, assertFalse, assertNull, assertNotNull. ConfusingMethodName Rule (naming) : Checks for very confusing method names. The referenced methods have names that differ only by capitalization. ObjectOverrideMisspelledMethodName Rule (naming) : Verifies that the names of the most commonly overridden methods of Object: equals, hashCode and toString, are correct. MethodCount Rule (size) : Checks if the number of methods within a class exceeds the number of lines specified by the maxMethod property. BUG FIXES - None reported, none fixed! OTHER CHANGES - CodeNarc now requires Groovy 1.7 to run. Keep in mind that it can still run against (analyze) older Groovy code. - There is a new rule category called "dry", meaning "do not repeat yourself". - AstUtil enhancements - For writers of rules: there are new utility methods in the AstUtil class. See the javadoc for more details. - AbstractAstVisitor Breaking Changes - If you implemented your own rule by subclassing AbstractAstVisitor then your code might break. It is a compile error and the breakage will be clear and obvious. In order to support @SuppressWarnings, we needed to change AbstractAstVisitor. The method visitMethodNode became visitMethodNodeEx, visitClass became visitClassEx, visitConstructorOrMethod became visitConstructorOrMethodEx, visitField became visitFieldEx, visitProperty became visitPropertyEx, and visitConstructor became visitConstructorEx. From within these new methods there is no need to call super.visitX. In the rare case that the simple renaming does not fix your problem then please contact the mailing list. Changes in version 0.10 (26 September 2010) ------------------------------------------- BUG FIXES - Fix Bug #3071531: "Unused rules don't recognized method closures". https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=3071531&group_id=250145. e.g. private def bar() { } .. return this.&bar; - Fix: UnusedPrivateField: Dont produce violation if field is a Closure field and is executed. - Fix: ImportFromSamePackage: Fix for (ignore) alias imports within same package. package org.xyz; import org.xyz.MyBigClass as MBC. NEW RULES - New UnnecessaryIfStatementRule (basic): Checks for if statements where the if and else blocks are only returning true and false constants. if(x) { return true } else { return false }. - New UnnecessaryBooleanExpressionRule (basic): Check for unnecessary boolean expressions, including ANDing (&&) or ORing (||) with true, false, null, or Map/List/String/Number literal. Also checks for negation of true, false, null, or Map/List/String/Number literal. - New BigDecimalInstantiationRule (basic): Avoid creating BigDecimal with a decimal (float/double) literal. Use a String literal. From PMD. See http://pmd.sourceforge.net/rules/basic.html#AvoidDecimalLiteralsInBigDecimalConstructor. Note that println new BigDecimal(0.1) prints out 0.1000000000000000055511151231257827021181583404541015625. - UnusedObjectRule (unused): Checks for object allocations that are not assigned or used, unless it is the last statement within a block (because it may be the intentional return value). - New UnusedArrayRule (unused): This inspection reports any instances of Groovy array allocation where the array allocated is ignored. Such allocation expressions are legal Groovy, but are usually either inadvertent, or evidence of a very odd object initialization strategy. (IntelliJ). When an ExpressionStatement has as its expression an ArrayExpression. - Implement ImplementationAsTypeRule (design): Checks that particular classes are never used as types in variable declarations, return values or parameters. GregorianCalendar, HashMap, HashSet, Hashtable, LinkedList, LinkedHashMap, LinkedHashSet, TreeSet, TreeMap, Vector, ArrayList, CopyOnWriteArrayList, CopyOnWriteArraySet, ConcurrentHashMap, ArrayBlockingQueue, ConcurrentLinkedQueue, DelayQueue, LinkedBlockingQueue, PriorityBlockingQueue, PriorityQueue, SynchronousQueue (see Checkstyle). (design) - New JUnitUnnecessaryTearDownRule (junit). Checks for tearDown() methods that only call super.tearDown(). - New JUnitUnnecessarySetUpRule (junit). Checks for setUp() methods that only call super.setUp(). NEW REPORT WRITER - New InlineXmlReportWriter (from Robin Bramley) for improved integration with the Hudson Violations plugin. See http://wiki.hudson-ci.org/display/HUDSON/Violations. OTHER CHANGES - CodeNarc now requires Groovy 1.6 to run. Keep in mind that it can still run against (analyze) older Groovy code. - Upgrade to GMetrics 0.3 for AbcComplexityRule and CyclomaticComplexityRule. Violations now include line number and source line. - All JUnit rules (JUnit*Rule): Also apply to classes with names ending in *TestCase. - Add codenarc create-rule script to create a new rule and associated classes/tests. https://sourceforge.net/tracker/?func=detail&aid=3005873&group_id=250145&atid=1126575. (Hamlet D'Arcy) - ConstantTernaryExpressionRule: Also flag constant Map and List expressions. - ConstantIfExpressionRule: Also flag constant Map and List expressions. - GrailsPublicControllerMethod: add ignoreMethodNames property. - Add reference to Sonar plugin. http://docs.codehaus.org/display/SONAR/Groovy+Plugin to web site. - Add reference to Hudson Violations Plugin. http://wiki.hudson-ci.org/display/HUDSON/Violations to web site. Changes in version 0.9 (10 May 2010) ------------------------------------ BUG FIXES - Fix bug #2985592: "MissingPropertyException: No such property: W3C_XML_SCHEMA_NS_URI". - XML RuleSet: Allow wildcards (*) in <include> and <exclude>. - WildcardPattern: Escape plus sign ('+'). - NestedBlockDepthRule: Ignore first level of closure for Closure Fields (since they are really equivalent to methods). NEW SIZE/COMPLEXITY RULES - AbcComplexityRule - Check ABC size/complexity score against threshold for method and class average (size) - CyclomaticComplexityRule - Check Cyclomatic Complexity against threshold for method and class average (size) NEW CONCURRENCY RULES - NestedSynchronizationRule (concurrency - Hamlet DArcy) - RunFinalizersOnExitRule (concurrency - Hamlet DArcy) - SynchronizedMethodRule (concurrency - Hamlet DArcy) - SynchronizedOnThisRule (concurrency - Hamlet DArcy) - ThreadLocalNotStaticFinalRule (concurrency - Hamlet DArcy) - ThreadYieldRule: (concurrency - Hamlet DArcy) - VolatileLongOrDoubleFieldRule: (concurrency - Hamlet DArcy) NEW BASIC RULES - CloneableWithoutCloneRule (basic - Hamlet D'Arcy & René Gröschke) - ConstantIfExpressionRule: if(true) or if(false). Or literal constant. (basic) - ConstantTernaryExpressionRule: true ? x : y or false, null or literal.(basic) - UnnecessaryTernaryExpressionRule: x ? true : false. Or Boolean.TRUE. Or where both expressions are the same. (basic) OTHER CHANGES - Deprecate GrailsSessionReferenceRule. Default enabled to false. Note in online docs. - StatelessClassRule: Add setAddToIgnoreFieldNames() method (adds to ignoreFieldNames). - Add new <rule>.description.html property for each rule. Change the HtmlReportWriter to look for *.description.html first; if not defined, use *.description. Continue to use *.description in XML report. Potential BREAKAGE: If you have overridden the "<rule>.description" message for a predefined rule in a "codenarc-messages.properties" file, you will have to change those message keys to "<rule>.description.html". - Do not include disabled rules in list of rules at bottom of HTML/XML report. - HtmlReportWriter: Dont log warning if "codenarc-messages.properties" contains *.description but not *.description.html. - UnusedVariableRule: Fix limitation: Does not recognize variable references on the same line as the variable declaration. - GroovyDslRuleSet: Throw MissingPropertyException if a non-existent property is set within a Groovy RuleSet DSL. - CodeNarcRunner: Add System.out println of summary counts. - MethodSizeRule: Apply to constructors as well. - WildcardPattern: Trim pattern values. This includes property values such as common rule properties applyToFileNames/doNotApplyToFileNames, applyToClassNames/doNotApplyToClassNames. Or many rule-specific properties such as ignoreMethodNames for the MethodSizeRule. - PropertiesFileRuleSetConfigurer: Log warning if rule name not found. - TESTS: AbstractRuleTestCase: Add assertViolations(String source, Map[] violationMaps) helper method. - TESTS: Fix tests broken on Linux. Changes in version 0.8.1 (2 Feb 2010) ------------------------------------ BUG FIXES - Fix Bug #2943025: "NestedBlockDepthRule: Produces erroneous results on Groovy 1.6.x." https://sourceforge.net/tracker/?func=detail&aid=2943025&group_id=250145&atid=1126573 - Fix Bug #2943028: "PackageNameRule may show incorrect violations for classes within the default package when running in Groovy 1.6.x." https://sourceforge.net/tracker/?func=detail&aid=2943028&group_id=250145&atid=1126573 - Fix Bug #2935587 "Building CodeNarc 0.8 fails." - Problem from Joern Huxhorn (Jan 18, 2010) Unable to build from the downloaded CodeNarc-0.8-bin.tar.gz. http://sourceforge.net/tracker/?func=detail&aid=2935587&group_id=250145&atid=1126573. See CodeNarc - Unable to Build From TarGZip.doc. Remove platform/locale dependencies: AbstractReportWriterTest, UrlResourceTest, GrailsSessionReferenceRuleTest, GrailsPublicControllerMethodRuleTest, GrailsServletContextReferenceRuleTest, GrailsStatelessServiceRuleTest. [Jan 24] - Fix StackOverflow in Groovy 1.7.0 for some rules: All rules that implement the visitVariableExpression(VariableExpression expression) visitor method: UnusedVariableRule, UnusedPrivateFieldRule, GrailsSessionReferenceRule, GrailsServletContextReferenceRule Removed call to super.visitVariableExpression(expression) since that seems to cause problems (StackOverflow) in Groovy 1.7.0. - Fix tests broken when running in Groovy 1.6 or Groovy 1.7. - DuplicateImportRule: Document that this rule does not work when running under Groovy 1.7 (i.e., will not produce any violations), and does not distinguish between multiple duplicate imports for the same class. Changes in version 0.8 (17 Jan 2010) ------------------------------------ BUG FIXES - Fix Bug #2930886: "Cannot load rules when groovy is in different classloader". XmlReaderRuleSet, ReportWriterFactory: Replace calls to Class.forName() with getClass().classLoader.loadClass(). https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=2930886&group_id=250145. - Fix Bug #2847520: "UnusedVariableRule: Closure variable must be invoked". UnusedVariableRule: Referencing an (explicit) Closure variable without invoking it is not recognized as a valid reference. e.g., final CLOSURE = { .. }; return CLOSURE. https://sourceforge.net/tracker/?func=detail&aid=2847520&group_id=250145&atid=1126573 - Fix false positive: Local closures: If a closure is assigned to a local variable, then used later in the method, CodeNarc report the variable unused. [I think this has already been resolved, perhaps as part of Bug #2847520]. (reported by Donal Murtagh) - Fix false positive: Default arguments: If a constant is only used as the value of a default argument, CodeNarc reports this constant unused. (reported by Donal Murtagh) REPORTS - Create XmlReportWriter for wrting out an XML report ("xml"). (beta) - Create TextReportWriter. Writes out text report with violations by file and priority and summary counts. - Enable configuring all provided ReportWriters (HtmlReportWriter, XmlReportWriter, TextReportWriter) to write to the stdout (console). - Enable specifying the full class name of a custom ReportWriter class. - CodeNarcTask: Add support for <option> nested elements under the <report> element. - HtmlReportWriter: Externalize strings to resource bundle. - Remove setTitle() and setOutputFile() from ReportWriter interface. - ReportWriter: Rename writeOutReport() method to writeReport(). - Create AbstractReportWriter. RULES - Create new NestedBlockDepthRule. Checks for nesting of all types of block statements (and closures), including for, if, while, try and switch statements. (design) - MethodSizeRule: Add support for "ignoreMethodNames" property to enable filtering. - AbstractRule: Enhance applyToFileNames to handle optional path (e.g. "abc/def/MyClass.groovy"). - AbstractRule: The (previously deprecated) applyToFilenames and doNotApplyToFilenames properties now throw an UnsupportedOperationException. - AbstractRule: Add optional description property; Use it in report if specified. OTHER CHANGES - Allow spaces within comma-separated list of ruleset files. Applies when specifying ruleset files for the CodeNarc Ant Task or the CodeNarc script. - CodeNarcRunner: Dont require that reportWriters is non-empty. - AntFileSetSourceAnalyzer: Specify sourceDirectories relative to project base directory. - Reorganize web site. Add Reports section. Add pages for HTML, XML and and text reports. - Add support and documentation for running CodeNarc as part of an automated test suite (e.g. JUnit). - Add List getSourceDirectories() to SourceAnalyzer interface and implementation classes. - Change "codenarc-version.txt" to contain only the version number. - Rename AbstractTest to AbstractTestCase. Changes in version 0.7 (25 Aug 2009) ------------------------------------ BUG FIXES - Fix Bug #2825698: "UnusedVariableRule: stops after 1st unused variable per name". https://sourceforge.net/tracker/?func=detail&aid=2825698&group_id=250145&atid=1126573. - Fix Bug #2828696: "UnusedImport rule with fully qualified class reference" https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=2828696&group_id=250145. - UnusedImportRule: Add support for static imports. Document known limitation: will not work on imports with wildcards. - UnnecessaryGroovyImportRule: Add java.net as another automatically included package. NEW FEATURES AND INFRASTRUCTURE - Groovy DSL for defining RuleSets. (GroovyDslRuleSet and RuleSetBuilder). - Enable optional prefix of "file:", "http:" or any other standard URL prefix for resource files, including ruleset files, "codenarc.properties" and rule scripts. * Addresses Tracker Issue #2828616: "Allow ruleset file to be specified as a file or url" https://sourceforge.net/tracker/?func=detail&atid=1126575&aid=2828616&group_id=250145. - CodeNarcTask and AntFileSetSourceAnalyzer: Allow more than one FileSet to be added. * Addresses Tracker Issue #2831255: "Ant task should accept any ResourceCollection for source" https://sourceforge.net/tracker/?func=detail&aid=2831255&group_id=250145&atid=1126575. - HtmlReportWriter: Show rule name in color according to priority. - CompositeRuleSet: Rename add(RuleSet) to addRuleSet(RuleSet). Add addRule(Rule). RULES - Create new PropertyNameRule. (naming) - FieldNameRule: Do not apply to property fields. Changes in version 0.6 (17 Jul 2009) ------------------------------------ BUG FIXES - Fix BUG #2798845 : "StringIndexOutOfBoundsException" https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=2798845&group_id=250145 - Fix BUG #2799752: GrailsPublicControllerMethodRule - should only apply itself to methods within classes that have suffix "Controller". (see email from Jason Anderson, May 26, 2009) https://sourceforge.net/tracker/?func=detail&aid=2799752&group_id=250145&atid=1126573 - Fix BUG #2796953: StatelessClassRule requires applyToFileNames or applyToFilesMatching. https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=2796953&group_id=250145 - Fix BUG #2811213: "FieldNameRule: Names for final fields - not be all caps". FieldNameRule: Field names for final instance fields should not default to be all caps like static final fields. For instance: final List sentEmails = []. Rather, "If a property is declared final the private field is created final and no setter is generated." (http://groovy.codehaus.org/Groovy+Beans). So, they should be named with "normal" naming conventions. Re-purpose the finalRegex property to just apply to final instance fields and default to null so that final field names use same convention as non-final. https://sourceforge.net/tracker/?func=detail&aid=2811213&group_id=250145&atid=1126573. - Fix: GrailsStatelessServiceRule: Should only apply to *Service classes. RULES - Implement UnusedVariableRule. (unused) - Implement UnusedPrivateMethodRule. (unused) - Implement UnusedPrivateFieldRule. (unused). - MethodNameRule: Add support for ignoreMethodNames. - ParameterNameRule: Add support for ignoreParameterNames. - VariableNameRule: Add support for ignoreVariableNames. - FieldNameRule: Add support for ignoreFieldNames. - IllegalRegexRule: Include line numbers in rule violations. INFRASTRUCTURE - Allow setting custom name and path for "codenarc.properties" file using "codenarc.properties.file" system property. - WildcardPattern: Add optional defaultMatches constructor parameter to specify return value of matches() when the pattern string is null or empty. - HtmlReportWriter: Show rules with priority 4. This enables configuring rules to be included in the report but not fail the build. - SourceCode: Add int getLineNumberForCharacterIndex(int charIndex). - CodeNarcRunner: Dont mandate that reportWriters is non-empty. OTHER - Publish CodeNarc to Maven repository. Changes in version 0.5 (24 May 2009) ------------------------------------ BUG FIXES - FIX: IllegalRegexRule: Dont stop after first violation. - FIX: VariableNameRule processing enums: "ArrayIndexOutOfBoundsException: Negative array index [-3] too large for array size 1". - FIX: BooleanInstantiationRule, VariableNameRule: Error parsing code with Enums. - FIX: Rules sometimes produce two violations for a single line. (e.g. EmptyElseBlockRule, PrintlnRule) POTENTIAL BREAKING CHANGES - Normalize all path separators (/,\) in SourceCode paths. - SourceCodeCriteria: Change applyToFilenames and doNotApplyToFilenames to applyToFileNames and doNotApplyToFileNames. - DirectorySourceAnalyzer: Change applyToFilenames and doNotApplyToFilenames to applyToFileNames and doNotApplyToFileNames. RULES - Created new "grails" RuleSet and nine new Rules: * GrailsStatelessServiceRule (Specially-configured StatelessClassRule) (grails) * GrailsPublicControllerMethodRule (grails) * GrailsServletContextReferenceRule (grails) * GrailsSessionReferenceRule (grails) * StatelessClassRule (generic) * EmptySynchronizedStatementRule (basic). * EmptySwitchStatementRule (basic). * EqualsAndHashCodeRule (basic) * JUnitPublicNonTestMethodRule (junit). - Change JUnit rules to use applyToClassNames=*Test,*Tests. - ClassSizeRule: Dont include package name in violation message. INFRASTRUCTURE - Support running CodeNarc as a command-line application (org.codenarc.CodeNarc). - Add support for Groovy rule scripts. - AbstractAstVisitorRule: Add applyToClassNames and doNotApplyToClassNames. Filter rules based on class and/or package. - AbstractRule. Add applyToFileNames and doNotApplyToFileNames (deprecate applyToFilenames and doNotApplyToFilenames). - Normalize all separators (/,\) in SourceCode paths to '/'. - AbstractRule: Enable setting violationMessage to empty string to turn it off. - HtmlReportWriter: Log output report filename. - Include number (index) of rule in Rule Descriptions section of HTML report. - Create CodeNarcRunner class; refactor CodeNarc and CodeNarcTask to use it. - HtmlReportWriter: Shrink font size of the rule descriptions at the end of the HTML report. - HtmlReportWriter: Remove "Source Directories" section. - Create FilesystemSourceAnalyzer. - Refactor WildcardPattern to (optionally) support comma-separated list of patterns. - Change WildcardPattern to support Ant-style ** wildcards. - Refactor AbstractRule and AbstractAstVisitor add/create Violation and source line helper methods. - Add createViolation(SourceCode, ASTNode) method to AbstractRule. - Add line(int) method to SourceCode to return trimmed source line. - Add createViolation() convenience method(s) to AbstractRule. - AbstractAstVisitor: Replace isAlreadyVisited() and registerAsVisited() with isFirstVisit(). DEPRECATIONS - AbstractRule: Deprecated applyToFilenames and doNotApplyToFilenames (replace with applyToFileNames and doNotApplyToFileNames). - Deprecated DirectorySourceAnalyzer. DOCUMENTATION - Create "Create Rule" document. - Add section in "Configuring Rules" on Turning Off a Rule. Changes in version 0.4 (31 Mar 2009) ------------------------------------ INFRASTRUCTURE - Support for wildcards (*,?) in RuleSet <include> and <exclude>, and in Rule.applyToFilenames. - Fix for configuration from properties files - allow setting superclass fields. - Add better logging, including stacktrace, when an error occurs during processing. - Format (and truncate) source line within the HtmlReportWriter. - Improve violation information for imports - line number and actual source line. - Make version at the bottom of the HTML report a link to the web site. - Refactor SourceCodeUtil to a SourceCodeCriteria class. - CodeNarcTask: Log elapsed time after analysis is complete. - CodeNarcTask: Dont fail build until after reports are generated. - Create WildcardPattern class. - Create AstUtil. Move isBlock() and isEmptyBlock() from AbstractAstVisitor. RULES - Created new "junit" and "logging" RuleSets and a bunch of new Rules: * JUnitAssertAlwaysSuccedsRule (junit) * JUnitAssertAlwaysFailsRule (junit) * JUnitTearDownCallsSuperRule (junit) * JUnitSetUpCallsSuperRule (junit) * SystemErrPrintRule. (logging) * SystemOutPrintRule. (logging) * PrintlnRule. (logging) * PrintStackTraceRule. (logging) * CatchNullPointerExceptionRule. (exceptions) * CatchExceptionRule. (exceptions) * CatchRuntimeExceptionRule. (exceptions) * CatchErrorRule. (exceptions) * ThrowThrowableRule (exceptions) * ThrowExceptionRule (exceptions) * ThrowNullPointerExceptionRule (exceptions) * ThrowRuntimeExceptionRule (exceptions) * ThrowErrorRule (exceptions) - BooleanInstantiationRule: Also check for Boolean.valueOf(true/false). DOCUMENTATION - Add example reports for open source Groovy projects: Grails, Griffon and Gradle. Changes in version 0.3 (02 Mar 2009) ------------------------------------ INFRASTRUCTURE - Read rules configuration from optional "codenarc.properties" file. (PropertiesRuleSetConfigurer). - CodeNarcTask: Add support for maxPriority3Violations property, etc. - AbstractRule: Add applyToFilenames and doNotApplyToFilenames - available to all rules (subclasses). - HtmlReportWriter: Display sourceLine and message on separate lines with named bullets. RULES - Created new "naming" RuleSets and new Rules: * AbstractClassNameRule. (naming) * ClassNameRule. (naming) * FieldNameRule. (naming) * InterfaceNameRule. (naming) * MethodNameRule. (naming) * PackageNameRule. (naming) * ParameterNameRule. (naming) * VariableNameRule. (naming) MINOR FIXES/ENHANCEMENTS - Fix NullPointerException for compiler errors from import rules. - AbstractRule: Introduce violationMessage property. Overrides default message if set. - Rename Violation description property to message. - Rename HtmlReportWriter CSS file to 'codenarc-htmlreport.css'. - Change SourceCodeUtil.shouldApplyTo() to take a Map of criteria. - Add setName() and setPriority() to AbstractRule. DOCUMENTATION - Add info to online docs re: standard rule properties. - Reorganize docs separate doc for each RuleSet; section for each rule; table for properties. - Update RuleSets doc with info about configuring using properties file. - Create "Configuring Rules" document (adapt existing "custom-rule-descriptions.apt"). Changes in version 0.2 (07 Feb 2009) ------------------------------------ - Create XML Schema Definition (XSD) for XML RuleSet file. * NOTE: RuleSet files MUST declare this schema * NOTE: RuleSet files are validated against this schema - More powerful and flexible RuleSet definition, including: * Nested RuleSets * Use <include> and <exclude> to filter rules from nested RuleSets * Use <rule-config> to configure rules from nested RuleSets - Created new "generic", "braces", and "size" RuleSets - Created new Rules: * IllegalRegexRule. (generic) * RequiredRegexRule. (generic) * ElseBlockBracesRule. (braces) * ForStatementBracesRule. (braces) * IfStatementBracesRule. (braces) * WhileStatementBracesRule. (braces) * MethodSizeRule. (size) * ClassSizeRule. (size) - Rule: Rename "id" property to "name". * NOTE: This is a potential breakage if you have defined custom Rules. - Flexible customization and localization of rule descriptions. ("codenarc-messages.properties") - HtmlReportWriter: Add setTitle(), setOutputFile() to ReportWriter interface. Changes in version 0.1 (24 Jan 2009) ------------------------------------ - Initial release. Includes 16 Rules; HtmlReportWriter; CodeNarcAntTask, DirectorySourceAnalyzer; XML RuleSets, etc.. |
|
From: Hamlet D. <ham...@ca...> - 2010-11-10 14:02:42
|
CodeNarc Change Log ------------------------------------------------------------------------------- http://www.codenarc.org Changes in version 0.11 (November 2010) ------------------------------------------- NEW FEATURES - @SuppressWarnings support. All rules now recognize the java.lang.SuppressWarnings annotation on fields, methods, and classes. If this annotation is added then there will be no violations produced. Just as in Java, the annotation requires a String or List<String> parameter. For example, annotating a class with @SuppressWarnings('UnusedPrivateField') will ignore the rule for that class. Annotating a method with @SuppressWarnings(['UnusedPrivateField', 'UnnecessaryIfStatementRule']) will ignore both rules for the annotated method. - Better "codenarc create-rule" support. You can create a new rule by running "codenarc create-rule" from the root of the CodeNarc codebase. This script has been updated to properly format Javadoc, prompt for the author name, and update the Maven Site .apt documentation. NEW RULES BooleanMethodReturnsNull Rule (basic) : Checks for a method with Boolean return type that returns an explicit null. DeadCode Rule (basic) : Checks for dead code that appears after a return statement or after an exception is thrown. DoubleNegative Rule (basic) : Checks for using a double negative, which is always positive. DuplicateCaseStatement Rule (basic) : Check for duplicate case statements in a switch block, such as two equal integers or strings. ExplicitCallToAndMethod Rule (basic) : This rule detects when the and(Object) method is called directly in code instead of using the & operator. ExplicitCallToCompareToMethod Rule (basic) : This rule detects when the compareTo(Object) method is called directly in code instead of using the <=>, >, >=, <, and <= operators. ExplicitCallToDivMethod Rule (basic) : This rule detects when the div(Object) method is called directly in code instead of using the / operator. ExplicitCallToEqualsMethod Rule (basic) : This rule detects when the equals(Object) method is called directly in code instead of using the == or != operator. ExplicitCallToGetAtMethod Rule (basic) : This rule detects when the getAt(Object) method is called directly in code instead of using the [] index operator. ExplicitCallToLeftShiftMethod Rule (basic) : This rule detects when the leftShift(Object) method is called directly in code instead of using the \<\< operator. ExplicitCallToMinusMethod Rule (basic) : This rule detects when the minus(Object) method is called directly in code instead of using the - operator. ExplicitCallToMultiplyMethod Rule (basic) : This rule detects when the multiply(Object) method is called directly in code instead of using the * operator. ExplicitCallToModMethod Rule (basic) : This rule detects when the mod(Object) method is called directly in code instead of using the % operator. ExplicitCallToOrMethod Rule (basic) : This rule detects when the or(Object) method is called directly in code instead of using the | operator. ExplicitCallToPlusMethod Rule (basic) : This rule detects when the plus(Object) method is called directly in code instead of using the + operator. ExplicitCallToPowerMethod Rule (basic) : This rule detects when the power(Object) method is called directly in code instead of using the ** operator. ExplicitCallToRightShiftMethod Rule (basic) : This rule detects when the rightShift(Object) method is called directly in code instead of using the \>\> operator. ExplicitCallToXorMethod Rule (basic) : This rule detects when the xor(Object) method is called directly in code instead of using the ^ operator. ExplicitCreationOfArrayList Rule (basic) : This rule checks for the explicit instantiation of an ArrayList. In Groovy, it is best to write new ArrayList() as [], which creates the same object. ExplicitCreationOfHashMap Rule (basic) : This rule checks for the explicit instantiation of a HashMap. In Groovy, it is best to write new HashMap() as [:], which creates the same object. ExplicitCreationOfHashSet Rule (basic) : This rule checks for the explicit instantiation of a HashSet. In Groovy, it is best to write new HashSet() as [] as Set, which creates the same object. ExplicitCreationOfLinkedList Rule (basic) : This rule checks for the explicit instantiation of a LinkedList. In Groovy, it is best to write new LinkedList() as [] as Queue, which creates the same object. ExplicitCreationOfStack Rule (basic) : This rule checks for the explicit instantiation of a Stack. In Groovy, it is best to write new Stack() as [] as Stack, which creates the same object. ExplicitCreationOfTreeSet Rule (basic) : This rule checks for the explicit instantiation of a TreeSet. In Groovy, it is best to write new TreeSet()>> as [] as SortedSet, which creates the same object. GStringAsMapKey Rule A GString should not be used as a map key since its hashcode is not guaranteed to be stable. InvertedIfElse Rule (basic) : An inverted if-else statement is one in which there is a single if statement with a single else branch and the boolean test of the if is negated. RemoveAllOnSelf Rule (basic) : Don't use removeAll to clear a collection. ReturnsNullInsteadOfEmptyArray Rule (basic) : If you have a method or closure that returns an array, then when there are no results return a zero-length (empty) array rather than null. ReturnsNullInsteadOfEmptyCollection Rule (basic) : If you have a method or closure that returns a collection, then when there are no results return a zero-length (empty) collection rather than null. SerialVersionUID Rule (basic) : A serialVersionUID is normally intended to be used with Serialization. It needs to be of type long, static, and final. UnnecessaryConstructor Rule (basic) : This rule detects when a constructor is not necessary; i.e., when there's only one constructor, it's public, has an empty body, and takes no arguments. UselessCollectionCall Rule (basic) : Checks for useless calls to collections. UselessOverridingMethod Rule (basic) : Checks for an overriding method that merely calls the same method defined in a superclass. UnnecessaryReturnKeyword Rule (basic) : In Groovy, the return keyword is often optional. SynchronizedOnGetClass Rule (concurrency) : Checks for synchronization on getClass() rather than class literal. UseOfNotifyMethod Rule (concurrency) : Checks for code that calls notify() rather than notifyAll(). DuplicateNumberLiteral Rule (dry) : This rule checks for duplicate number literals within the current class. DuplicateStringLiteral Rule (dry) : This rule checks for duplicate String literals within the current class. CatchIllegalMonitorStateException Rule (exceptions) : Dubious catching of IllegalMonitorStateException. ConfusingClassNamedException Rule (exceptions) : This class is not derived from another exception, but ends with 'Exception'. ReturnNullFromCatchBlock Rule (exceptions) : Returning null from a catch block often masks errors and requires the client to handle error codes. UseAssertEqualsInsteadOfAssertTrue Rule (junit) : This rule detects JUnit assertions in object equality. UseAssertTrueInsteadOfAssertEqualsRule Rule (junit) : This rule detects JUnit calling assertEquals where the first parameter is a boolean. UseAssertNullInsteadOfAssertEquals Rule (junit) : This rule detects JUnit calling assertEquals where the first or second parameter is null. UseAssertSameInsteadOfAssertTrue Rule (junit) : This rule detects JUnit calling assertTrue or assertFalse where the first or second parameter is an Object#is() call testing for reference equality. UseFailWithMessageInsteadOfWithout Rule (junit) : This rule detects JUnit calling the fail() method without an argument. UsingJUnitStyleAssertions Rule (junit) : This rule detects calling JUnit style assertions like assertEquals, assertTrue, assertFalse, assertNull, assertNotNull. ConfusingMethodName Rule (naming) : Checks for very confusing method names. The referenced methods have names that differ only by capitalization. ObjectOverrideMisspelledMethodName Rule (naming) : Verifies that the names of the most commonly overridden methods of Object: equals, hashCode and toString, are correct. MethodCount Rule (size) : Checks if the number of methods within a class exceeds the number of lines specified by the maxMethod property. BUG FIXES - None reported, none fixed! OTHER CHANGES - CodeNarc now requires Groovy 1.7 to run. Keep in mind that it can still run against (analyze) older Groovy code. - There is a new rule category called "dry", meaning "do not repeat yourself". - AstUtil enhancements - For writers of rules: there are new utility methods in the AstUtil class. See the javadoc for more details. - AbstractAstVisitor Breaking Changes - If you implemented your own rule by subclassing AbstractAstVisitor then your code might break. It is a compile error and the breakage will be clear and obvious. In order to support @SuppressWarnings, we needed to change AbstractAstVisitor. The method visitMethodNode became visitMethodNodeEx, visitClass became visitClassEx, visitConstructorOrMethod became visitConstructorOrMethodEx, visitField became visitFieldEx, visitProperty became visitPropertyEx, and visitConstructor became visitConstructorEx. From within these new methods there is no need to call super.visitX. In the rare case that the simple renaming does not fix your problem then please contact the mailing list. Changes in version 0.10 (26 September 2010) ------------------------------------------- BUG FIXES - Fix Bug #3071531: "Unused rules don't recognized method closures". https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=3071531&group_id=250145. e.g. private def bar() { } .. return this.&bar; - Fix: UnusedPrivateField: Dont produce violation if field is a Closure field and is executed. - Fix: ImportFromSamePackage: Fix for (ignore) alias imports within same package. package org.xyz; import org.xyz.MyBigClass as MBC. NEW RULES - New UnnecessaryIfStatementRule (basic): Checks for if statements where the if and else blocks are only returning true and false constants. if(x) { return true } else { return false }. - New UnnecessaryBooleanExpressionRule (basic): Check for unnecessary boolean expressions, including ANDing (&&) or ORing (||) with true, false, null, or Map/List/String/Number literal. Also checks for negation of true, false, null, or Map/List/String/Number literal. - New BigDecimalInstantiationRule (basic): Avoid creating BigDecimal with a decimal (float/double) literal. Use a String literal. From PMD. See http://pmd.sourceforge.net/rules/basic.html#AvoidDecimalLiteralsInBigDecimalConstructor. Note that println new BigDecimal(0.1) prints out 0.1000000000000000055511151231257827021181583404541015625. - UnusedObjectRule (unused): Checks for object allocations that are not assigned or used, unless it is the last statement within a block (because it may be the intentional return value). - New UnusedArrayRule (unused): This inspection reports any instances of Groovy array allocation where the array allocated is ignored. Such allocation expressions are legal Groovy, but are usually either inadvertent, or evidence of a very odd object initialization strategy. (IntelliJ). When an ExpressionStatement has as its expression an ArrayExpression. - Implement ImplementationAsTypeRule (design): Checks that particular classes are never used as types in variable declarations, return values or parameters. GregorianCalendar, HashMap, HashSet, Hashtable, LinkedList, LinkedHashMap, LinkedHashSet, TreeSet, TreeMap, Vector, ArrayList, CopyOnWriteArrayList, CopyOnWriteArraySet, ConcurrentHashMap, ArrayBlockingQueue, ConcurrentLinkedQueue, DelayQueue, LinkedBlockingQueue, PriorityBlockingQueue, PriorityQueue, SynchronousQueue (see Checkstyle). (design) - New JUnitUnnecessaryTearDownRule (junit). Checks for tearDown() methods that only call super.tearDown(). - New JUnitUnnecessarySetUpRule (junit). Checks for setUp() methods that only call super.setUp(). NEW REPORT WRITER - New InlineXmlReportWriter (from Robin Bramley) for improved integration with the Hudson Violations plugin. See http://wiki.hudson-ci.org/display/HUDSON/Violations. OTHER CHANGES - CodeNarc now requires Groovy 1.6 to run. Keep in mind that it can still run against (analyze) older Groovy code. - Upgrade to GMetrics 0.3 for AbcComplexityRule and CyclomaticComplexityRule. Violations now include line number and source line. - All JUnit rules (JUnit*Rule): Also apply to classes with names ending in *TestCase. - Add codenarc create-rule script to create a new rule and associated classes/tests. https://sourceforge.net/tracker/?func=detail&aid=3005873&group_id=250145&atid=1126575. (Hamlet D'Arcy) - ConstantTernaryExpressionRule: Also flag constant Map and List expressions. - ConstantIfExpressionRule: Also flag constant Map and List expressions. - GrailsPublicControllerMethod: add ignoreMethodNames property. - Add reference to Sonar plugin. http://docs.codehaus.org/display/SONAR/Groovy+Plugin to web site. - Add reference to Hudson Violations Plugin. http://wiki.hudson-ci.org/display/HUDSON/Violations to web site. Changes in version 0.9 (10 May 2010) ------------------------------------ BUG FIXES - Fix bug #2985592: "MissingPropertyException: No such property: W3C_XML_SCHEMA_NS_URI". - XML RuleSet: Allow wildcards (*) in <include> and <exclude>. - WildcardPattern: Escape plus sign ('+'). - NestedBlockDepthRule: Ignore first level of closure for Closure Fields (since they are really equivalent to methods). NEW SIZE/COMPLEXITY RULES - AbcComplexityRule - Check ABC size/complexity score against threshold for method and class average (size) - CyclomaticComplexityRule - Check Cyclomatic Complexity against threshold for method and class average (size) NEW CONCURRENCY RULES - NestedSynchronizationRule (concurrency - Hamlet DArcy) - RunFinalizersOnExitRule (concurrency - Hamlet DArcy) - SynchronizedMethodRule (concurrency - Hamlet DArcy) - SynchronizedOnThisRule (concurrency - Hamlet DArcy) - ThreadLocalNotStaticFinalRule (concurrency - Hamlet DArcy) - ThreadYieldRule: (concurrency - Hamlet DArcy) - VolatileLongOrDoubleFieldRule: (concurrency - Hamlet DArcy) NEW BASIC RULES - CloneableWithoutCloneRule (basic - Hamlet D'Arcy & René Gröschke) - ConstantIfExpressionRule: if(true) or if(false). Or literal constant. (basic) - ConstantTernaryExpressionRule: true ? x : y or false, null or literal.(basic) - UnnecessaryTernaryExpressionRule: x ? true : false. Or Boolean.TRUE. Or where both expressions are the same. (basic) OTHER CHANGES - Deprecate GrailsSessionReferenceRule. Default enabled to false. Note in online docs. - StatelessClassRule: Add setAddToIgnoreFieldNames() method (adds to ignoreFieldNames). - Add new <rule>.description.html property for each rule. Change the HtmlReportWriter to look for *.description.html first; if not defined, use *.description. Continue to use *.description in XML report. Potential BREAKAGE: If you have overridden the "<rule>.description" message for a predefined rule in a "codenarc-messages.properties" file, you will have to change those message keys to "<rule>.description.html". - Do not include disabled rules in list of rules at bottom of HTML/XML report. - HtmlReportWriter: Dont log warning if "codenarc-messages.properties" contains *.description but not *.description.html. - UnusedVariableRule: Fix limitation: Does not recognize variable references on the same line as the variable declaration. - GroovyDslRuleSet: Throw MissingPropertyException if a non-existent property is set within a Groovy RuleSet DSL. - CodeNarcRunner: Add System.out println of summary counts. - MethodSizeRule: Apply to constructors as well. - WildcardPattern: Trim pattern values. This includes property values such as common rule properties applyToFileNames/doNotApplyToFileNames, applyToClassNames/doNotApplyToClassNames. Or many rule-specific properties such as ignoreMethodNames for the MethodSizeRule. - PropertiesFileRuleSetConfigurer: Log warning if rule name not found. - TESTS: AbstractRuleTestCase: Add assertViolations(String source, Map[] violationMaps) helper method. - TESTS: Fix tests broken on Linux. Changes in version 0.8.1 (2 Feb 2010) ------------------------------------ BUG FIXES - Fix Bug #2943025: "NestedBlockDepthRule: Produces erroneous results on Groovy 1.6.x." https://sourceforge.net/tracker/?func=detail&aid=2943025&group_id=250145&atid=1126573 - Fix Bug #2943028: "PackageNameRule may show incorrect violations for classes within the default package when running in Groovy 1.6.x." https://sourceforge.net/tracker/?func=detail&aid=2943028&group_id=250145&atid=1126573 - Fix Bug #2935587 "Building CodeNarc 0.8 fails." - Problem from Joern Huxhorn (Jan 18, 2010) Unable to build from the downloaded CodeNarc-0.8-bin.tar.gz. http://sourceforge.net/tracker/?func=detail&aid=2935587&group_id=250145&atid=1126573. See CodeNarc - Unable to Build From TarGZip.doc. Remove platform/locale dependencies: AbstractReportWriterTest, UrlResourceTest, GrailsSessionReferenceRuleTest, GrailsPublicControllerMethodRuleTest, GrailsServletContextReferenceRuleTest, GrailsStatelessServiceRuleTest. [Jan 24] - Fix StackOverflow in Groovy 1.7.0 for some rules: All rules that implement the visitVariableExpression(VariableExpression expression) visitor method: UnusedVariableRule, UnusedPrivateFieldRule, GrailsSessionReferenceRule, GrailsServletContextReferenceRule Removed call to super.visitVariableExpression(expression) since that seems to cause problems (StackOverflow) in Groovy 1.7.0. - Fix tests broken when running in Groovy 1.6 or Groovy 1.7. - DuplicateImportRule: Document that this rule does not work when running under Groovy 1.7 (i.e., will not produce any violations), and does not distinguish between multiple duplicate imports for the same class. Changes in version 0.8 (17 Jan 2010) ------------------------------------ BUG FIXES - Fix Bug #2930886: "Cannot load rules when groovy is in different classloader". XmlReaderRuleSet, ReportWriterFactory: Replace calls to Class.forName() with getClass().classLoader.loadClass(). https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=2930886&group_id=250145. - Fix Bug #2847520: "UnusedVariableRule: Closure variable must be invoked". UnusedVariableRule: Referencing an (explicit) Closure variable without invoking it is not recognized as a valid reference. e.g., final CLOSURE = { .. }; return CLOSURE. https://sourceforge.net/tracker/?func=detail&aid=2847520&group_id=250145&atid=1126573 - Fix false positive: Local closures: If a closure is assigned to a local variable, then used later in the method, CodeNarc report the variable unused. [I think this has already been resolved, perhaps as part of Bug #2847520]. (reported by Donal Murtagh) - Fix false positive: Default arguments: If a constant is only used as the value of a default argument, CodeNarc reports this constant unused. (reported by Donal Murtagh) REPORTS - Create XmlReportWriter for wrting out an XML report ("xml"). (beta) - Create TextReportWriter. Writes out text report with violations by file and priority and summary counts. - Enable configuring all provided ReportWriters (HtmlReportWriter, XmlReportWriter, TextReportWriter) to write to the stdout (console). - Enable specifying the full class name of a custom ReportWriter class. - CodeNarcTask: Add support for <option> nested elements under the <report> element. - HtmlReportWriter: Externalize strings to resource bundle. - Remove setTitle() and setOutputFile() from ReportWriter interface. - ReportWriter: Rename writeOutReport() method to writeReport(). - Create AbstractReportWriter. RULES - Create new NestedBlockDepthRule. Checks for nesting of all types of block statements (and closures), including for, if, while, try and switch statements. (design) - MethodSizeRule: Add support for "ignoreMethodNames" property to enable filtering. - AbstractRule: Enhance applyToFileNames to handle optional path (e.g. "abc/def/MyClass.groovy"). - AbstractRule: The (previously deprecated) applyToFilenames and doNotApplyToFilenames properties now throw an UnsupportedOperationException. - AbstractRule: Add optional description property; Use it in report if specified. OTHER CHANGES - Allow spaces within comma-separated list of ruleset files. Applies when specifying ruleset files for the CodeNarc Ant Task or the CodeNarc script. - CodeNarcRunner: Dont require that reportWriters is non-empty. - AntFileSetSourceAnalyzer: Specify sourceDirectories relative to project base directory. - Reorganize web site. Add Reports section. Add pages for HTML, XML and and text reports. - Add support and documentation for running CodeNarc as part of an automated test suite (e.g. JUnit). - Add List getSourceDirectories() to SourceAnalyzer interface and implementation classes. - Change "codenarc-version.txt" to contain only the version number. - Rename AbstractTest to AbstractTestCase. Changes in version 0.7 (25 Aug 2009) ------------------------------------ BUG FIXES - Fix Bug #2825698: "UnusedVariableRule: stops after 1st unused variable per name". https://sourceforge.net/tracker/?func=detail&aid=2825698&group_id=250145&atid=1126573. - Fix Bug #2828696: "UnusedImport rule with fully qualified class reference" https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=2828696&group_id=250145. - UnusedImportRule: Add support for static imports. Document known limitation: will not work on imports with wildcards. - UnnecessaryGroovyImportRule: Add java.net as another automatically included package. NEW FEATURES AND INFRASTRUCTURE - Groovy DSL for defining RuleSets. (GroovyDslRuleSet and RuleSetBuilder). - Enable optional prefix of "file:", "http:" or any other standard URL prefix for resource files, including ruleset files, "codenarc.properties" and rule scripts. * Addresses Tracker Issue #2828616: "Allow ruleset file to be specified as a file or url" https://sourceforge.net/tracker/?func=detail&atid=1126575&aid=2828616&group_id=250145. - CodeNarcTask and AntFileSetSourceAnalyzer: Allow more than one FileSet to be added. * Addresses Tracker Issue #2831255: "Ant task should accept any ResourceCollection for source" https://sourceforge.net/tracker/?func=detail&aid=2831255&group_id=250145&atid=1126575. - HtmlReportWriter: Show rule name in color according to priority. - CompositeRuleSet: Rename add(RuleSet) to addRuleSet(RuleSet). Add addRule(Rule). RULES - Create new PropertyNameRule. (naming) - FieldNameRule: Do not apply to property fields. Changes in version 0.6 (17 Jul 2009) ------------------------------------ BUG FIXES - Fix BUG #2798845 : "StringIndexOutOfBoundsException" https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=2798845&group_id=250145 - Fix BUG #2799752: GrailsPublicControllerMethodRule - should only apply itself to methods within classes that have suffix "Controller". (see email from Jason Anderson, May 26, 2009) https://sourceforge.net/tracker/?func=detail&aid=2799752&group_id=250145&atid=1126573 - Fix BUG #2796953: StatelessClassRule requires applyToFileNames or applyToFilesMatching. https://sourceforge.net/tracker/?func=detail&atid=1126573&aid=2796953&group_id=250145 - Fix BUG #2811213: "FieldNameRule: Names for final fields - not be all caps". FieldNameRule: Field names for final instance fields should not default to be all caps like static final fields. For instance: final List sentEmails = []. Rather, "If a property is declared final the private field is created final and no setter is generated." (http://groovy.codehaus.org/Groovy+Beans). So, they should be named with "normal" naming conventions. Re-purpose the finalRegex property to just apply to final instance fields and default to null so that final field names use same convention as non-final. https://sourceforge.net/tracker/?func=detail&aid=2811213&group_id=250145&atid=1126573. - Fix: GrailsStatelessServiceRule: Should only apply to *Service classes. RULES - Implement UnusedVariableRule. (unused) - Implement UnusedPrivateMethodRule. (unused) - Implement UnusedPrivateFieldRule. (unused). - MethodNameRule: Add support for ignoreMethodNames. - ParameterNameRule: Add support for ignoreParameterNames. - VariableNameRule: Add support for ignoreVariableNames. - FieldNameRule: Add support for ignoreFieldNames. - IllegalRegexRule: Include line numbers in rule violations. INFRASTRUCTURE - Allow setting custom name and path for "codenarc.properties" file using "codenarc.properties.file" system property. - WildcardPattern: Add optional defaultMatches constructor parameter to specify return value of matches() when the pattern string is null or empty. - HtmlReportWriter: Show rules with priority 4. This enables configuring rules to be included in the report but not fail the build. - SourceCode: Add int getLineNumberForCharacterIndex(int charIndex). - CodeNarcRunner: Dont mandate that reportWriters is non-empty. OTHER - Publish CodeNarc to Maven repository. Changes in version 0.5 (24 May 2009) ------------------------------------ BUG FIXES - FIX: IllegalRegexRule: Dont stop after first violation. - FIX: VariableNameRule processing enums: "ArrayIndexOutOfBoundsException: Negative array index [-3] too large for array size 1". - FIX: BooleanInstantiationRule, VariableNameRule: Error parsing code with Enums. - FIX: Rules sometimes produce two violations for a single line. (e.g. EmptyElseBlockRule, PrintlnRule) POTENTIAL BREAKING CHANGES - Normalize all path separators (/,\) in SourceCode paths. - SourceCodeCriteria: Change applyToFilenames and doNotApplyToFilenames to applyToFileNames and doNotApplyToFileNames. - DirectorySourceAnalyzer: Change applyToFilenames and doNotApplyToFilenames to applyToFileNames and doNotApplyToFileNames. RULES - Created new "grails" RuleSet and nine new Rules: * GrailsStatelessServiceRule (Specially-configured StatelessClassRule) (grails) * GrailsPublicControllerMethodRule (grails) * GrailsServletContextReferenceRule (grails) * GrailsSessionReferenceRule (grails) * StatelessClassRule (generic) * EmptySynchronizedStatementRule (basic). * EmptySwitchStatementRule (basic). * EqualsAndHashCodeRule (basic) * JUnitPublicNonTestMethodRule (junit). - Change JUnit rules to use applyToClassNames=*Test,*Tests. - ClassSizeRule: Dont include package name in violation message. INFRASTRUCTURE - Support running CodeNarc as a command-line application (org.codenarc.CodeNarc). - Add support for Groovy rule scripts. - AbstractAstVisitorRule: Add applyToClassNames and doNotApplyToClassNames. Filter rules based on class and/or package. - AbstractRule. Add applyToFileNames and doNotApplyToFileNames (deprecate applyToFilenames and doNotApplyToFilenames). - Normalize all separators (/,\) in SourceCode paths to '/'. - AbstractRule: Enable setting violationMessage to empty string to turn it off. - HtmlReportWriter: Log output report filename. - Include number (index) of rule in Rule Descriptions section of HTML report. - Create CodeNarcRunner class; refactor CodeNarc and CodeNarcTask to use it. - HtmlReportWriter: Shrink font size of the rule descriptions at the end of the HTML report. - HtmlReportWriter: Remove "Source Directories" section. - Create FilesystemSourceAnalyzer. - Refactor WildcardPattern to (optionally) support comma-separated list of patterns. - Change WildcardPattern to support Ant-style ** wildcards. - Refactor AbstractRule and AbstractAstVisitor add/create Violation and source line helper methods. - Add createViolation(SourceCode, ASTNode) method to AbstractRule. - Add line(int) method to SourceCode to return trimmed source line. - Add createViolation() convenience method(s) to AbstractRule. - AbstractAstVisitor: Replace isAlreadyVisited() and registerAsVisited() with isFirstVisit(). DEPRECATIONS - AbstractRule: Deprecated applyToFilenames and doNotApplyToFilenames (replace with applyToFileNames and doNotApplyToFileNames). - Deprecated DirectorySourceAnalyzer. DOCUMENTATION - Create "Create Rule" document. - Add section in "Configuring Rules" on Turning Off a Rule. Changes in version 0.4 (31 Mar 2009) ------------------------------------ INFRASTRUCTURE - Support for wildcards (*,?) in RuleSet <include> and <exclude>, and in Rule.applyToFilenames. - Fix for configuration from properties files - allow setting superclass fields. - Add better logging, including stacktrace, when an error occurs during processing. - Format (and truncate) source line within the HtmlReportWriter. - Improve violation information for imports - line number and actual source line. - Make version at the bottom of the HTML report a link to the web site. - Refactor SourceCodeUtil to a SourceCodeCriteria class. - CodeNarcTask: Log elapsed time after analysis is complete. - CodeNarcTask: Dont fail build until after reports are generated. - Create WildcardPattern class. - Create AstUtil. Move isBlock() and isEmptyBlock() from AbstractAstVisitor. RULES - Created new "junit" and "logging" RuleSets and a bunch of new Rules: * JUnitAssertAlwaysSuccedsRule (junit) * JUnitAssertAlwaysFailsRule (junit) * JUnitTearDownCallsSuperRule (junit) * JUnitSetUpCallsSuperRule (junit) * SystemErrPrintRule. (logging) * SystemOutPrintRule. (logging) * PrintlnRule. (logging) * PrintStackTraceRule. (logging) * CatchNullPointerExceptionRule. (exceptions) * CatchExceptionRule. (exceptions) * CatchRuntimeExceptionRule. (exceptions) * CatchErrorRule. (exceptions) * ThrowThrowableRule (exceptions) * ThrowExceptionRule (exceptions) * ThrowNullPointerExceptionRule (exceptions) * ThrowRuntimeExceptionRule (exceptions) * ThrowErrorRule (exceptions) - BooleanInstantiationRule: Also check for Boolean.valueOf(true/false). DOCUMENTATION - Add example reports for open source Groovy projects: Grails, Griffon and Gradle. Changes in version 0.3 (02 Mar 2009) ------------------------------------ INFRASTRUCTURE - Read rules configuration from optional "codenarc.properties" file. (PropertiesRuleSetConfigurer). - CodeNarcTask: Add support for maxPriority3Violations property, etc. - AbstractRule: Add applyToFilenames and doNotApplyToFilenames - available to all rules (subclasses). - HtmlReportWriter: Display sourceLine and message on separate lines with named bullets. RULES - Created new "naming" RuleSets and new Rules: * AbstractClassNameRule. (naming) * ClassNameRule. (naming) * FieldNameRule. (naming) * InterfaceNameRule. (naming) * MethodNameRule. (naming) * PackageNameRule. (naming) * ParameterNameRule. (naming) * VariableNameRule. (naming) MINOR FIXES/ENHANCEMENTS - Fix NullPointerException for compiler errors from import rules. - AbstractRule: Introduce violationMessage property. Overrides default message if set. - Rename Violation description property to message. - Rename HtmlReportWriter CSS file to 'codenarc-htmlreport.css'. - Change SourceCodeUtil.shouldApplyTo() to take a Map of criteria. - Add setName() and setPriority() to AbstractRule. DOCUMENTATION - Add info to online docs re: standard rule properties. - Reorganize docs separate doc for each RuleSet; section for each rule; table for properties. - Update RuleSets doc with info about configuring using properties file. - Create "Configuring Rules" document (adapt existing "custom-rule-descriptions.apt"). Changes in version 0.2 (07 Feb 2009) ------------------------------------ - Create XML Schema Definition (XSD) for XML RuleSet file. * NOTE: RuleSet files MUST declare this schema * NOTE: RuleSet files are validated against this schema - More powerful and flexible RuleSet definition, including: * Nested RuleSets * Use <include> and <exclude> to filter rules from nested RuleSets * Use <rule-config> to configure rules from nested RuleSets - Created new "generic", "braces", and "size" RuleSets - Created new Rules: * IllegalRegexRule. (generic) * RequiredRegexRule. (generic) * ElseBlockBracesRule. (braces) * ForStatementBracesRule. (braces) * IfStatementBracesRule. (braces) * WhileStatementBracesRule. (braces) * MethodSizeRule. (size) * ClassSizeRule. (size) - Rule: Rename "id" property to "name". * NOTE: This is a potential breakage if you have defined custom Rules. - Flexible customization and localization of rule descriptions. ("codenarc-messages.properties") - HtmlReportWriter: Add setTitle(), setOutputFile() to ReportWriter interface. Changes in version 0.1 (24 Jan 2009) ------------------------------------ - Initial release. Includes 16 Rules; HtmlReportWriter; CodeNarcAntTask, DirectorySourceAnalyzer; XML RuleSets, etc.. |
|
From: <chr...@wa...> - 2010-11-10 13:54:24
|
Ok. In general, I have been preferring "lightweight" releases -- no branching; just roll changes/fixes into next release; and do next release sooner if necessary. But we can consider this a special case, since it is time-constrained. I'll plan on doing a 0.11-RC1 release, and we can create a branch. Is the weekend ok for that? When do you need it? Chris Hamlet DArcy <ham...@ca...> 11/10/2010 01:25 AM To Chris Mair <chr...@ea...> cc Cod...@li... Subject Re: [Codenarc-developer] 0.11 release planning thread Hmmm, I'll work on the CHANGELOG.txt file and javadoc in AstUtil. That way no new rules get checked in today. Perhaps it is best to build and upload 0.11 RC1 or Beta1 and branch the codebase. Then we have time to clean up false positives and issues while still allowing early adopters to check out the new work (and help with the bug reports!) -- Hamlet D'Arcy ham...@ca... Hamlet, In addition to the items in your list, I typically: A) Create a snapshot release and run that against several large Groovy projects at work, and examine the violations. In almost every release that has ended up revealing an issue or two -- often a false negative or false positive in a new rule. B) Run the new code version against the open source projects (Grails, Griffon, Gradle) and pull in the resulting reports. C) Deploy to the Maven Central Repo after the release D) Tag the project version in SVN I will plan to do all of the above. I will also do #3 (Grails plugin) from your list - usually a a few days after the release. You are more than welcome to do #2, #4 (I do not have Gradle commit rights) and #5. For #6 (email announcements), I was intending on collaborating with you. For #0 (Change log), if you want to do a draft version in the "CHANGELOG.txt" version that would be great, but not required. I will have a few additions of my own. To be honest, I am struggling to keep up with all of the recent additions/changes (though I am absolutely NOT complaining!!!). I don't have a lot of time to work on this each day. It will take me at least a few days to catch up and get my own changes done before the release. Are you pretty much done with your changes? Thanks a lot. Chris -----Original Message----- From: Hamlet D'Arcy [mailto:ham...@gm...] Sent: Tuesday, November 09, 2010 2:57 PM To: Cod...@li... Subject: [Codenarc-developer] 0.11 release planning thread Chris, You're the owner, so it is of course up to you to run the 0.11 release the way you want. As a list of todos, we need to: 0. Create the Changelog 1. Build and upload new version 2. Update Griffon plugin (i have commit rights and can do this) 3. UPdate Grails plugin (do you have commit rights?) 4. Update Gradle plugin (do you have commit rights?) 5. Publish a blogpost/page with more info about all the new rules (i can do this) 6. Send email announcements to groovy, griffon, grails, & hackergarten lists Which do you need the most help with? What is missing? -- Hamlet D'Arcy ham...@gm... ---------------------------------------------------------------------------- -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ForwardSourceID:NT000CE31E |
|
From: Hamlet D. <ham...@ca...> - 2010-11-10 06:27:44
|
Do whatever you want with the docs. Just let me know what you did so I can update the "create-rule" script to do the same. -- Hamlet D'Arcy ham...@ca... Message I refined the formatting of all of those "New in 0.11" messages, so that they looked ok when the web pages are rendered. I also changed them all to "Since CodeNarc 0.11" so that we don't have to update them when we put out 0.12, etc.. I also reorderd the new rule documentation to be in alphabetical order. Otherwise it is difficult to find rule documentation for a specific rule, especially within a big ruleset like "basic". Please do that when you add new rules. I am still considering adding an index or table of contents for some of the bigger rulesets, or perhaps an index for all of the rules (if I can generate it from a script). Thanks. Chris -----Original Message----- From: Hamlet D'Arcy [mailto:ham...@gm...] Sent: Tuesday, November 09, 2010 2:47 PM To: chr...@wa...; Cod...@li... Subject: Re: [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki The .apt files are now updated with "new in 0.11" -- Hamlet D'Arcy ham...@gm... On Tue, Nov 9, 2010 at 2:31 PM, < chr...@wa... > wrote: That sounds fine. I thought maybe you were suggesting updating and releasing the docs today, to get a one-week head start. But it sounds like we are on the same page. Hamlet DArcy < ham...@ca... > 11/09/2010 08:21 AM To chris mair < chr...@wa... > cc cod...@li... Subject Re: [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki Of course we will update the docs before the release. But I was thinking that next month maybe someone contributes a better description and then what do we do... we can just run mvn site and upload with no problems. -- Hamlet D'Arcy ham...@ca... If we are going to do the 0.11 release within the next week or so, can we just release it all together? Hamlet DArcy < ham...@ca... > 11/09/2010 07:53 AM To chris mair < chr...@wa... > cc cod...@li... Subject Re: [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki And if we document the .apt files with "since 0.11" then releasing new docs with changes from the head will not break anything. Let's do it. -- Hamlet D'Arcy ham...@ca... >> What do you think about documenting the new rules with "since 0.11" in the .apt file. That sounds like a great idea. >> Can the site documentation be updated outside of a build cycle? Yes, if needed, we could run the mvn site goal to rebuild the site, and then transfer the files up to the SourceForge directory, without doing a formal release. Chris Hamlet DArcy < ham...@ca... > 11/09/2010 07:41 AM To cod...@li... cc Subject [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki What do you think about documenting the new rules with "since 0.11" in the .apt file. That way they could be easily found. Can the site documentation be updated outside of a build cycle? -- Hamlet D'Arcy ham...@ca... ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev_______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ForwardSourceID:NT000CE136 ForwardSourceID:NT000CE14E ForwardSourceID:NT000CE182 ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer |
|
From: Hamlet D. <ham...@ca...> - 2010-11-10 06:25:38
|
Hmmm, I'll work on the CHANGELOG.txt file and javadoc in AstUtil. That way no new rules get checked in today. Perhaps it is best to build and upload 0.11 RC1 or Beta1 and branch the codebase. Then we have time to clean up false positives and issues while still allowing early adopters to check out the new work (and help with the bug reports!) -- Hamlet D'Arcy ham...@ca... Hamlet, In addition to the items in your list, I typically: A) Create a snapshot release and run that against several large Groovy projects at work, and examine the violations. In almost every release that has ended up revealing an issue or two -- often a false negative or false positive in a new rule. B) Run the new code version against the open source projects (Grails, Griffon, Gradle) and pull in the resulting reports. C) Deploy to the Maven Central Repo after the release D) Tag the project version in SVN I will plan to do all of the above. I will also do #3 (Grails plugin) from your list - usually a a few days after the release. You are more than welcome to do #2, #4 (I do not have Gradle commit rights) and #5. For #6 (email announcements), I was intending on collaborating with you. For #0 (Change log), if you want to do a draft version in the "CHANGELOG.txt" version that would be great, but not required. I will have a few additions of my own. To be honest, I am struggling to keep up with all of the recent additions/changes (though I am absolutely NOT complaining!!!). I don't have a lot of time to work on this each day. It will take me at least a few days to catch up and get my own changes done before the release. Are you pretty much done with your changes? Thanks a lot. Chris -----Original Message----- From: Hamlet D'Arcy [mailto:ham...@gm...] Sent: Tuesday, November 09, 2010 2:57 PM To: Cod...@li... Subject: [Codenarc-developer] 0.11 release planning thread Chris, You're the owner, so it is of course up to you to run the 0.11 release the way you want. As a list of todos, we need to: 0. Create the Changelog 1. Build and upload new version 2. Update Griffon plugin (i have commit rights and can do this) 3. UPdate Grails plugin (do you have commit rights?) 4. Update Gradle plugin (do you have commit rights?) 5. Publish a blogpost/page with more info about all the new rules (i can do this) 6. Send email announcements to groovy, griffon, grails, & hackergarten lists Which do you need the most help with? What is missing? -- Hamlet D'Arcy ham...@gm... ---------------------------------------------------------------------------- -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer |
|
From: Chris M. <chr...@ea...> - 2010-11-10 03:25:34
|
Hamlet, In addition to the items in your list, I typically: A) Create a snapshot release and run that against several large Groovy projects at work, and examine the violations. In almost every release that has ended up revealing an issue or two -- often a false negative or false positive in a new rule. B) Run the new code version against the open source projects (Grails, Griffon, Gradle) and pull in the resulting reports. C) Deploy to the Maven Central Repo after the release D) Tag the project version in SVN I will plan to do all of the above. I will also do #3 (Grails plugin) from your list - usually a a few days after the release. You are more than welcome to do #2, #4 (I do not have Gradle commit rights) and #5. For #6 (email announcements), I was intending on collaborating with you. For #0 (Change log), if you want to do a draft version in the "CHANGELOG.txt" version that would be great, but not required. I will have a few additions of my own. To be honest, I am struggling to keep up with all of the recent additions/changes (though I am absolutely NOT complaining!!!). I don't have a lot of time to work on this each day. It will take me at least a few days to catch up and get my own changes done before the release. Are you pretty much done with your changes? Thanks a lot. Chris -----Original Message----- From: Hamlet D'Arcy [mailto:ham...@gm...] Sent: Tuesday, November 09, 2010 2:57 PM To: Cod...@li... Subject: [Codenarc-developer] 0.11 release planning thread Chris, You're the owner, so it is of course up to you to run the 0.11 release the way you want. As a list of todos, we need to: 0. Create the Changelog 1. Build and upload new version 2. Update Griffon plugin (i have commit rights and can do this) 3. UPdate Grails plugin (do you have commit rights?) 4. Update Gradle plugin (do you have commit rights?) 5. Publish a blogpost/page with more info about all the new rules (i can do this) 6. Send email announcements to groovy, griffon, grails, & hackergarten lists Which do you need the most help with? What is missing? -- Hamlet D'Arcy ham...@gm... ---------------------------------------------------------------------------- -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer |
|
From: Chris M. <chr...@ea...> - 2010-11-10 02:27:37
|
I refined the formatting of all of those "New in 0.11" messages, so that they looked ok when the web pages are rendered. I also changed them all to "Since CodeNarc 0.11" so that we don't have to update them when we put out 0.12, etc.. I also reorderd the new rule documentation to be in alphabetical order. Otherwise it is difficult to find rule documentation for a specific rule, especially within a big ruleset like "basic". Please do that when you add new rules. I am still considering adding an index or table of contents for some of the bigger rulesets, or perhaps an index for all of the rules (if I can generate it from a script). Thanks. Chris -----Original Message----- From: Hamlet D'Arcy [mailto:ham...@gm...] Sent: Tuesday, November 09, 2010 2:47 PM To: chr...@wa...; Cod...@li... Subject: Re: [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki The .apt files are now updated with "new in 0.11" -- Hamlet D'Arcy ham...@gm... On Tue, Nov 9, 2010 at 2:31 PM, <chr...@wa...> wrote: That sounds fine. I thought maybe you were suggesting updating and releasing the docs today, to get a one-week head start. But it sounds like we are on the same page. Hamlet DArcy <ham...@ca...> 11/09/2010 08:21 AM To chris mair <chr...@wa...> cc cod...@li... Subject Re: [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki Of course we will update the docs before the release. But I was thinking that next month maybe someone contributes a better description and then what do we do... we can just run mvn site and upload with no problems. -- Hamlet D'Arcy ham...@ca... _____ If we are going to do the 0.11 release within the next week or so, can we just release it all together? Hamlet DArcy <ham...@ca...> 11/09/2010 07:53 AM To chris mair <chr...@wa...> cc cod...@li... Subject Re: [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki And if we document the .apt files with "since 0.11" then releasing new docs with changes from the head will not break anything. Let's do it. -- Hamlet D'Arcy ham...@ca... _____ >> What do you think about documenting the new rules with "since 0.11" in the .apt file. That sounds like a great idea. >> Can the site documentation be updated outside of a build cycle? Yes, if needed, we could run the mvn site goal to rebuild the site, and then transfer the files up to the SourceForge directory, without doing a formal release. Chris Hamlet DArcy <ham...@ca...> 11/09/2010 07:41 AM To cod...@li... cc Subject [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki What do you think about documenting the new rules with "since 0.11" in the .apt file. That way they could be easily found. Can the site documentation be updated outside of a build cycle? -- Hamlet D'Arcy ham...@ca... ---------------------------------------------------------------------------- -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev_____________________________________________ __ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ForwardSourceID:NT000CE136 ForwardSourceID:NT000CE14E ForwardSourceID:NT000CE182 ---------------------------------------------------------------------------- -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer |
|
From: Hamlet D'A. <ham...@gm...> - 2010-11-09 19:56:46
|
Chris, You're the owner, so it is of course up to you to run the 0.11 release the way you want. As a list of todos, we need to: 0. Create the Changelog 1. Build and upload new version 2. Update Griffon plugin (i have commit rights and can do this) 3. UPdate Grails plugin (do you have commit rights?) 4. Update Gradle plugin (do you have commit rights?) 5. Publish a blogpost/page with more info about all the new rules (i can do this) 6. Send email announcements to groovy, griffon, grails, & hackergarten lists Which do you need the most help with? What is missing? -- Hamlet D'Arcy ham...@gm... |
|
From: Hamlet D'A. <ham...@gm...> - 2010-11-09 19:47:24
|
The .apt files are now updated with "new in 0.11" -- Hamlet D'Arcy ham...@gm... On Tue, Nov 9, 2010 at 2:31 PM, <chr...@wa...> wrote: > > That sounds fine. I thought maybe you were suggesting updating and > releasing the docs today, to get a one-week head start. But it sounds like > we are on the same page. > > > > *Hamlet DArcy <ham...@ca...>* > > 11/09/2010 08:21 AM > To > chris mair <chr...@wa...> > cc > cod...@li... > Subject > Re: [Codenarc-developer] documenting .apt rule descriptions with "since > .011" or on wiki > > > > > Of course we will update the docs before the release. > But I was thinking that next month maybe someone contributes a better > description and then what do we do... we can just run mvn site and upload > with no problems. > > -- > Hamlet D'Arcy > ham...@ca... > > ------------------------------ > > > If we are going to do the 0.11 release within the next week or so, can we > just release it all together? > > > *Hamlet DArcy <ham...@ca...>* > 11/09/2010 07:53 AM > To > chris mair <chr...@wa...> > cc > cod...@li... > Subject > Re: [Codenarc-developer] documenting .apt rule descriptions with "since > .011" or on wiki > > > > > > > And if we document the .apt files with "since 0.11" then releasing new docs > with changes from the head will not break anything. > > Let's do it. > > -- > Hamlet D'Arcy > ham...@ca... > > ------------------------------ > > > >> What do you think about documenting the new rules with "since 0.11" in > the .apt file. > > That sounds like a great idea. > > >> Can the site documentation be updated outside of a build cycle? > > Yes, if needed, we could run the *mvn site *goal to rebuild the site, and > then transfer the files up to the SourceForge directory, without doing a > formal release. > > Chris > *Hamlet DArcy <ham...@ca...>* > 11/09/2010 07:41 AM > To > cod...@li... > cc > Subject > [Codenarc-developer] documenting .apt rule descriptions with "since > .011" or on wiki > > > > > > > > > What do you think about documenting the new rules with "since 0.11" in the > .apt file. That way they could be easily found. > > Can the site documentation be updated outside of a build cycle? > > -- > Hamlet D'Arcy > ham...@ca... > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > > http://p.sf.net/sfu/SAP-dev2dev_______________________________________________ > Codenarc-developer mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codenarc-developer > > ForwardSourceID:NT000CE136 > > ForwardSourceID:NT000CE14E > > ForwardSourceID:NT000CE182 > > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > Codenarc-developer mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codenarc-developer > > |
|
From: <chr...@wa...> - 2010-11-09 13:31:57
|
That sounds fine. I thought maybe you were suggesting updating and releasing the docs today, to get a one-week head start. But it sounds like we are on the same page. Hamlet DArcy <ham...@ca...> 11/09/2010 08:21 AM To chris mair <chr...@wa...> cc cod...@li... Subject Re: [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki Of course we will update the docs before the release. But I was thinking that next month maybe someone contributes a better description and then what do we do... we can just run mvn site and upload with no problems. -- Hamlet D'Arcy ham...@ca... If we are going to do the 0.11 release within the next week or so, can we just release it all together? Hamlet DArcy <ham...@ca...> 11/09/2010 07:53 AM To chris mair <chr...@wa...> cc cod...@li... Subject Re: [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki And if we document the .apt files with "since 0.11" then releasing new docs with changes from the head will not break anything. Let's do it. -- Hamlet D'Arcy ham...@ca... >> What do you think about documenting the new rules with "since 0.11" in the .apt file. That sounds like a great idea. >> Can the site documentation be updated outside of a build cycle? Yes, if needed, we could run the mvn site goal to rebuild the site, and then transfer the files up to the SourceForge directory, without doing a formal release. Chris Hamlet DArcy <ham...@ca...> 11/09/2010 07:41 AM To cod...@li... cc Subject [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki What do you think about documenting the new rules with "since 0.11" in the .apt file. That way they could be easily found. Can the site documentation be updated outside of a build cycle? -- Hamlet D'Arcy ham...@ca... ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev_______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ForwardSourceID:NT000CE136 ForwardSourceID:NT000CE14E ForwardSourceID:NT000CE182 |
|
From: Hamlet D. <ham...@ca...> - 2010-11-09 13:21:29
|
Of course we will update the docs before the release. But I was thinking that next month maybe someone contributes a better description and then what do we do... we can just run mvn site and upload with no problems. -- Hamlet D'Arcy ham...@ca... If we are going to do the 0.11 release within the next week or so, can we just release it all together? Hamlet DArcy <ham...@ca...> 11/09/2010 07:53 AM To chris mair <chr...@wa...> cc cod...@li... Subject Re: [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki And if we document the .apt files with "since 0.11" then releasing new docs with changes from the head will not break anything. Let's do it. -- Hamlet D'Arcy ham...@ca... >> What do you think about documenting the new rules with "since 0.11" in the .apt file. That sounds like a great idea. >> Can the site documentation be updated outside of a build cycle? Yes, if needed, we could run the mvn site goal to rebuild the site, and then transfer the files up to the SourceForge directory, without doing a formal release. Chris Hamlet DArcy <ham...@ca...> 11/09/2010 07:41 AM To cod...@li... cc Subject [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki What do you think about documenting the new rules with "since 0.11" in the .apt file. That way they could be easily found. Can the site documentation be updated outside of a build cycle? -- Hamlet D'Arcy ham...@ca... ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev_______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ForwardSourceID:NT000CE136 ForwardSourceID:NT000CE14E |
|
From: <chr...@wa...> - 2010-11-09 12:56:02
|
If we are going to do the 0.11 release within the next week or so, can we just release it all together? Hamlet DArcy <ham...@ca...> 11/09/2010 07:53 AM To chris mair <chr...@wa...> cc cod...@li... Subject Re: [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki And if we document the .apt files with "since 0.11" then releasing new docs with changes from the head will not break anything. Let's do it. -- Hamlet D'Arcy ham...@ca... >> What do you think about documenting the new rules with "since 0.11" in the .apt file. That sounds like a great idea. >> Can the site documentation be updated outside of a build cycle? Yes, if needed, we could run the mvn site goal to rebuild the site, and then transfer the files up to the SourceForge directory, without doing a formal release. Chris Hamlet DArcy <ham...@ca...> 11/09/2010 07:41 AM To cod...@li... cc Subject [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki What do you think about documenting the new rules with "since 0.11" in the .apt file. That way they could be easily found. Can the site documentation be updated outside of a build cycle? -- Hamlet D'Arcy ham...@ca... ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev_______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ForwardSourceID:NT000CE136 ForwardSourceID:NT000CE14E |
|
From: Hamlet D. <ham...@ca...> - 2010-11-09 12:53:14
|
And if we document the .apt files with "since 0.11" then releasing new docs with changes from the head will not break anything. Let's do it. -- Hamlet D'Arcy ham...@ca... >> What do you think about documenting the new rules with "since 0.11" in the .apt file. That sounds like a great idea. >> Can the site documentation be updated outside of a build cycle? Yes, if needed, we could run the mvn site goal to rebuild the site, and then transfer the files up to the SourceForge directory, without doing a formal release. Chris Hamlet DArcy <ham...@ca...> 11/09/2010 07:41 AM To cod...@li... cc Subject [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki What do you think about documenting the new rules with "since 0.11" in the .apt file. That way they could be easily found. Can the site documentation be updated outside of a build cycle? -- Hamlet D'Arcy ham...@ca... ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev_______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ForwardSourceID:NT000CE136 |
|
From: <chr...@wa...> - 2010-11-09 12:46:14
|
>> What do you think about documenting the new rules with "since 0.11" in the .apt file. That sounds like a great idea. >> Can the site documentation be updated outside of a build cycle? Yes, if needed, we could run the mvn site goal to rebuild the site, and then transfer the files up to the SourceForge directory, without doing a formal release. Chris Hamlet DArcy <ham...@ca...> 11/09/2010 07:41 AM To cod...@li... cc Subject [Codenarc-developer] documenting .apt rule descriptions with "since .011" or on wiki What do you think about documenting the new rules with "since 0.11" in the .apt file. That way they could be easily found. Can the site documentation be updated outside of a build cycle? -- Hamlet D'Arcy ham...@ca... ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ForwardSourceID:NT000CE136 |
|
From: Hamlet D. <ham...@ca...> - 2010-11-09 12:41:21
|
What do you think about documenting the new rules with "since 0.11" in the .apt file. That way they could be easily found. Can the site documentation be updated outside of a build cycle? -- Hamlet D'Arcy ham...@ca... |
