Sonar Plugins

Changelog extractor uses path to Sonar project configuration file

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: SCM-ACTIVITY-1.3
  • Fix Version/s: SCM-ACTIVITY-1.4
  • Component/s: SCM Activity
  • Labels:
    None
  • Environment:
    Sonar 2.7, Jenkins ANT Build, pom generated during build
  • Number of attachments :
    0

Description

It looks like the 'Retrieve changelog' is based on the path to the Sonar configuration file (which is a pom when Maven is used) given with the build. This leads to an error for instance if the pom is generated and therefor not under scm control. 

[1.0.0] $ mvn -f prj/build/sonar/pom.xml ... -e -B sonar:sonar
....
[INFO]  Retrieve changelog from revision 1...
[INFO]  It can be long this first time. Next analysis will be faster.
[INFO]  	Executing: /bin/sh -c cd /export/build/hudson/jobs/prj-1.0.0/workspace/1.0.0/prj/build/sonar && svn --username foo --password '*****' --no-auth-cache --non-interactive --trust-server-cert log -v -r 1:BASE
[INFO]  	Working directory: /export/build/hudson/jobs/prj-1.0.0/workspace/1.0.0/prj/build/sonar
[INFO]  Retrieve changelog from revision 1 done: 31 ms
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Can not execute Sonar

Embedded error: Unable to retrieve changelog: svn: '.' is not a working copy
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Can not execute Sonar
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
	at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
	at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
	at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
	at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Can not execute Sonar
	at org.codehaus.mojo.sonar.Bootstraper.executeMojo(Bootstraper.java:103)
	at org.codehaus.mojo.sonar.Bootstraper.start(Bootstraper.java:79)
	at org.codehaus.mojo.sonar.SonarMojo.execute(SonarMojo.java:88)
	at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
	... 17 more
Caused by: org.sonar.api.utils.SonarException: Unable to retrieve changelog: svn: '.' is not a working copy

	at org.sonar.plugins.scmactivity.Changelog.retrieveChangeSets(Changelog.java:105)
	at org.sonar.plugins.scmactivity.Changelog.load(Changelog.java:55)
	at org.sonar.plugins.scmactivity.ScmActivitySensor.analyse(ScmActivitySensor.java:83)
	at org.sonar.batch.phases.SensorsExecutor.execute(SensorsExecutor.java:59)
	at org.sonar.batch.phases.Phases.execute(Phases.java:75)
	at org.sonar.batch.ProjectBatch.execute(ProjectBatch.java:55)
	at org.sonar.batch.Batch.analyzeModule(Batch.java:158)
	at org.sonar.batch.Batch.analyzeModules(Batch.java:76)
	at org.sonar.batch.Batch.execute(Batch.java:62)
	at org.sonar.maven.SonarMojo.executeBatch(SonarMojo.java:151)
	at org.sonar.maven.SonarMojo.execute(SonarMojo.java:142)
	at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
	at org.codehaus.mojo.sonar.Bootstraper.executeMojo(Bootstraper.java:98)
	... 21 more

This extractor should be able to work with the scm connection url in such case or with another additional provided root directory.

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. SONARPLUGINS-1287 Unable to retrieve Git changelog when Sonar executed from directory, which is symlink to original one

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Freddy Mallet added a comment -

I guess we could use this SCM developerConnection only if available and otherwise keep the current behavior.

Show
Freddy Mallet added a comment - I guess we could use this SCM developerConnection only if available and otherwise keep the current behavior.
Hide
Permalink
Evgeny Mandrikov added a comment -

Hi Andreas,

Do you confirm that directory "/export/build/hudson/jobs/prj-1.0.0/workspace/1.0.0/prj/build/sonar" is not under version control ?

Show
Evgeny Mandrikov added a comment - Hi Andreas, Do you confirm that directory "/export/build/hudson/jobs/prj-1.0.0/workspace/1.0.0/prj/build/sonar" is not under version control ?
Hide
Permalink
Evgeny Mandrikov added a comment -

Freddy, we can't use developerConnection because Sonar performs analysis only for working copy of source code.
Which means that changelog should be retrieved up to revision of working copy, which is exactly command "svn -r <start_revision>:BASE <working_copy_dir>".
Otherwise it's possible to receive inconsistent results - for example in following case:
1. svn checkout
2. build, which can take a lot of time for big project, and during this time someone can commit to Subversion
3. Sonar analysis
So if someone will perform commit in step 2 and we will not use revision of working copy, then we will consume changelog for revisions, which is not in working copy yet.

Show
Evgeny Mandrikov added a comment - Freddy, we can't use developerConnection because Sonar performs analysis only for working copy of source code. Which means that changelog should be retrieved up to revision of working copy, which is exactly command "svn -r <start_revision>:BASE <working_copy_dir>". Otherwise it's possible to receive inconsistent results - for example in following case: 1. svn checkout 2. build, which can take a lot of time for big project, and during this time someone can commit to Subversion 3. Sonar analysis So if someone will perform commit in step 2 and we will not use revision of working copy, then we will consume changelog for revisions, which is not in working copy yet.
Hide
Permalink
Andreas Mandel added a comment -

Hi Evgeny,
yes I can confirm this. The POM is generated during the ant build to give Sonar the needed information for it's job. BTW: This is not the first SVN action, before 'Retrieve changelog' - the source directories are checked for local modifications. Using the source directories to retrieve the log could be another way - but there is more than one source directory so you have to merge the results together.

