Quantcast

defect in sonar ant task passing properties ?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

defect in sonar ant task passing properties ?

Dennis Sherman-2
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: defect in sonar ant task passing properties ?

Ann Campbell
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?

* 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.

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



**********************************************************
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.
**********************************************************

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: defect in sonar ant task passing properties ?

Dennis Sherman-2

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.

 

--
Dennis R. Sherman
Ex Libris (USA)Inc.
847-227-4840
[hidden email]
http://www.exlibrisgroup.com

 

From: Ann Campbell [mailto:[hidden email]]
Sent: Monday, July 30, 2012 2:51 PM
To: [hidden email]
Subject: Re: [sonar-user] 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 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?


* 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.

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

 

 

**********************************************************

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.

**********************************************************

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: defect in sonar ant task passing properties ?

David Racodon-2
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:

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.

 

--
Dennis R. Sherman
Ex Libris (USA)Inc.
<a href="tel:847-227-4840" value="+18472274840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com

 

From: Ann Campbell [mailto:[hidden email]]
Sent: Monday, July 30, 2012 2:51 PM
To: [hidden email]
Subject: Re: [sonar-user] 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 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?


* 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.

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.
<a href="tel:847-227-4840" value="+18472274840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

 

 

**********************************************************

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.

**********************************************************

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: defect in sonar ant task passing properties ?

Dennis Sherman-2

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.

 

--
Dennis R. Sherman
Ex Libris (USA)Inc.
847-227-4840
[hidden email]
http://www.exlibrisgroup.com

 

From: David Racodon [mailto:[hidden email]]
Sent: Friday, August 03, 2012 10:29 AM
To: [hidden email]
Subject: Re: [sonar-user] 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:

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.

 

--
Dennis R. Sherman
Ex Libris (USA)Inc.
<a href="tel:847-227-4840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com

 

From: Ann Campbell [mailto:[hidden email]]
Sent: Monday, July 30, 2012 2:51 PM
To: [hidden email]
Subject: Re: [sonar-user] 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 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?


* 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.

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.
<a href="tel:847-227-4840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

 

 

**********************************************************

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.

**********************************************************

 

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: defect in sonar ant task passing properties ?

David Racodon-2
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:

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.

 

--
Dennis R. Sherman
Ex Libris (USA)Inc.
<a href="tel:847-227-4840" value="+18472274840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com

 

From: David Racodon [mailto:[hidden email]]
Sent: Friday, August 03, 2012 10:29 AM
To: [hidden email]
Subject: Re: [sonar-user] 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:

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.

 

--
Dennis R. Sherman
Ex Libris (USA)Inc.
<a href="tel:847-227-4840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com

 

From: Ann Campbell [mailto:[hidden email]]
Sent: Monday, July 30, 2012 2:51 PM
To: [hidden email]
Subject: Re: [sonar-user] 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 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?


* 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.

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.
<a href="tel:847-227-4840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

 

 

**********************************************************

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.

**********************************************************

 

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Annotations vs False positives

Spencer
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations vs False positives

krishna chaitanya kurnala
Hello Spencer

It is a Hot-topic at our Work place currently too ;-)

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.



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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations vs False positives

Patroklos Papapetrou
Hi Spencer
You could also use the NOSONAR tag.

Regards
Patroklos

2012/8/7 krishna chaitanya kurnala <[hidden email]>
Hello Spencer

It is a Hot-topic at our Work place currently too ;-)

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.



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




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations vs False positives

Evgeny Mandrikov
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:
  • if rule produces false-positives, then report this to us so we can improve rule - better to improve rule than just ignore
  • if rule produces too many false-positives, you have an option to disable it, because it is not suitable in your environment

On Wed, Aug 8, 2012 at 12:29 AM, Papapetrou P.Patroklos <[hidden email]> wrote:
Hi Spencer
You could also use the NOSONAR tag.

Regards
Patroklos


2012/8/7 krishna chaitanya kurnala <[hidden email]>
Hello Spencer

It is a Hot-topic at our Work place currently too ;-)

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.



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







--
Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>
http://twitter.com/_godin_
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Annotations vs False positives

Ann Campbell
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
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:
  • if rule produces false-positives, then report this to us so we can improve rule - better to improve rule than just ignore
  • if rule produces too many false-positives, you have an option to disable it, because it is not suitable in your environment

On Wed, Aug 8, 2012 at 12:29 AM, Papapetrou P.Patroklos <[hidden email]> wrote:
Hi Spencer
You could also use the NOSONAR tag.

Regards
Patroklos


2012/8/7 krishna chaitanya kurnala <[hidden email]>
Hello Spencer

It is a Hot-topic at our Work place currently too ;-)

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.



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







--
Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>
http://twitter.com/_godin_


**********************************************************
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.
**********************************************************

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: defect in sonar ant task passing properties ?

Dennis Sherman-2
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?

 

--
Dennis R. Sherman
Ex Libris (USA)Inc.
847-227-4840
[hidden email]
http://www.exlibrisgroup.com

 

From: David Racodon [mailto:[hidden email]]
Sent: Tuesday, August 07, 2012 12:26 PM
To: [hidden email]
Subject: Re: [sonar-user] 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:

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.

 

--
Dennis R. Sherman
Ex Libris (USA)Inc.
<a href="tel:847-227-4840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com

 

From: David Racodon [mailto:[hidden email]]
Sent: Friday, August 03, 2012 10:29 AM
To: [hidden email]
Subject: Re: [sonar-user] 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:

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.

 

--
Dennis R. Sherman
Ex Libris (USA)Inc.
<a href="tel:847-227-4840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com

 

From: Ann Campbell [mailto:[hidden email]]
Sent: Monday, July 30, 2012 2:51 PM
To: [hidden email]
Subject: Re: [sonar-user] 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 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?


* 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.

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.
<a href="tel:847-227-4840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

 

 

**********************************************************

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.

**********************************************************

 

 

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: defect in sonar ant task passing properties ?

David Racodon-2
Hi Dennis,


Regards,

David RACODON | SonarSource
Senior Consultant



On 8 August 2012 23:16, Dennis Sherman <[hidden email]> wrote:

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?

 

--
Dennis R. Sherman
Ex Libris (USA)Inc.
<a href="tel:847-227-4840" value="+18472274840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com

 

From: David Racodon [mailto:[hidden email]]
Sent: Tuesday, August 07, 2012 12:26 PM
To: [hidden email]
Subject: Re: [sonar-user] 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:

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.

 

--
Dennis R. Sherman
Ex Libris (USA)Inc.
<a href="tel:847-227-4840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com

 

From: David Racodon [mailto:[hidden email]]
Sent: Friday, August 03, 2012 10:29 AM
To: [hidden email]
Subject: Re: [sonar-user] 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:

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.

 

--
Dennis R. Sherman
Ex Libris (USA)Inc.
<a href="tel:847-227-4840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com

 

From: Ann Campbell [mailto:[hidden email]]
Sent: Monday, July 30, 2012 2:51 PM
To: [hidden email]
Subject: Re: [sonar-user] 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 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?


* 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.

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.
<a href="tel:847-227-4840" target="_blank">847-227-4840
[hidden email]
http://www.exlibrisgroup.com





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

 

 

**********************************************************

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.

**********************************************************

 

 

 


Loading...