Violations for files in project root folder cannot be fed

[Bertk]

A file name entry in a XML report using a simple file name without any path information (e.g. file exists in project root folder) will not be handled correctly.
The reported issues from CppCheck and Vera++ will not be considered for these files.
Root cause: org.sonar.api.resources.File.fromIOFile returns null
Hint: RATS XML reports will work because a "./" prefix is used for these kind of file names.

[guwirth]

Maybe #155 solves the problem?

[guwirth]

Also wondering what is the expected behavior/definition for sonar.sources?
If I set nothing,

• is the current directory of the sonar configuration file the default?
• or do I have to set sonar.sources=.?

Manual: sonar.sources
Comma-separated paths to directories containing source files. Compatible with Maven since SonarQube 4.2. If not set, the source code is retrieved from the default Maven source code location.

[s7726]

I'm hitting the issue of not having './' at the beginning of the paths. Was working prior to sonar 4.2.

[guwirth]

A file name entry in a XML report using a simple file name without any path information

For me that means sensors are searching in all folders defined in sonar.sources?
If folders in sonar.sources are relative the root folder is used as an anchor.

There are still some questions

• if sonar.sources is not defined, is the default 'sonar.sources=.' ?
• if file wasn't found in sonar.sources is there an additional search in root folder?
• 'filename' and './filename' should have the same meaning?

[wenns]

2014-04-18 10:28 GMT+02:00 Günter Wirth notifications@github.com:

A file name entry in a XML report using a simple file name without any
path information

For me that means sensors are searching in all folders defined in sonar.
sources?
If folders in sonar.sources are relative the root folder is used as an
anchor.

There are still some questions

• if sonar.sources is not defined, is the default 'sonar.sources=.' ?

sonar.sources is obligatory, you have to define it.

• if file wasn't found in sonar.sources is there an additional search
  in root folder?

Thats the central question here: what is the search path for stuff coming
from exteral reports?? Trying to figure out the answer:

• Our samples either use pathes relative to projects root or absolute pathes, if the tool cannot use relative ones.
• The algorithm used in the core for path resolving, as far as I am aware of,
  didnt work if you tried to save a violation which addresses a file
  relative to a source dir (as in sonar.sources). See the top of this tread...
• I am not aware of any across-plugins-standard defining that. C# and Java
  plugins, if I understand correctly, make certain assumptions which are
  baked by strong conventions in respective communities. The python plugin
  also doesnt define it; it just throws the paths at Sonar and relies on its path
  resolving capabilities.
• Having only one anchor would save performance for planned extensions of saveViolation (where we will actually try to find files on the FS before feeding them to Sonar)

Looking at all that, I get the feeling we should define that the reports
should use paths relative to projects root. And in case of multi-module
setups relative to root of the according module. Not sure about the latter,
though, it also depends on how the core likes it...

• 'filename' and './filename' should have the same meaning?

Would say yes.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/102#issuecomment-40794907
.

[s7726]

Parking relative to modules (aka subdirectories) would complicate running
tools again our source. Right no I can run most of our tools as a single
instance from the base directory and get one report. Running against each
subdirectory, to get individual reports would increase needed scan time due
to the tools need to redundantly scan the other directories for dependency
information.

This would be much easier if sonar would just recognize
filename
./filename
As the same file. The way it used to.

I say check for a "./" at the beginning, and if it's not there add it.
That's what the script to keep me running in the mean time does.
On Apr 24, 2014 4:50 AM, "Waleri Enns" notifications@github.com wrote:

2014-04-18 10:28 GMT+02:00 Günter Wirth notifications@github.com:

A file name entry in a XML report using a simple file name without any
path information

For me that means sensors are searching in all folders defined in sonar.
sources?
If folders in sonar.sources are relative the root folder is used as an
anchor.

There are still some questions

• if sonar.sources is not defined, is the default 'sonar.sources=.' ?

sonar.sources is obligatory, you have to define it.