Show
Andreas Mandel added a comment - Hi Evgeny, yes I can confirm this. The POM is generated during the ant build to give Sonar the needed information for it's job. BTW: This is not the first SVN action, before 'Retrieve changelog' - the source directories are checked for local modifications. Using the source directories to retrieve the log could be another way - but there is more than one source directory so you have to merge the results together.
Hide
Permalink
Evgeny Mandrikov added a comment -

Hi Andreas,

From my point of view use-case provided by you not typical for most users. So proposed solution will add unnecessary complexity to plugin. And it adds more questions, than solves problems. For example I can imagine another use-case in this case, which would be hard to cover and diagnose : different source directories checked out from different locations.

Quick-win solution for you : base directory for project should be placed under version control.

Show
Evgeny Mandrikov added a comment - Hi Andreas, From my point of view use-case provided by you not typical for most users. So proposed solution will add unnecessary complexity to plugin. And it adds more questions, than solves problems. For example I can imagine another use-case in this case, which would be hard to cover and diagnose : different source directories checked out from different locations. Quick-win solution for you : base directory for project should be placed under version control.
Hide
Permalink
Andreas Mandel added a comment -

Hi Evgeny,

looks like my point is not fully clear:

We have a ant based build in a Jenkins continuous integration system. To feed the needed information into Sonar we generate a pom.xml during the build typically into the directory /build/sonar/pom.xml. The build directory is our equivalent to the maven target directory. So we will definitely not put /build or anything below under version control. Also since the pom.xml is generated our policy does not permit to place the file outside the build directory.

In other words: Our base directory is under version control, but the pom.xml is not placed in our base directory.

With the current behavior the plugin will fail for every build that uses the -f prj/build/sonar/pom.xml option that points to a file outside of version control. And it might produce unpredictable results if the pom.xml is not placed in the base directory of the project.

I assume this is very common for none maven builds.

Might be a parameter that points to the base directory of the project might help to solve this? Default can stay as is - the directory where the pom.xml is placed.

Show
Andreas Mandel added a comment - Hi Evgeny, looks like my point is not fully clear: We have a ant based build in a Jenkins continuous integration system. To feed the needed information into Sonar we generate a pom.xml during the build typically into the directory /build/sonar/pom.xml . The build directory is our equivalent to the maven target directory. So we will definitely not put /build or anything below under version control. Also since the pom.xml is generated our policy does not permit to place the file outside the build directory. In other words: Our base directory is under version control, but the pom.xml is not placed in our base directory. With the current behavior the plugin will fail for every build that uses the -f prj/build/sonar/pom.xml option that points to a file outside of version control. And it might produce unpredictable results if the pom.xml is not placed in the base directory of the project. I assume this is very common for none maven builds. Might be a parameter that points to the base directory of the project might help to solve this? Default can stay as is - the directory where the pom.xml is placed.
Hide
Permalink
Evgeny Mandrikov added a comment -

Thanks Andreas for detailed explanation - now it's more clear.

Show
Evgeny Mandrikov added a comment - Thanks Andreas for detailed explanation - now it's more clear.
Hide
Permalink
Freddy Mallet added a comment -

Hi Andreas, in that case perhaps the best solution would be to use the Sonar Ant task (http://docs.codehaus.org/display/SONAR/Analyse+with+ANT) and in that case your issue would automatically vanish.

Show
Freddy Mallet added a comment - Hi Andreas, in that case perhaps the best solution would be to use the Sonar Ant task ( http://docs.codehaus.org/display/SONAR/Analyse+with+ANT ) and in that case your issue would automatically vanish.
Hide
Permalink
Andreas Mandel added a comment -

Hmmm, that would completely change the way we integrate our builds with Sonar - this is currently not an option. We based the integration on the Sonar Jenkins Plugin.

How is the

{base directory}

determined if the ant task is used? I could not see this in the definition of the ant task. Might be a similiar way could be used here?

Show
Andreas Mandel added a comment - Hmmm, that would completely change the way we integrate our builds with Sonar - this is currently not an option. We based the integration on the Sonar Jenkins Plugin . How is the {base directory} determined if the ant task is used? I could not see this in the definition of the ant task. Might be a similiar way could be used here?
Hide
Permalink
Freddy Mallet added a comment -

This would be very similar to what you get with Maven : the svn changelog command would be launch from where your Ant build script is located (but in that case, I guess that your ant build script would be located at the root of your project).

Show
Freddy Mallet added a comment - This would be very similar to what you get with Maven : the svn changelog command would be launch from where your Ant build script is located (but in that case, I guess that your ant build script would be located at the root of your project).
Hide
Permalink
Andreas Mandel added a comment -

I looks like the implied values do not fit in our case. The only solution I see is to provide a property sonar.projectBasePath that overrides the otherwise implied base directory.

Show
Andreas Mandel added a comment - I looks like the implied values do not fit in our case. The only solution I see is to provide a property sonar.projectBasePath that overrides the otherwise implied base directory .
Hide
Permalink
Freddy Mallet added a comment -

Interesting idea that could solve another issue that we have on the C plugin (http://jira.sonarsource.com/browse/CANSI-72).

Show
Freddy Mallet added a comment - Interesting idea that could solve another issue that we have on the C plugin ( http://jira.sonarsource.com/browse/CANSI-72 ).
Hide
Permalink
David Gageot added a comment -

With version 1.4 of the plugin, we don't load the changesets anymore

Show
David Gageot added a comment - With version 1.4 of the plugin, we don't load the changesets anymore

People

  • Assignee:
    David Gageot
    Reporter:
    Andreas Mandel
Vote (6)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved: