defect in sonar ant task passing properties ?
Locked
defect in sonar ant task passing properties ?
 
|
I believe I have found a defect in sonar-ant-task-* and how it finds property definitions. I've had this problem with 1.2, 1.3, and 1.4. It has taken an amazing amount of time to boil this down to a "simple" replication example.
I have tested with all combinations of java 1.6, 1.7 and ant 1.7.1 and 1.8.3, they all show the same results. The root of the problem is that the sonar ant task is fetching property values from build.properties if there is one, even if a particular property was defined on the ant command line with a -D parameter. That violates ant's precedence standards as I understand them. Attached is a git diff showing the changes I made to the ut-ant-multimodule-jacoco-runTests example to expose the issue. Here's the narrative description: Preparation: configure build.xml as needed to see "ant all" work correctly and load to a sonar installation 1) create a new directory "dependencies" parallel to module1 and module2 2) move module1/lib and its contents to dependencies 3) add these lines to the child build.xml files: <property file="../build.properties" /> <property name="library.root.dir" value="${basedir}/../nodir" /> 4) in the child build.xml files, change the definition of lib.junit.dir to this: <property name="lib.junit.dir" value="${library.root.dir}/lib" /> 5) optionally, add these lines to the parent build.xml, but it doesn't actually matter <property file="build.properties" /> <property name="library.root.dir" value="${basedir}/../nodir" /> At this point, re-execute > ant all And the build will fail, with a message similar to C:\Workspace\sonar-examples\sonar-examples\projects\code-coverage\ut\nodir\lib does not exist. So far, as expected, we defined library.root.dir and lib.junit.dir in such a way that seeing "...nodir\lib" is what we expect. 7) create a text file named build.properties in the same directory as the parent build.xml. Include a line defining library.root.dir with the full path to the dependencies directory added, similar to this: library.root.dir=C:/Workspace/sonar-examples/sonar-examples/projects/code-coverage/ut/ut-ant-multimodule-jacoco-runTests/dependencies Run "ant all" again, and it succeeds. (run "ant -verbose all" to see classpath details in the compile target) 8) edit build.properties, and change the definition like this: library.root.dir=baddir Run "ant all" again. It fails, as we should expect, with a message similar to C:\Workspace\sonar-examples\sonar-examples\projects\code-coverage\ut\ut-ant-multimodule-jacoco-runTests\module1\baddir\lib does not exist. Note that the path includes "baddir" which we set in our build.properties. At this point we have established that we are reading build.properties correctly, and if it contains a good definition of library.root.dir everything should work. 9) Now run ant, defining the library.root.dir property on the command line, similar to this: > ant -Dlibrary.root.dir=C:/Workspace/sonar-examples/sonar-examples/projects/code-coverage/ut/ut-ant-multimodule-jacoco-runTests/dependencies all This time we don't fail immediately - we get through the clean and compile, and the sonar task starts. But it fails at the point where it tries to define the junit task, because it has retrieved the value of library.root.dir from build.properties, instead of using the value given on the command line: BUILD FAILED C:\Workspace\sonar-examples\sonar-examples\projects\code-coverage\ut\ut-ant-multimodule-jacoco-runTests\build.xml:32: C:\Workspace\sonar-examples\sonar-examples\projects\code-coverage\ut\ut-ant-multimodule-jacoco-runTests\module1\build.xml:43: C:\Workspace\sonar-examples\sonar-examples\projects\code-coverage\ut\ut-ant-multimodule-jacoco-runTests\module1\baddir\lib does not exist. If I'm misinterpreting what I see, or if there is some way to pass additional (non-sonar.*) property definitions in to the sonar ant task that I haven't found in the documentation, I'd be happy to hear about it. Attachments: * gitdiff.txt shows changes in build.xml files and directory structure * outbad.txt and errbad.txt are stdout and stderr respectively from step #8 above * out-D.txt and err-D.txt are stdout and stderr respectively from running ant with a -D parameter to define library.root.dir in step #9 above -- Dennis R. Sherman Ex Libris (USA)Inc. 847-227-4840 [hidden email] http://www.exlibrisgroup.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email  gitdiff.txt (5K) Download Attachment outbad.txt (26K) Download Attachment errbad.txt (5K) Download Attachment out-D.txt (31K) Download Attachment err-D.txt (8K) Download Attachment |
Re: defect in sonar ant task passing properties ?
|
Dennis,
I'm in an Ant shop, but we use the Jenkins plugin to do our analyses. Nonetheless, I'm curious: * What happens when you give the commandline definition with no reference to a properties file in build.xml at all? I.e. you're describing a conflicting definition of the property, but what happens when there's no conflict & it's passed in as a -D?
* Is this weird behavior specific to "build.properties"? I.e. if you renamed it to "fred.properties" would you still see the same behavior? BTW, I'm just a community member. So feel free to ignore my curiosity. Many do! :-D Ann --- G. Ann Campbell
Sr. Systems Engineer, IS Production Systems - Shop Floor Systems Shaw Industries Inc, 201 S. Hamilton St. Dalton Ga 30720 On Mon, Jul 30, 2012 at 3:35 PM, Dennis Sherman <[hidden email]> wrote: I believe I have found a defect in sonar-ant-task-* and how it finds property definitions. I've had this problem with 1.2, 1.3, and 1.4. It has taken an amazing amount of time to boil this down to a "simple" replication example. ****************************** Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail. If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender. Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company or its subsidiaries. ****************************** |
RE: defect in sonar ant task passing properties ?
|
|
Hi Ann, Happy to answer anyone's questions if they shed light on a solution to the issue! And you've got one condition I hadn't considered, which is good. Echo before sonar task shows the value set on the command line.
I hadn't considered having no default definition at all. Good thought… but echo before sonar task shows the value as set via -D, the failure message shows
that directory blah/blah/${library.root.dir}/lib doesn't exist. Again, IMHO the same bad behavior passing the wrong value to the test target. File name doesn't matter, as long as I follow ant standards. Meaning if I use a name other than "build.properties" I have to include -propertyfile fred.properties
on the command line. And if I do, I see the same behavior as if the file were named build.properties. I've come to believe the problem really is that the sonar ant task is not passing the execution environment to the test target. BTW, the issue in our production environment is in building the compilation classpath, rather than testing. I mention that only to forestall suggestions for
managing testing other ways. It was simplest to make a test case from the existing example around the test lib, but our production problem presents exactly the same symptoms building a correct classpath. -- From: Ann Campbell [mailto:[hidden email]]
Dennis, I'm in an Ant shop, but we use the Jenkins plugin to do our analyses. Nonetheless, I'm curious: * What do you get when you echo the property in question before the sonar task? * What happens when you give the commandline definition with no reference to a properties file in build.xml at all? I.e. you're describing a conflicting definition of the property, but what happens when there's no conflict & it's passed
in as a -D?
BTW, I'm just a community member. So feel free to ignore my curiosity. Many do! :-D Ann --- G. Ann Campbell Sr. Systems Engineer, IS Production Systems - Shop Floor Systems Shaw Industries Inc, 201 S. Hamilton St. Dalton Ga 30720
On Mon, Jul 30, 2012 at 3:35 PM, Dennis Sherman <[hidden email]> wrote: I believe I have found a defect in sonar-ant-task-* and how it finds property definitions. I've had this problem with 1.2, 1.3, and 1.4. It has taken an amazing amount of time to boil this down to a "simple"
replication example. ********************************************************** Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this
message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail. If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender. Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company or its
subsidiaries. ********************************************************** |
Re: defect in sonar ant task passing properties ?
|
Hi Dennis,
I tested on a very simple example to override in the command line the "sonar.host.url property" defined in my build.xml file. It worked as expected. Same thing when overriding this property defined in my build.properties file.
Could you provide a very simple example (no module, etc.) to reproduce your issue? Thank you Regards, David RACODON | SonarSource
Senior Consultant On 30 July 2012 23:10, Dennis Sherman <[hidden email]> wrote:
|
RE: defect in sonar ant task passing properties ?
|
|
Hi David, I haven't been able to replicate the issue in a single module example. I think the problem involves the sonar ant task calling targets in child projects, so
a two module project is the simplest I have been able to come up with. -- From: David Racodon [mailto:[hidden email]]
Hi Dennis, I tested on a very simple example to override in the command line the "sonar.host.url property" defined in my build.xml file. It worked as expected. Same thing when overriding this property defined in my build.properties file. Could you provide a very simple example (no module, etc.) to reproduce your issue? Thank you Regards,
David RACODON | SonarSource
On 30 July 2012 23:10, Dennis Sherman <[hidden email]> wrote: Hi Ann, Happy to answer anyone's questions if they shed light on a solution to the issue! And you've got
one condition I hadn't considered, which is good. Echo before sonar task shows the value set on the command line.
I hadn't considered having no default definition at all. Good thought… but echo before sonar task
shows the value as set via -D, the failure message shows that directory blah/blah/${library.root.dir}/lib doesn't exist. Again, IMHO the same bad behavior passing the wrong value to the test target. File name doesn't matter, as long as I follow ant standards. Meaning if I use a name other than
"build.properties" I have to include -propertyfile fred.properties on the command line. And if I do, I see the same behavior as if the file were named build.properties. I've come to believe the problem really is that the sonar ant task is not passing the execution environment
to the test target. BTW, the issue in our production environment is in building the compilation classpath, rather than
testing. I mention that only to forestall suggestions for managing testing other ways. It was simplest to make a test case from the existing example around the test lib, but our production problem presents exactly the same symptoms building a correct classpath. -- From: Ann Campbell [mailto:[hidden email]]
Dennis, I'm in an Ant shop, but we use the Jenkins plugin to do our analyses. Nonetheless, I'm curious: * What do you get when you echo the property in question before the sonar task? * What happens when you give the commandline definition with no reference to a properties file in build.xml at all? I.e. you're describing a conflicting definition of the property,
but what happens when there's no conflict & it's passed in as a -D?
BTW, I'm just a community member. So feel free to ignore my curiosity. Many do! :-D Ann --- G. Ann Campbell Sr. Systems Engineer, IS Production Systems - Shop Floor Systems Shaw Industries Inc, 201 S. Hamilton St. Dalton Ga 30720 On Mon, Jul 30, 2012 at 3:35 PM, Dennis Sherman <[hidden email]> wrote: I believe I have found a defect in sonar-ant-task-* and how it finds property definitions. I've had this problem with 1.2, 1.3, and 1.4. It has taken an amazing amount of time to boil
this down to a "simple" replication example. ********************************************************** Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated
in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail. If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender. Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do
not relate to the official business of the company or its subsidiaries. ********************************************************** |
Re: defect in sonar ant task passing properties ?
|
|
Hi Dennis,
I made a few complementary tests. My conclusion: property defined at parent level is not passed to the module by the Sonar Ant Task. Meaning that if you do not define this property at module level, the Sonar Ant Task won't try to retrieve it from the parent level.
It also fits with the behavior that you encountered when you overrode a property of the parent file through the command line. As this property is not passed to the module, the module takes the one defined at its level (through the build.properties file declaration). If you remove this build.properties declaration, you will see that the Sonar Ant Task will no longer find this property (the expected behavior would have been for the Sonar Ant Task to retrieve it from the parent).
Could you please confirm this analysis? Thank you Regards, David RACODON | SonarSource
Senior Consultant On 6 August 2012 22:17, Dennis Sherman <[hidden email]> wrote:
|
|
I received a quesiton from a co-worker I could not answer. He asked whether or not we could create annotations in our code to prevent a violation. He was envisioning something like Flexelint wheere you could turn off(and then back on again) certain violations in the source code itself. I realize this is a little like marking it as a "false positive", but he thought it would be nice to have a way that was more permanent, self documenting, and would not go away if the database accidentally went away.
I beleived I read all the relevant documentation and could not find anything. But I thought I would double check with you folks before I gave up. Thanks in advance, Spencer --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Annotations vs False positives
|
Hello Spencer
It is a Hot-topic at our Work place currently too ;-) One way to do this is,
http://docs.codehaus.org/display/SONAR/Switch+Off+Violations+Plugin Thanks,
Krishna Chaitanya On Tue, Aug 7, 2012 at 10:42 AM, <[hidden email]> wrote: I received a quesiton from a co-worker I could not answer. He asked whether or not we could create annotations in our code to prevent a violation. He was envisioning something like Flexelint wheere you could turn off(and then back on again) certain violations in the source code itself. I realize this is a little like marking it as a "false positive", but he thought it would be nice to have a way that was more permanent, self documenting, and would not go away if the database accidentally went away. |
Re: Annotations vs False positives
|
Hi Spencer
You could also use the NOSONAR tag. See
http://docs.codehaus.org/display/SONAR/Frequently+Asked+Questions#FrequentlyAskedQuestions-NOSONAR Regards Patroklos
2012/8/7 krishna chaitanya kurnala <[hidden email]> Hello Spencer |
Re: Annotations vs False positives
|
Here is my considerations about NOSONAR - http://jira.codehaus.org/browse/SONAR-3408?focusedCommentId=296303&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-296303
Approximately the same can be applied on Switch Off Violations Plugin. And to summarize - IMO you don't need to hide violations and persist this hidings in code, because:
On Wed, Aug 8, 2012 at 12:29 AM, Papapetrou P.Patroklos <[hidden email]> wrote: Hi Spencer Best regards, Evgeny Mandrikov aka Godin <http://godin.net.ru> http://twitter.com/_godin_ |
Re: Annotations vs False positives
|
|
I recently had a similar question from a coworker around the rules that look at switch statements. There are two types: one that flags multiple cases with the same content and another that flags switches without a default.
He didn't want the rules disabled - and I agree. We felt that each such violation really did need examination. But once we've "cleared" an instance as being what we really do want in the code, then you're stuck with:
* //NOSONAR - and ignore forever every violation that might pop up on that line * mark it as a false-positive... which it's actually not. After some research he discovered that we're using the Findbugs rules for these things but that one of the other rule engines under Sonar (forget whether it's PMD or Checkstyle) has rules for these situations and recognizes annotations that turn them off. We're looking at switching.
--- G. Ann Campbell Sr. Systems Engineer, IS Production Systems - Shop Floor Systems Shaw Industries Inc, 201 S. Hamilton St. Dalton Ga 30720
On Tue, Aug 7, 2012 at 3:31 PM, Evgeny Mandrikov <[hidden email]> wrote: Here is my considerations about NOSONAR - http://jira.codehaus.org/browse/SONAR-3408?focusedCommentId=296303&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-296303 ****************************** Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail. If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender. Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company or its subsidiaries. ****************************** |
RE: defect in sonar ant task passing properties ?
|
|
In reply to this post by David Racodon-2
Hi David, Yes, I confirm that what you describe matches what I'm seeing.
I'm glad to have someone else able to replicate it. Our build environment is complex enough that it was hard to track down. Thanks. Can we look forward to a defect repair, or do we need to change our build conventions to implement a workaround? -- From: David Racodon [mailto:[hidden email]]
Hi Dennis, I made a few complementary tests. My conclusion: property defined at parent level is not passed to the module by the Sonar Ant Task. Meaning that if you do not define this property at module level, the Sonar Ant Task won't try to retrieve it from the parent level. It also fits with the behavior that you encountered when you overrode a property of the parent file through the command line. As this property is not passed to the module, the module takes the one defined at its level (through the build.properties
file declaration). If you remove this build.properties declaration, you will see that the Sonar Ant Task will no longer find this property (the expected behavior would have been for the Sonar Ant Task to retrieve it from the parent). Could you please confirm this analysis? Thank you Regards, David RACODON | SonarSource
On 6 August 2012 22:17, Dennis Sherman <[hidden email]> wrote: Hi David, I haven't been able to replicate the issue in a single module example. I think the problem involves
the sonar ant task calling targets in child projects, so a two module project is the simplest I have been able to come up with. -- From: David Racodon [mailto:[hidden email]]
Hi Dennis, I tested on a very simple example to override in the command line the "sonar.host.url property" defined in my build.xml file. It worked as expected. Same thing when overriding this property defined in my build.properties file. Could you provide a very simple example (no module, etc.) to reproduce your issue? Thank you Regards,
David RACODON | SonarSource On 30 July 2012 23:10, Dennis Sherman <[hidden email]> wrote: Hi Ann, Happy to answer anyone's questions if they shed light on a solution to the issue! And you've got
one condition I hadn't considered, which is good. Echo before sonar task shows the value set on the command line.
I hadn't considered having no default definition at all. Good thought… but echo before sonar task
shows the value as set via -D, the failure message shows that directory blah/blah/${library.root.dir}/lib doesn't exist. Again, IMHO the same bad behavior passing the wrong value to the test target. File name doesn't matter, as long as I follow ant standards. Meaning if I use a name other than
"build.properties" I have to include -propertyfile fred.properties on the command line. And if I do, I see the same behavior as if the file were named build.properties. I've come to believe the problem really is that the sonar ant task is not passing the execution environment
to the test target. BTW, the issue in our production environment is in building the compilation classpath, rather than
testing. I mention that only to forestall suggestions for managing testing other ways. It was simplest to make a test case from the existing example around the test lib, but our production problem presents exactly the same symptoms building a correct classpath. -- From: Ann Campbell [mailto:[hidden email]]
Dennis, I'm in an Ant shop, but we use the Jenkins plugin to do our analyses. Nonetheless, I'm curious: * What do you get when you echo the property in question before the sonar task? * What happens when you give the commandline definition with no reference to a properties file in build.xml at all? I.e. you're describing a conflicting definition of the property,
but what happens when there's no conflict & it's passed in as a -D?
BTW, I'm just a community member. So feel free to ignore my curiosity. Many do! :-D Ann --- G. Ann Campbell Sr. Systems Engineer, IS Production Systems - Shop Floor Systems Shaw Industries Inc, 201 S. Hamilton St. Dalton Ga 30720 On Mon, Jul 30, 2012 at 3:35 PM, Dennis Sherman <[hidden email]> wrote: I believe I have found a defect in sonar-ant-task-* and how it finds property definitions. I've had this problem with 1.2, 1.3, and 1.4. It has taken an amazing amount of time to boil
this down to a "simple" replication example. ********************************************************** Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated
in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail. If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender. Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do
not relate to the official business of the company or its subsidiaries. ********************************************************** |
Re: defect in sonar ant task passing properties ?
|
|
Hi Dennis,
Regards,
David RACODON | SonarSource
Senior Consultant On 8 August 2012 23:16, Dennis Sherman <[hidden email]> wrote:
|
| Powered by Nabble | Edit this page |