• if file wasn't found in sonar.sources is there an additional search
  in root folder?

Thats a central question here: what is the search path for stuff coming
from exteral reports?? Trying to figure out the answer:

• Our samples all use pathes relative to projects root.
• The algorithm used for path resolving, as far as I am aware of,
  didnt work if you tried to save a violation which adresses a file
  relative to a source dir (as in sonar.sources).
• I am not aware of any accross-plugins standard defining that. C# and
  Java
  plugins, if I understand correctly, make certain assumptions which are
  baked by strong conventions in respective communities. The python plugin
  also doesnt define it just throws the paths at Sonar and relies on its
  path
  resolving capabilities.

Looking at all that, I get the feeling we should define that the reports
should use paths relative to projects root. And in case of multi-module
setups relative to root of the according module. Not sure about the
latter,
though, it also depends on how the core likes it...

• 'filename' and './filename' should have the same meaning?

Would say yes.

—
Reply to this email directly or view it on GitHub<
https://github.com/wenns/sonar-cxx/issues/102#issuecomment-40794907>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/102#issuecomment-41270853
.

[wenns]

Parking relative to modules (aka subdirectories)
Not sure if youre misunderstanding this: not every subdirectory is a module in Sonar's sense -- modules have to be explicitly configured. See e.g. http://docs.codehaus.org/display/SONAR/Analyzing+with+SonarQube+Runner

would complicate running
tools again our source. Right no I can run most of our tools as a single
instance from the base directory and get one report. Running against each
subdirectory, to get individual reports would increase needed scan time due
to the tools need to redundantly scan the other directories for dependency
information.

Im fine with the "relative to projects basedir or absolute and nothing more" policy. But I did not test if things, especially multi-module setups, do run smoothly against recent versions of Sonar. Did you?

This would be much easier if sonar would just recognize
filename
./filename
As the same file. The way it used to.

Im not that often on sonar dev lists anymore... Did Sonars devs make a statement on this behaviour change?

[s7726]

Having things organized into sub directories causes sonar to see them as
modules now. Each directory of sources you give sonar becomes a module.

Yes. I pointed it out as a regression in relative path handling. They
called it a feature.
On Apr 24, 2014 7:40 AM, "Waleri Enns" notifications@github.com wrote:

Parking relative to modules (aka subdirectories)
Not sure if youre misunderstanding this: not every subdirectory is a
module in Sonar's sense -- modules have to be explicitly configured. See
e.g.
http://docs.codehaus.org/display/SONAR/Analyzing+with+SonarQube+Runner

would complicate running
tools again our source. Right no I can run most of our tools as a single
instance from the base directory and get one report. Running against each
subdirectory, to get individual reports would increase needed scan time due
to the tools need to redundantly scan the other directories for dependency
information.

Im fine with the "relative to projects basedir or absolute and nothing
more" policy. But I did not test if things, especially multi-module setups,
do run smoothly against recent versions of Sonar. Did you?

This would be much easier if sonar would just recognize
filename
./filename
As the same file. The way it used to.

Im not that often on sonar dev lists anymore... Did Sonars devs make a
statement on this behaviour change?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/102#issuecomment-41287848
.

[wenns]

Having things organized into sub directories causes sonar to see them as
modules now. Each directory of sources you give sonar becomes a module.

Since 4.2??

[s7726]

Yes
On Apr 24, 2014 8:09 AM, "Waleri Enns" notifications@github.com wrote:

Having things organized into sub directories causes sonar to see them as
modules now. Each directory of sources you give sonar becomes a module.
Since 4.2??

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/102#issuecomment-41291372
.

[guwirth]

I_m also thinking that _"filename"* and "./filename" should be the same.

[wenns]

Fixed with 10bd87a. Tested via smoketest.

[s7726]

I know the pathing issue also affects rats and vera results. Possibly a couple others as well but I won't be back into the office till Monday to verify.