RE: turbine-torque-user list
[EMAIL PROTECTED] -Original Message- From: Brian McCallister [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 7:35 AM To: Jakarta General List Subject: turbine-torque-user list I apologize for sending to this list, but both [EMAIL PROTECTED] and [EMAIL PROTECTED] (the one still listed on the Jakarta site) are bouncing right now. What is the list name (and subscribe request) addy for torque users now? Thanks, Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Another unused import statement report is out...
unused imports are down 40% since last November, crikey! http://cvs.apache.org/~tcopeland/jakarta_bad_imports.htm Past reports can be found here - http://cvs.apache.org/~tcopeland/, and mad props to the xml-xalan project, who went from 1421 unused imports to 2 in the last month. Yours, Tom Copeland InfoEther 703-486-4543 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
Anyway of turning off the: Avoid unused local variables such as 'obj' for classes which extend TestCase? It's not something to avoid in a TestCase, as it tests the type of the returned value. These warnings make it hard to see the real problems. Even if it's only a grep for TestCase.java and 'unused local variable' to filter these lines out :) Also, do you have a list of the unused imports for the test below? I was going to do some cleaning up in Taglibs, but can't see the list. Thanks, Hen On Wed, 26 Feb 2003, Tom Copeland wrote: unused imports are down 40% since last November, crikey! http://cvs.apache.org/~tcopeland/jakarta_bad_imports.htm Past reports can be found here - http://cvs.apache.org/~tcopeland/, and mad props to the xml-xalan project, who went from 1421 unused imports to 2 in the last month. Yours, Tom Copeland InfoEther 703-486-4543 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
On Wed, 26 Feb 2003, Tom Copeland wrote:
Hi Henri -
Hm, I'm sorry, I don't understand the TestCase thing... are you doing
something like:
import junit.framework.*;
public class FooTest extends TestCase {
public void testFiddle() {
Object obj = doSomething();
}
}
or something else?
Basically. Except it's:
Fred fred = (Fred)doSomething(); in some cases.
When I raised the discussion a while back on removing these [based on your
error reporting] there was a view that the above improves the testing,
even if it is not usually considered good style.
So I'm looking for a configuration change in the Jakarta Commons/Sandbox
[at least] reporting which removes these and makes it easier to focus on
the real problems.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
I still don't understand what the hubub about unused imports is about. Tapestry is pretty clean of them, but even if it wasn't, I wouldn't say that code quality suffered. I mean, there's some fractional difference in compile speed I guess, and a tiny difference in code comprehension that is completely eclipsed by decent comments and JavaDoc. There are other tools out there that do a better job of analyzing the code itself for deficiencies. I'd much rather see folks working to create JUnit test suites and publishing their code coverage results. Tapestry uses a framework called Clover, which is free for open source projects and produces a pretty result (using Velocity, btw). http://jakarta.apache.org/proposals/tapestry/doc/clover/ I'm very proud of the 80% coverage (on 23K NCLOC, 23000 lines of code excluding comments) and expect to push this to 90% before 2.4 GAs. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/proposals/tapestry -Original Message- From: Tom Copeland [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 2:58 PM To: [EMAIL PROTECTED] Subject: Another unused import statement report is out... unused imports are down 40% since last November, crikey! http://cvs.apache.org/~tcopeland/jakarta_bad_imports.htm Past reports can be found here - http://cvs.apache.org/~tcopeland/, and mad props to the xml-xalan project, who went from 1421 unused imports to 2 in the last month. Yours, Tom Copeland InfoEther 703-486-4543 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
Basically. Except it's: Fred fred = (Fred)doSomething(); in some cases. Hmmm it seems like that local variable is unnecessary if it's not being used later on if this is a JUnit test and it's meant to ensure a certain type is return, seems like this: assertTrue(Whoa, doSomething returned a non-Fred type!, doSomething() instanceof Fred); That way you'll get a nice error message rather than just a ClassCastException if the test fails. When I raised the discussion a while back on removing these [based on your error reporting] there was a view that the above improves the testing, even if it is not usually considered good style. So I'm looking for a configuration change in the Jakarta Commons/Sandbox [at least] reporting which removes these and makes it easier to focus on the real problems. Does the above assertTrue() thing work for you? Or maybe I'm not understanding the problem completely... Yours, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
Perhaps test code should not be analysed at all. In HttpClient we are rigorus about imports (and style in general) in production code, but are more lax in test code. Not that test code is in anyway unimportant, but just has a different purpose than production code. Yup, I'm the same way - I'm much more likely to copy and paste test code than I am real code. On the other hand, that usually comes back to bite me at some point when I have to change stuff. But, I know what you mean. Actually, for most of these reports: http://cvs.apache.org/~tcopeland/pmdweb/ I only run PMD on the foomodule/java/src directory, so I usually end up missing the tests. The jakarta-taglibs project, though, has a whole bunch of directories right under the module, so it's not as easy to separate the production code out... And, of course, this is only a rough scan, PMD has a couple of bugs that can occasionally return false positives, so your mileage may vary and all that. It's still pretty accurate though :-) Yours, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another unused import statement report is out...
I still don't understand what the hubub about unused imports is about. Tapestry is pretty clean of them, but even if it wasn't, I wouldn't say that code quality suffered. I mean, there's some fractional difference in compile speed I guess, and a tiny difference in code comprehension that is completely eclipsed by decent comments and JavaDoc. There are other tools out there that do a better job of analyzing the code itself for deficiencies. True! The reason I send these reports to the list is that: # it's easy - the report takes about 10 minutes to create # it occasionally triggers good discussions like the current one # it's fun to see all the projects side by side in any kind of view # it kind of lightens things up sometimes I'd much rather see folks working to create JUnit test suites and publishing their code coverage results. Tapestry uses a framework called Clover, which is free for open source projects and produces a pretty result (using Velocity, btw). http://jakarta.apache.org/proposals/tapestry/doc/clover/ I'm very proud of the 80% coverage (on 23K NCLOC, 23000 lines of code excluding comments) and expect to push this to 90% before 2.4 GAs. I totally concur that unit tests are far more important than unused imports, and I applaud your unit test coverage. 80% is awesome. Yours, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
In message [EMAIL PROTECTED], Hen ri Yandell writes: Basically. Except it's: Fred fred = (Fred)doSomething(); in some cases. Shouldn't you actually do something with the result as a precaution to ensure the assignment doesn't get optimized out (either by the JIT or the compiler)? (Or make sure tests are compiled and run with no optimizations and no jit with a compiler and jvm with well-understood behavior.) In any case, all metrics reports have to be taken with a grain of salt and interpreted by a human rather than blindly trusted as indications of errors. So any general out of the box configuration is not going to be suitable for all subprojects. One thing subprojects that rely on Tom's PMD reports could do is adjust their Gump descriptors (or just their build files) so that Gump will run PMD using their custom PMD configuration and generate subproject-specific reports on a daily basis. But I guess that would require Gump to publish the reports. Short of developing a comprehensive opt-in cross-subproject process plan, I think Gump's a good place to focus this sort of stuff so ad hoc process additions that require asynchronous recurrent generation of artifacts are localized in a single place. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
In message [EMAIL PROTECTED], Tom Copeland writes: assertTrue(Whoa, doSomething returned a non-Fred type!, doSomething() instanceof Fred); I retract my comment about needing to do something with the variable. Tom's comment here, in my opinion, is the best approach. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
On Wednesday 26 Feb 2003 7:57 pm, Tom Copeland wrote: unused imports are down 40% since last November, crikey! http://cvs.apache.org/~tcopeland/jakarta_bad_imports.htm Past reports can be found here - http://cvs.apache.org/~tcopeland/, and mad props to the xml-xalan project, who went from 1421 unused imports to 2 in the last month. Do you have a tool for checking for unused imports? I know I have a lot of them in my code, but weeding them takes time and time is something I'm always short of... -- [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ See one nuclear war, you've seen them all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
Simon Brooke wrote: Do you have a tool for checking for unused imports? I know I have a lot of them in my code, but weeding them takes time and time is something I'm always short of... There are a few - Tom's tool, PMD, will do it, while checkstyle will also do it. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
Tom, how are you working out the LOC for Maven? I count approx 280 .java files in the source tree and at 4066 loc, that makes approx 15 loc per file. Either we're really efficient, or there's something being missed. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Tom Copeland [EMAIL PROTECTED] wrote on 27/02/2003 06:57:50 AM: unused imports are down 40% since last November, crikey! http://cvs.apache.org/~tcopeland/jakarta_bad_imports.htm Past reports can be found here - http://cvs.apache.org/~tcopeland/, and mad props to the xml-xalan project, who went from 1421 unused imports to 2 in the last month. Yours, Tom Copeland InfoEther 703-486-4543 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
Hi Dion - I'm using JavaNCSS - http://www.kclee.com/clemens/java/javancss/ - v21.41. But I'm only scanning jakarta-turbine-maven/src/java: [EMAIL PROTECTED] jakartafun]$ find jakarta-turbine-maven/ -name *.java | wc -l 256 [EMAIL PROTECTED] jakartafun]$ find jakarta-turbine-maven/src/java -name *.java | wc -l 81 [EMAIL PROTECTED] jakartafun]$ so I think that's the difference... Yours, Tom - Original Message - From: [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 8:07 PM Subject: Re: Another unused import statement report is out... Tom, how are you working out the LOC for Maven? I count approx 280 .java files in the source tree and at 4066 loc, that makes approx 15 loc per file. Either we're really efficient, or there's something being missed. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Tom Copeland [EMAIL PROTECTED] wrote on 27/02/2003 06:57:50 AM: unused imports are down 40% since last November, crikey! http://cvs.apache.org/~tcopeland/jakarta_bad_imports.htm Past reports can be found here - http://cvs.apache.org/~tcopeland/, and mad props to the xml-xalan project, who went from 1421 unused imports to 2 in the last month. Yours, Tom Copeland InfoEther 703-486-4543 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another unused import statement report is out...
Historically Checkstyle focuses more on coding standards and checks for things like Javadoc quality, brace placement, use of whitespace, number of parameters in methods, etc. It does find unused imports and other QA checks. PMD has more of a bent on analysing the meaning of the source code, to find unused imports, variables, methods + plus other tests. Hence it is slower than Checkstyle. There is a degree of overlap between them both. It depends on what you are wanting to achieve (and how quickly) as to which one to use. Yup! Right on. If you grep either the Checkstyle or the PMD code, you'll find several places where we've borrowed ideas from each other. I know I;ve put some comments in the PMD code like Props to the Checkstyle guys for this Ant formatter gizmo which I've copied from their code. :-) Yours, tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Karma request jakarta-site2
On Wed, 26 Feb 2003, O'brien, Tim wrote: Date: Wed, 26 Feb 2003 19:12:51 -0600 From: O'brien, Tim [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: 'Jakarta General List' [EMAIL PROTECTED] Subject: Karma request jakarta-site2 Was trying to add my name to the whoweare.xml list. Could I get some karma? Done. Tim O'Brien Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
