codenarc-developer Mailing List for CodeNarc (Page 7)
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: Chris M. <chr...@ea...> - 2011-06-04 18:23:27
|
I am considering creating a new "serialization" ruleset, and including these three rules: . SerialPersistentFields (0.14) . SerialVersionUID (0.11) . SerializableClassMustDefineSerialVersionUID (0.13) That implies moving the last two rules, which were released in previous versions of CodeNarc. The SerialPersistentFields rule is included in the upcoming 0.14 release. If I do that, I realize that might cause some (hopefully minor) breakage for users that already configured the two existing rules within the context of an included rulesets, but not if they are only configured within "codenarc.properties" or as individual rules. Anyone have opinions on that, one way or another? Chris |
|
From: Chris M. <chr...@ea...> - 2011-06-04 15:06:02
|
The documentation for UnnecessaryEqualityWithNull says The expression object.equals(null) is always false and is unnecessary. The object.equals(null) comparison will always return false, since the object is not null. (If the object is null, the program will throw a NullPointerException). This is the basic contract of the equals() method. But this prints true in the GroovyConsole, rather than throwing a NPE: def x = null println x.equals(null) Any thoughts on what to do with this rule? |
|
From: Chris M. <chr...@ea...> - 2011-06-04 14:45:44
|
>> That is the intent of the rule.
>>
>> It is so that someone doesn't see the value of a property in the middle
of a state change.
But in this case, it looks like the synchronized method is there to ensure
safe lazy-initialization of a read-only cached value. And it is a private
method. That lazy-initialization method just happens to be called
getProperties(). Is that still an "inconsistent property synchronization"?
e.g.,
class DbConfigurationProperties {
private static final LOG =
Logger.getLogger(DbConfigurationProperties)
private static final DBCONFIGURATION_KEY =
"DbConfigurationProperties"
String dbConfigurationFile
Cache cache
boolean isEnabled(Client client, Channel channel) {
assert cache
assert client
assert channel
def properties = getProperties()
def propertyValue =
properties.getProperty(propertyKey(client, channel.getId()))
propertyValue = propertyValue ?:
properties.getProperty(propertyKey(client, "*"))
return isTrue(propertyValue)
}
private synchronized Properties getProperties() {
Properties dbConfigurationProperties =
cache.get(DBCONFIGURATION_KEY)
if (dbConfigurationProperties == null) {
dbConfigurationProperties = loadDbConfiguration()
cache.put(DBCONFIGURATION_KEY,
dbConfigurationProperties)
}
return dbConfigurationProperties
}
private String propertyKey(Client client, String channelId) {
return "datasource.${client.id}.${channelId}"
}
private boolean isTrue(String value) {
return value == null || value.toLowerCase() == "true"
}
private Properties loadDbConfiguration() {
assert dbConfigurationFile
def props = new Properties();
try {
new File(dbConfigurationFile).withInputStream {
inputStream -> props.load(inputStream)
}
}
catch (FileNotFoundException e){
LOG.error("Error loading $dbConfigurationFile: $e")
}
LOG.info "Loaded DBConfiguration properties=$props"
return props
}
}
--------------------------------------------------------------
> Hamlet,
>
> Is the intent that InconsistentPropertySynchronization cause a
> violation if the class defines a synchronized getXXX() method but no
> matching setXXX() method or like-named property exists? I ran into a
> violation for that for a class at work.
>
> Chris
|
|
From: Hamlet D'A. <ham...@gm...> - 2011-06-04 06:42:47
|
That is the intent of the rule. It is so that someone doesn't see the value of a property in the middle of a state change. On Sat, Jun 4, 2011 at 12:36 AM, Chris Mair <chr...@ea...> wrote: > Hamlet, > > > > Is the intent that InconsistentPropertySynchronization cause a violation if > the class defines a synchronized getXXX() method but no matching setXXX() > method or like-named property exists? I ran into a violation for that for a > class at work. > > > > Chris -- Hamlet D'Arcy ham...@gm... |
|
From: Chris M. <chr...@ea...> - 2011-06-03 22:36:15
|
Hamlet, Is the intent that InconsistentPropertySynchronization cause a violation if the class defines a synchronized getXXX() method but no matching setXXX() method or like-named property exists? I ran into a violation for that for a class at work. Chris |
|
From: Chris M. <chr...@ea...> - 2011-06-03 21:11:45
|
I pulled in the test changes from the patch (and checked it in) and the code
still passes all tests.
Chris
-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...]
Sent: Friday, June 03, 2011 2:13 AM
To: Chris Mair
Cc: cod...@li...
Subject: Re: ClosureAsLastMethodParameterRule - bug with double slashes;
simplified?
Shoot, I also have this patch to apply from Marcin the original author.
I won't have time soon, but we should rip the tests out of the patch and see
if they still pass with your changes.
On Fri, Jun 3, 2011 at 4:12 AM, Chris Mair <chr...@ea...> wrote:
> Hamlet,
>
>
>
> When running the CodeNarc 0.14 snapshot against a project at work, I
> ran across a bug in ClosureAsLastMethodParameterRule, where it would
> give a false-positive violation if the closure parameter contained a
> string containing //.
>
>
>
> Here is the test case I added, that initially failed with three
violations:
>
>
>
> void testLinesWithStringsContainingDoubleSlash() {
>
> final SOURCE = '''
>
> void testProcess() {
>
> shouldFail {
> process('xxx://wrsnetdev.usa.wachovia.net') }
>
> shouldFail(Exception) { process('http://')
>
> }
>
> shouldFail {
>
> process('http://wrsnetdev.usa.wachovia.net:xxx') }
>
> }
>
> '''
>
> assertNoViolations(SOURCE)
>
> }
>
>
>
> I stripped out the logic in that rule that checked for comments in the
> source, and just base the check on the lastColumnNumber of the closure
> parm versus the whole method. It may be too simplistic, but it passes
> all of the tests, including my new test. If you get a chance, could
> you please take a look. If I am missing some requirement, then we
> obviously need more/better tests.
>
>
>
> Chris
--
Hamlet D'Arcy
ham...@gm...
|
|
From: Hamlet D'A. <ham...@gm...> - 2011-06-03 06:12:52
|
Shoot, I also have this patch to apply from Marcin the original author.
I won't have time soon, but we should rip the tests out of the patch
and see if they still pass with your changes.
On Fri, Jun 3, 2011 at 4:12 AM, Chris Mair <chr...@ea...> wrote:
> Hamlet,
>
>
>
> When running the CodeNarc 0.14 snapshot against a project at work, I ran
> across a bug in ClosureAsLastMethodParameterRule, where it would give a
> false-positive violation if the closure parameter contained a string
> containing “//”.
>
>
>
> Here is the test case I added, that initially failed with three violations:
>
>
>
> void testLinesWithStringsContainingDoubleSlash() {
>
> final SOURCE = '''
>
> void testProcess() {
>
> shouldFail { process('xxx://wrsnetdev.usa.wachovia.net') }
>
> shouldFail(Exception) { process('http://')
>
> }
>
> shouldFail {
>
> process('http://wrsnetdev.usa.wachovia.net:xxx') }
>
> }
>
> '''
>
> assertNoViolations(SOURCE)
>
> }
>
>
>
> I stripped out the logic in that rule that checked for comments in the
> source, and just base the check on the lastColumnNumber of the closure parm
> versus the whole method. It may be too simplistic, but it passes all of the
> tests, including my new test. If you get a chance, could you please take a
> look. If I am missing some “requirement”, then we obviously need more/better
> tests.
>
>
>
> Chris
--
Hamlet D'Arcy
ham...@gm...
|
|
From: Chris M. <chr...@ea...> - 2011-06-03 02:12:19
|
Hamlet,
When running the CodeNarc 0.14 snapshot against a project at work, I ran
across a bug in ClosureAsLastMethodParameterRule, where it would give a
false-positive violation if the closure parameter contained a string
containing "//".
Here is the test case I added, that initially failed with three violations:
void testLinesWithStringsContainingDoubleSlash() {
final SOURCE = '''
void testProcess() {
shouldFail { process('xxx://wrsnetdev.usa.wachovia.net') }
shouldFail(Exception) { process('http://')
}
shouldFail {
process('http://wrsnetdev.usa.wachovia.net:xxx') }
}
'''
assertNoViolations(SOURCE)
}
I stripped out the logic in that rule that checked for comments in the
source, and just base the check on the lastColumnNumber of the closure parm
versus the whole method. It may be too simplistic, but it passes all of the
tests, including my new test. If you get a chance, could you please take a
look. If I am missing some "requirement", then we obviously need more/better
tests.
Chris
|
|
From: Hamlet D'A. <ham...@gm...> - 2011-06-01 12:45:18
|
That sounds good to me. I'll assume it's on your todo list and not on mine... just let me know if you need me to do it instead. -- Hamlet D'Arcy ham...@gm... On Wed, Jun 1, 2011 at 1:50 PM, <chr...@we...> wrote: > Yes, that sounds like a good idea. I guess it would instantiate the rule and check all of the non-null applyTo* and doNotApplyTo* values. I think I'll be able to come up with a validation for the wildcard expressions. > > -----Original Message----- > From: Hamlet D'Arcy [mailto:ham...@gm...] > Sent: Wednesday, June 01, 2011 12:24 AM > To: Cod...@li... > Subject: Re: [Codenarc-developer] tons of exceptions in build > > Can we write a unit test in the abstract test case to make sure these > are valid for all rules? > > I can validate a regex... can you validate a wildcard expression? > > > > On Wed, Jun 1, 2011 at 4:21 AM, Chris Mair <chr...@ea...> wrote: >> Hamlet, >> >> I do see those exceptions in the test output as well, when I run mvn test, >> though all the tests pass. >> >> It is because the JavaIoPackageAccessRule has doNotApplyToFilesMatching = >> DEFAULT_TEST_CLASS_NAMES (wildcard string) instead of DEFAULT_TEST_FILES >> (regex). I checked in the fix for that, and don't see those errors anymore. >> >> Chris >> -----Original Message----- >> From: Hamlet DArcy [mailto:ham...@ca...] >> Sent: Tuesday, May 31, 2011 5:32 AM >> To: cod...@li... >> Subject: [Codenarc-developer] tons of exceptions in build >> >> Hi Chris, >> >> When running the maven build, I get a ton of exceptions. I never know if it >> works correctly or is a new error. >> >> I see this exception quite often when I run "mvn test": >> >> java.util.regex.PatternSyntaxException: Dangling meta character '*' near >> index 0 *Test,*Tests,*TestCase ^ >> at java.util.regex.Pattern.error(Pattern.java:1713) >> at java.util.regex.Pattern.sequence(Pattern.java:1878) >> at java.util.regex.Pattern.expr(Pattern.java:1752) >> >> >> Is it normal that these exceptions are thrown? >> >> -- >> Hamlet D'Arcy >> ham...@ca... >> >> >> ---------------------------------------------------------------------------- >> -- >> Simplify data backup and recovery for your virtual environment with vRanger. >> >> Installation's a snap, and flexible recovery options mean your data is safe, >> secure and there when you need it. Data protection magic? >> Nope - It's vRanger. Get your free trial download today. >> http://p.sf.net/sfu/quest-sfdev2dev >> _______________________________________________ >> Codenarc-developer mailing list >> Cod...@li... >> https://lists.sourceforge.net/lists/listinfo/codenarc-developer >> >> >> ------------------------------------------------------------------------------ >> Simplify data backup and recovery for your virtual environment with vRanger. >> Installation's a snap, and flexible recovery options mean your data is safe, >> secure and there when you need it. Data protection magic? >> Nope - It's vRanger. Get your free trial download today. >> http://p.sf.net/sfu/quest-sfdev2dev >> _______________________________________________ >> Codenarc-developer mailing list >> Cod...@li... >> https://lists.sourceforge.net/lists/listinfo/codenarc-developer >> > > > > -- > Hamlet D'Arcy > ham...@gm... > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > Codenarc-developer mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codenarc-developer > |
|
From: <chr...@we...> - 2011-06-01 12:03:35
|
And I guess one other thing to consider is whether that affects our possible migration to Gradle. -----Original Message----- From: chr...@we... [mailto:chr...@we...] Sent: Wednesday, June 01, 2011 8:01 AM To: ham...@ca...; cod...@li... Subject: Re: [Codenarc-developer] using Groovy-Eclipse compiler in Maven I noticed this announcement as well, and was considering it. The downside is that with no stub generation, we give up the possibility of generating javadoc/groovydoc for the web site (I assume). Though the javadoc is broken now anyway because of a GMaven incompatibility or perhaps because of my lack of GMaven/Maven expertise. But perhaps we could do that after the 0.14 release. I created a Feature Request to track it, in case we want to do it: https://sourceforge.net/tracker/?func=detail&aid=3310143&group_id=250145&atid=1126575 -----Original Message----- From: Hamlet DArcy [mailto:ham...@ca...] Sent: Wednesday, June 01, 2011 3:18 AM To: cod...@li... Subject: [Codenarc-developer] using Groovy-Eclipse compiler in Maven You can now use the Groovy-Eclipse compiler from Maven. http://docs.codehaus.org/display/GROOVY/Groovy-Eclipse+compiler+plugin+for+Maven Perhaps CodeNarc should switch over to this. It's faster and there is no stub generation. -- Hamlet D'Arcy ham...@ca... ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer |
|
From: <chr...@we...> - 2011-06-01 12:01:36
|
I noticed this announcement as well, and was considering it. The downside is that with no stub generation, we give up the possibility of generating javadoc/groovydoc for the web site (I assume). Though the javadoc is broken now anyway because of a GMaven incompatibility or perhaps because of my lack of GMaven/Maven expertise. But perhaps we could do that after the 0.14 release. I created a Feature Request to track it, in case we want to do it: https://sourceforge.net/tracker/?func=detail&aid=3310143&group_id=250145&atid=1126575 -----Original Message----- From: Hamlet DArcy [mailto:ham...@ca...] Sent: Wednesday, June 01, 2011 3:18 AM To: cod...@li... Subject: [Codenarc-developer] using Groovy-Eclipse compiler in Maven You can now use the Groovy-Eclipse compiler from Maven. http://docs.codehaus.org/display/GROOVY/Groovy-Eclipse+compiler+plugin+for+Maven Perhaps CodeNarc should switch over to this. It's faster and there is no stub generation. -- Hamlet D'Arcy ham...@ca... ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer |
|
From: <chr...@we...> - 2011-06-01 11:50:44
|
Yes, that sounds like a good idea. I guess it would instantiate the rule and check all of the non-null applyTo* and doNotApplyTo* values. I think I'll be able to come up with a validation for the wildcard expressions. -----Original Message----- From: Hamlet D'Arcy [mailto:ham...@gm...] Sent: Wednesday, June 01, 2011 12:24 AM To: Cod...@li... Subject: Re: [Codenarc-developer] tons of exceptions in build Can we write a unit test in the abstract test case to make sure these are valid for all rules? I can validate a regex... can you validate a wildcard expression? On Wed, Jun 1, 2011 at 4:21 AM, Chris Mair <chr...@ea...> wrote: > Hamlet, > > I do see those exceptions in the test output as well, when I run mvn test, > though all the tests pass. > > It is because the JavaIoPackageAccessRule has doNotApplyToFilesMatching = > DEFAULT_TEST_CLASS_NAMES (wildcard string) instead of DEFAULT_TEST_FILES > (regex). I checked in the fix for that, and don't see those errors anymore. > > Chris > -----Original Message----- > From: Hamlet DArcy [mailto:ham...@ca...] > Sent: Tuesday, May 31, 2011 5:32 AM > To: cod...@li... > Subject: [Codenarc-developer] tons of exceptions in build > > Hi Chris, > > When running the maven build, I get a ton of exceptions. I never know if it > works correctly or is a new error. > > I see this exception quite often when I run "mvn test": > > java.util.regex.PatternSyntaxException: Dangling meta character '*' near > index 0 *Test,*Tests,*TestCase ^ > at java.util.regex.Pattern.error(Pattern.java:1713) > at java.util.regex.Pattern.sequence(Pattern.java:1878) > at java.util.regex.Pattern.expr(Pattern.java:1752) > > > Is it normal that these exceptions are thrown? > > -- > Hamlet D'Arcy > ham...@ca... > > > ---------------------------------------------------------------------------- > -- > Simplify data backup and recovery for your virtual environment with vRanger. > > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > Codenarc-developer mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codenarc-developer > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > Codenarc-developer mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codenarc-developer > -- Hamlet D'Arcy ham...@gm... ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer |
|
From: Hamlet D. <ham...@ca...> - 2011-06-01 07:18:00
|
You can now use the Groovy-Eclipse compiler from Maven. http://docs.codehaus.org/display/GROOVY/Groovy-Eclipse+compiler+plugin+for+Maven Perhaps CodeNarc should switch over to this. It's faster and there is no stub generation. -- Hamlet D'Arcy ham...@ca... |
|
From: Hamlet D'A. <ham...@gm...> - 2011-06-01 04:23:45
|
Can we write a unit test in the abstract test case to make sure these are valid for all rules? I can validate a regex... can you validate a wildcard expression? On Wed, Jun 1, 2011 at 4:21 AM, Chris Mair <chr...@ea...> wrote: > Hamlet, > > I do see those exceptions in the test output as well, when I run mvn test, > though all the tests pass. > > It is because the JavaIoPackageAccessRule has doNotApplyToFilesMatching = > DEFAULT_TEST_CLASS_NAMES (wildcard string) instead of DEFAULT_TEST_FILES > (regex). I checked in the fix for that, and don't see those errors anymore. > > Chris > -----Original Message----- > From: Hamlet DArcy [mailto:ham...@ca...] > Sent: Tuesday, May 31, 2011 5:32 AM > To: cod...@li... > Subject: [Codenarc-developer] tons of exceptions in build > > Hi Chris, > > When running the maven build, I get a ton of exceptions. I never know if it > works correctly or is a new error. > > I see this exception quite often when I run "mvn test": > > java.util.regex.PatternSyntaxException: Dangling meta character '*' near > index 0 *Test,*Tests,*TestCase ^ > at java.util.regex.Pattern.error(Pattern.java:1713) > at java.util.regex.Pattern.sequence(Pattern.java:1878) > at java.util.regex.Pattern.expr(Pattern.java:1752) > > > Is it normal that these exceptions are thrown? > > -- > Hamlet D'Arcy > ham...@ca... > > > ---------------------------------------------------------------------------- > -- > Simplify data backup and recovery for your virtual environment with vRanger. > > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > Codenarc-developer mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codenarc-developer > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > Codenarc-developer mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codenarc-developer > -- Hamlet D'Arcy ham...@gm... |
|
From: Chris M. <chr...@ea...> - 2011-06-01 02:21:16
|
Hamlet, I do see those exceptions in the test output as well, when I run mvn test, though all the tests pass. It is because the JavaIoPackageAccessRule has doNotApplyToFilesMatching = DEFAULT_TEST_CLASS_NAMES (wildcard string) instead of DEFAULT_TEST_FILES (regex). I checked in the fix for that, and don't see those errors anymore. Chris -----Original Message----- From: Hamlet DArcy [mailto:ham...@ca...] Sent: Tuesday, May 31, 2011 5:32 AM To: cod...@li... Subject: [Codenarc-developer] tons of exceptions in build Hi Chris, When running the maven build, I get a ton of exceptions. I never know if it works correctly or is a new error. I see this exception quite often when I run "mvn test": java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0 *Test,*Tests,*TestCase ^ at java.util.regex.Pattern.error(Pattern.java:1713) at java.util.regex.Pattern.sequence(Pattern.java:1878) at java.util.regex.Pattern.expr(Pattern.java:1752) Is it normal that these exceptions are thrown? -- Hamlet D'Arcy ham...@ca... ---------------------------------------------------------------------------- -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer |
|
From: Hamlet D. <ham...@ca...> - 2011-05-31 09:32:11
|
Hi Chris, When running the maven build, I get a ton of exceptions. I never know if it works correctly or is a new error. I see this exception quite often when I run "mvn test": java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0 *Test,*Tests,*TestCase ^ at java.util.regex.Pattern.error(Pattern.java:1713) at java.util.regex.Pattern.sequence(Pattern.java:1878) at java.util.regex.Pattern.expr(Pattern.java:1752) Is it normal that these exceptions are thrown? -- Hamlet D'Arcy ham...@ca... |
|
From: Hamlet D'A. <ham...@gm...> - 2011-05-23 05:38:31
|
I checked in pom1_8.xml... It is just a sanity check that all the unit tests pass when compiled and run against 1.8. But we need to continue making deployments and builds using the normal pom.xml What we really need is a way to do this: * Build using Groovy 1.7 * Run all tests using the Groovy 1.7 runtime * Run all tests using the Groovy 1.8 runtime I believe this is a difficult thing to do with Maven, but my Maven Fu is horrible and I am more than a little obstinate when it comes to learning Maven. Rene has been working on a site plugin for Gradle and is using CodeNarc as the reference project. Perhaps he will be done this week or the next. We'll see. -- Hamlet D'Arcy ham...@gm... On Mon, May 23, 2011 at 3:57 AM, Chris Mair <chr...@ea...> wrote: > Thanks Hamlet. > > I see you already checked in a POM file for 1.8. Does that work? If we use > that, can we use the parent POM facility to avoid duplication? My Maven Fu > is not so strong, so I have not used that facility myself yet. > > I still have some cleanup and a little reorg to do before a release, as well > as testing against my projects at work. I fear the release will probably > slip into early June (I've got holidays coming up, and I still have to get > out the June GroovyMag article), but I'll do what I can. This is another > impressive release, IMHO. > > Chris > -----Original Message----- > From: Hamlet D'Arcy [mailto:ham...@gm...] > Sent: Sunday, May 22, 2011 2:39 AM > To: Cod...@li...; Cédric CHAMPEAU > Subject: [Codenarc-developer] CodeNarc and Groovy 1.8 > > Hi all, > > I checked in changes this morning that have Groovy 1.8 support. > CodeNarc should continue to be built with Groovy 1.7, but there are some > changes so that it can run with a 1.8 runtime. > > Chris, we need to figure out a way to do a "mvn test" using Groovy 1.8 from > the build, but continue to build only the binaries with 1.7. Some rules need > special logic to support both 1.8 and 1.7. You can check the version of > Groovy using the GroovyVersion class and then implement appropriately. Maybe > in the end we have 2 different pom.xml files for now, one with 1.8 and one > with 1.7. > > There is just one patch I have from Viktor that needs to be merged (it is 2 > new rules), and then I'd like to start testing for the next release. It > would be great to get the release done in May. > > -- > Hamlet D'Arcy > ham...@gm... > > |
|
From: Chris M. <chr...@ea...> - 2011-05-23 01:58:00
|
Thanks Hamlet. I see you already checked in a POM file for 1.8. Does that work? If we use that, can we use the parent POM facility to avoid duplication? My Maven Fu is not so strong, so I have not used that facility myself yet. I still have some cleanup and a little reorg to do before a release, as well as testing against my projects at work. I fear the release will probably slip into early June (I've got holidays coming up, and I still have to get out the June GroovyMag article), but I'll do what I can. This is another impressive release, IMHO. Chris -----Original Message----- From: Hamlet D'Arcy [mailto:ham...@gm...] Sent: Sunday, May 22, 2011 2:39 AM To: Cod...@li...; Cédric CHAMPEAU Subject: [Codenarc-developer] CodeNarc and Groovy 1.8 Hi all, I checked in changes this morning that have Groovy 1.8 support. CodeNarc should continue to be built with Groovy 1.7, but there are some changes so that it can run with a 1.8 runtime. Chris, we need to figure out a way to do a "mvn test" using Groovy 1.8 from the build, but continue to build only the binaries with 1.7. Some rules need special logic to support both 1.8 and 1.7. You can check the version of Groovy using the GroovyVersion class and then implement appropriately. Maybe in the end we have 2 different pom.xml files for now, one with 1.8 and one with 1.7. There is just one patch I have from Viktor that needs to be merged (it is 2 new rules), and then I'd like to start testing for the next release. It would be great to get the release done in May. -- Hamlet D'Arcy ham...@gm... |
|
From: Hamlet D'A. <ham...@gm...> - 2011-05-22 06:39:20
|
Hi all, I checked in changes this morning that have Groovy 1.8 support. CodeNarc should continue to be built with Groovy 1.7, but there are some changes so that it can run with a 1.8 runtime. Chris, we need to figure out a way to do a "mvn test" using Groovy 1.8 from the build, but continue to build only the binaries with 1.7. Some rules need special logic to support both 1.8 and 1.7. You can check the version of Groovy using the GroovyVersion class and then implement appropriately. Maybe in the end we have 2 different pom.xml files for now, one with 1.8 and one with 1.7. There is just one patch I have from Viktor that needs to be merged (it is 2 new rules), and then I'd like to start testing for the next release. It would be great to get the release done in May. -- Hamlet D'Arcy ham...@gm... |
|
From: Hamlet D. <ham...@ca...> - 2011-05-02 06:09:00
|
Rewriting the AbstractAstVisitor class in Java would probably be an easy way to see perf improvements as well. I don't think there is much in the class that is Groovy-dependent. ----- Original Message ----- > Hamlet, > > I have been having similar thoughts myself. One of things I have been > considering for the past year or so was adding in some (optional) > instrumentation to get metrics on rule and overall analysis > performance. But in any case, yes, I am concerned about the > performance in general. And right now I have no concrete way to > measure other than wall clock time. > > And, probably not a coincidence, it occurred to me as well that we > are walking the AST tree for each rule and there has to be a lot of > redundancy there. I was wondering about the feasibility and benefit > (if any) of approaching the analysis from the other direction from > how it currently works. Perhaps something like having each rule > "register" with the different aspects of the AST and just walking it > once, firing each rule component as necessary. But that was just > vague "I wonder if..." kind of speculation. And that would involve > a pretty significant redesign of the analysis engine and the rule > framework. I have no objection to your idea. If that approach works, > I guess we could expand that to other rule types as well. > > Chris > > > -----Original Message----- > >From: Hamlet D'Arcy <ham...@gm...> > >Sent: Apr 16, 2011 1:04 PM > >To: Cod...@li... > >Subject: [Codenarc-developer] performance improvements in rules > > > >Hi Chris, > > > >In my opinion, the rules need some performance improvements. Do you > >feel the same? > > > >One idea I have is to optimize rules that override > >visitMethodCallExpression. We walk the AST for every rule, but many > >rules only override visitMethodCall. Why not walk the tree only one > >time, and then call all the rules when a method call is found? I am > >thinking of an abstract class the defines only visitMethodCall as a > >abstract method. Then somehow the rule runner is smart enough to > >collect all the instance of the abstract classes and walk the tree > >only once, calling each child rule when a MethodCallExpression is > >found. It needs to support @SuppressWarnings as well. > > > >I think this would be an improvement. What do you think? > > > >What are you using to measure performance? > > > >Also, great activity recently :) I hope to find a little more time > >for > >rules over the next month or so. > > > >-- > >Hamlet D'Arcy > >ham...@gm... > >_______________________________________________ > >Codenarc-developer mailing list > >Cod...@li... > >https://lists.sourceforge.net/lists/listinfo/codenarc-developer > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and > improve > application availability and disaster protection. Learn more about > boosting > the value of server virtualization. > http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Codenarc-developer mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codenarc-developer > |
|
From: Christopher M. <chr...@ea...> - 2011-04-17 02:36:21
|
Hamlet, I have been having similar thoughts myself. One of things I have been considering for the past year or so was adding in some (optional) instrumentation to get metrics on rule and overall analysis performance. But in any case, yes, I am concerned about the performance in general. And right now I have no concrete way to measure other than wall clock time. And, probably not a coincidence, it occurred to me as well that we are walking the AST tree for each rule and there has to be a lot of redundancy there. I was wondering about the feasibility and benefit (if any) of approaching the analysis from the other direction from how it currently works. Perhaps something like having each rule "register" with the different aspects of the AST and just walking it once, firing each rule component as necessary. But that was just vague "I wonder if..." kind of speculation. And that would involve a pretty significant redesign of the analysis engine and the rule framework. I have no objection to your idea. If that approach works, I guess we could expand that to other rule types as well. Chris -----Original Message----- >From: Hamlet D'Arcy <ham...@gm...> >Sent: Apr 16, 2011 1:04 PM >To: Cod...@li... >Subject: [Codenarc-developer] performance improvements in rules > >Hi Chris, > >In my opinion, the rules need some performance improvements. Do you >feel the same? > >One idea I have is to optimize rules that override >visitMethodCallExpression. We walk the AST for every rule, but many >rules only override visitMethodCall. Why not walk the tree only one >time, and then call all the rules when a method call is found? I am >thinking of an abstract class the defines only visitMethodCall as a >abstract method. Then somehow the rule runner is smart enough to >collect all the instance of the abstract classes and walk the tree >only once, calling each child rule when a MethodCallExpression is >found. It needs to support @SuppressWarnings as well. > >I think this would be an improvement. What do you think? > >What are you using to measure performance? > >Also, great activity recently :) I hope to find a little more time for >rules over the next month or so. > >-- >Hamlet D'Arcy >ham...@gm... >_______________________________________________ >Codenarc-developer mailing list >Cod...@li... >https://lists.sourceforge.net/lists/listinfo/codenarc-developer |
|
From: Hamlet D'A. <ham...@gm...> - 2011-04-16 17:04:30
|
Hi Chris, In my opinion, the rules need some performance improvements. Do you feel the same? One idea I have is to optimize rules that override visitMethodCallExpression. We walk the AST for every rule, but many rules only override visitMethodCall. Why not walk the tree only one time, and then call all the rules when a method call is found? I am thinking of an abstract class the defines only visitMethodCall as a abstract method. Then somehow the rule runner is smart enough to collect all the instance of the abstract classes and walk the tree only once, calling each child rule when a MethodCallExpression is found. It needs to support @SuppressWarnings as well. I think this would be an improvement. What do you think? What are you using to measure performance? Also, great activity recently :) I hope to find a little more time for rules over the next month or so. -- Hamlet D'Arcy ham...@gm... |
|
From: Hamlet D'A. <ham...@gm...> - 2011-04-15 07:17:27
|
I still think that it's possible. I'd like to experiment and see what happens.
My original idea was for each rule to specify the compiler phase it
runs in. To test your idea, you can just change the rules to all run
in a late phase and see if the info you think should be there is.
Here is what I'd do (you'll need svn and mvn installed):
Get the source for CodeNarc:
$ svn co https://codenarc.svn.sourceforge.net/svnroot/codenarc codenarc
$ cd codenarc
$ mvn install
open the file: /src/main/groovy/org/codenarc/source/AbstractSourceCode.groovy
Line 75 says this:
compUnit.compile(Phases.CONVERSION)
Change it to
compUnit.compile(Phases.OUTPUT)
The project won't build cleanly any more after this change, but you
can write your transformation and unit test as part of the project and
run it individually.
If you see the AST you need, then we will work to add this feature in.
Regarding the point of your rule.... you basically want a rule that
adds a violation whenever a dynamic variable is found... right?
On Thu, Apr 14, 2011 at 5:41 PM, Klaus Baumecker
<kla...@go...> wrote:
> Now I found a real gap in my story: Groovy classes derived from Java
> classes. The java classes are not inspected and therefore not in the AST. I
> can't check against members of the super class.
>
> -- Gesendet von meinem Palm Pre
> ________________________________
> Am 14.04.2011 10:46 schrieb Hamlet D'Arcy <ham...@gm...>:
>
>> Btw. a topic for a side-discussion at GR-8 in Copenhagen?!
>
> A topic for Hackergarten as well. One of the nights we're planning a
> hacking-fest for groovy projects.
>
> I don't think this problem is specific to CodeNarc, but specific to
> Groovy ast transforms in general.
>
> If you run CodeNarc in a later compiler phase then I bet you'll see
> the information you need, no hackery needed.
>
> Do you want some tips on how to run this in a later phase? I had a
> patch to do this at one point, but Chris and I decided that it wasn't
> worth the effort because there were so many simple rules left to write
> that didn't require much type information.
>
>
>
> On Thu, Apr 14, 2011 at 9:45 AM, Klaus Baumecker
> <kla...@go...> wrote:
>> Hi Hamlet,
>>
>> the class hierarchy problem is because the AST generation takes a
>> class at a time and fills the superClass property just for the next
>> level up. If the superClass itself has not yet been inspected, it gets
>> Object as superClass.
>>
>> The way I (kind of) solved this problem was by using a 2-phase
>> approach. I modified the Codenarc script to run it two times and at
>> the same time build my own class-superClass map. Not perfect, I know.
>> But I got a complete hierarchy.
>>
>> Now to the actual problem I want to solve: I'm writing a rule, that
>> finds non-declared properties (or you might say dynamic properties).
>> That is all variable accesses that are not declared in the
>> class/superClass, the closure or whatever context the access is. I'm
>> pretty close to a working solution but I it will remain an
>> approximation to a strict parser with holes in it. The background is
>> to give the developers in my organisation a tool to check for typos
>> and 'forgotten' variables due to incomplete refactoring.
>> I continued, where GroovyLint stopped. I tried enhancing GroovyLint on
>> this topic, but at some point I got non-debuggable
>> ClassNotFound-exceptions and went over to CodeNarc. At this point I
>> also discovered the differences in completeness of the AST tree
>> between GroovyLint and CodeNarc (mainly because of the different
>> compile stage).
>> I also though about using Groovy++ for that task, but at this point
>> G++ has a different semantic than original Groovy wrt. scope in
>> closures and maybe elsewhere too.
>>
>> Anyway, that is my goal for giving Java programmers a smooth
>> transition to Groovy. You might argue, that CodeNarc is not the right
>> tool. IntelliJ would be an alternative, since it identifies these
>> variables as well, but I miss the reporting capability over a code
>> base.
>>
>> Btw. a topic for a side-discussion at GR-8 in Copenhagen?!
>>
>> Best regards,
>> klaus.
>>
>> On Wed, Apr 13, 2011 at 9:15 PM, Hamlet DArcy <ham...@ca...>
>> wrote:
>>> CodeNarc runs in a fairly early compiler phase. We do this so that you
>>> don't need to have the project's compiled class files on the classpath...
>>> you can still run CodeNarc even if your build/code is broken! On the
>>> negative side, that means a lot of type information is missing. Be careful
>>> when referencing types because any non-JDK types may not exist at the time
>>> you run CodeNarc.
>>>
>>> Do you have a simple example of the source the shows Object as the parent
>>> class with the missing inheritence problem? SOmething like
>>> {code}
>>> class A {}
>>> class B extends A {}
>>> class C extends B {}
>>> {code}
>>> Or something simple like that?
>>>
>>> ALso, I'd love to hear the specifics of the rule. Perhaps I can quickly
>>> write it for you, that way we can include it in the base product rather than
>>> leave it to something for you to maintain. (just a thought)
>>>
>>>
>>> ----- Original Message -----
>>>> I'm trying to build a rather complex rule based on information also
>>>> kept in the super class of a classnode. I made several observations:
>>>> 1. The class hierarchy seems broken with some classes. That is,
>>>> walking up along the superClass members I see java.lang.Object too
>>>> soon
>>>> 2. Not all fields of a class are visible in the classNode.
>>>>
>>>> I've built a rule based on the AbstractAstVisitor and overloaded
>>>> multiple visit* methods, such as visitClassEx and
>>>> visitConstructorOrMethodEx.
>>>>
>>>> For the incomplete fields information I suspect the threaded
>>>> execution
>>>> of the rules against the fileset. But why some superClass info is
>>>> missing I cannot explain.
>>>>
>>>> Any idea, what goes wrong here?
>>>>
>>>> Regards,
>>>> klaus.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Forrester Wave Report - Recovery time is now measured in hours and
>>>> minutes
>>>> not days. Key insights are discussed in the 2010 Forrester Wave
>>>> Report as
>>>> part of an in-depth evaluation of disaster recovery service
>>>> providers.
>>>> Forrester found the best-in-class provider in terms of services and
>>>> vision.
>>>> Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
>>>> _______________________________________________
>>>> Codenarc-user mailing list
>>>> Cod...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Benefiting from Server Virtualization: Beyond Initial Workload
>> Consolidation -- Increasing the use of server virtualization is a top
>> priority.Virtualization can reduce costs, simplify management, and improve
>> application availability and disaster protection. Learn more about
>> boosting
>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
>> _______________________________________________
>> Codenarc-user mailing list
>> Cod...@li...
>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>
>
>
>
> --
> Hamlet D'Arcy
> ham...@gm...
>
--
Hamlet D'Arcy
ham...@gm...
|
|
From: Chris M. <chr...@ea...> - 2011-04-14 00:52:19
|
Hamlet (or anyone), Do you think there is value in the @version tag in the class javadocs - that pulls in the SVN file revision # and date? Right now I have to remember to set svn:keywords on (all) new files through IDEA, which is a pain. Any problem with me not doing that anymore and us removing that line from the existing javadoc when we come across them? e.g. /** * ... * @author Chris Mair * @version $Revision: 635 $ - $Date: 2011-03-05 14:33:52 -0500 (Sat, 05 Mar 2011) $ // THIS LINE */ Thanks. Chris |
|
From: <chr...@we...> - 2011-04-11 11:57:05
|
>> It was a rule ported from the Klocwork project. They call all their >> rules "security" rules. If you use a non-pooled DirectConnection then >> I suppose you are more at-risk for denial of service. Maybe? >> >> We can move it anywhere we want though. I would be inclined to create a new "jdbc" ruleset. What do you think? Chris |
