Gradle Sonar plugin broken with Sonar 3.4?

Old Forum Archive
1

We are using Gradle 1.3. We upgraded our Sonar installation from 3.3 to 3.4 and now the Sonar plugin fails with a ClassNotFoundException when the Sonar Batch is trying to “Install plugins”:

Caused by: org.sonar.api.utils.SonarException: Fail to load plugin findbugs

at org.sonar.core.plugins.PluginClassloaders.instantiatePlugin(PluginClassloaders.java:229)

at org.sonar.core.plugins.PluginClassloaders.init(PluginClassloaders.java:97)

at org.sonar.batch.bootstrap.BatchPluginRepository.doStart(BatchPluginRepository.java:82)

at org.sonar.batch.bootstrap.BatchPluginRepository.start(BatchPluginRepository.java:63)

at org.picocontainer.lifecycle.ReflectionLifecycleStrategy.invokeMethod(ReflectionLifecycleStrategy.java:110)

… 82 more Caused by: java.lang.NoClassDefFoundError: org/sonar/api/SonarPlugin

at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)

at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)

at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)

at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)

at org.sonar.core.plugins.PluginClassloaders.instantiatePlugin(PluginClassloaders.java:222)

… 86 more Caused by: java.lang.ClassNotFoundException: org.sonar.api.SonarPlugin

at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)

at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)

at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)

… 91 more

The same problem is reproducible on my local maschine with a clean Sonar 3.4 installation and the Gradle sample project located in the distribution under samples/sonar/quickstart. But running Sonar on that sample project by using the Sonar Ant tasks did work.

I am not sure if this a problem of the new Sonar version or an incompatibility between the Gradle Sonar plugin and the new Sonar version…

Please help…

2

thanks for reporting this. I’ll have a look on this in the next couple of days and give you feedback.

cheers, Rene

3

We are having the exact same issue. I know you are looking into it so I will deactivate for now or roll back the sonar install for a while.

4

We are also having the same problem. Please let me know when a solution becomes available.

5

The Sonar plugin will have to undergo bigger changes to work with Sonar 3.4 and higher. Given that Gradle 1.4 is almost out, this will have to wait at least until 1.5.

6

Thanks for the information, Peter!

For those of you who don´t want to downgrade your Sonar installation back to <3.4 I have worked out a temporary workaround that hopefully is not too much efford and greatly demonstrates the strenghts of Gradle’s Ant integration :wink: This is intended to be a relatively simple workaround until Gradle supports Sonar 3.4 again. Unfortunately you need to pass your project settings manually instead of using the Gradle objects, but I guess for most projects it is worth a consideration.

Basic idea is to replace the broken sonarAnalyze task by a custom task that uses the original Sonar Ant task. I am using this solution on a multiproject build and I even did not need to change my CI config because the command line call stays the same.

I hope this helps, greetings to all Gradlers out there! Bernd Steinert

To replace the gradle plugin change the line “apply plugin: ‘sonar’” to “apply from ‘sonar.gradle’” in your build file(s).

sonar.gradle:

apply plugin: 'java'
  repositories {
    mavenCentral()
}
  configurations {
    sonar
}
  dependencies {
    sonar group: 'org.codehaus.sonar-plugins', name: 'sonar-ant-task', version: '2.0'
}
  task sonarAnalyze << {
      // define the Sonar properties according to Sonar Ant task documentation
    ant.properties['sonar.host.url'] = 'http://localhost:9000/sonar'
    ...
          // define multi-project modules
    ant.properties['sonar.modules'] = 'mod1,mod2,mod3'
          // define module specific properties
    ant.properties['mod1.sonar.sources'] = 'other/src/folder'
    ant.properties['mod2.sonar.sources'] = 'src,multiple/src/folders'
      ant.taskdef(name: 'sonar', classname: 'org.sonar.ant.SonarTask', classpath: configurations.sonar.asPath)
      ant.sonar()
}
7

Thanks for the workaround, I’ll give it a try. Peter, do you already have a JIRA to track the necessary changes to support sonar 3.4+?

Oliver

8

The work is already mostly done. You can try it in the latest nightly.

9

I’ve linked this to GRADLE-2657. Fix will be included in 1.5.

10

Peter, thanks for fixing this. Are you able to point us to a nightly build of this plugin. I assume we can just reference the sonar plugin rather than running an entire gradle 1.5-SNAPSHOT?

11

Since the plugin is part of the Gradle distribution, you’ll have to switch to a nightly Gradle build to give it a try. This is as easy as pointing your wrapper to a new location. (Needless to say, nightly builds aren’t intended for production use.) Note that we eventually decided to add a new plugin (‘sonar-runner’) rather than changing the old one. You can read more about it in the nightly user guide. Note that the new plugin is incubating and things may still change, especially until 1.5 is released.

We are grateful for any feedback on the new ‘sonar-runner’ plugin.

12

Thank you for fixing this.

I used the nightly build gradle-1.5-20130213172554 and got sonarRunner task to work and upload results to the sonar database.

Referring to : http://www.gradle.org/docs/nightly/userguide/sonar_runner_plugin.html#N13631

I change the variable names to:

’ property “sonar.jdbc.username”, “Fred Flintstone” property “sonar.jdbc.password”, “very clever”’