[Request for feedback] Scanner for Gradle 2.1 (with Android support)

468 views
Skip to first unread message

Julien HENRY

unread,
Aug 26, 2016, 11:01:05 AM8/26/16
to SonarQube
Hi guys,

I have published SonarQube Scanner for Gradle 2.1-rc1 on the Gradle plugin portal.

This version:
  • fixes support of Gradle 3
  • bring out of the box support of analyzing Android projects with SonarQube Java analyzer: no more need to manually provide source and classpath properties, the plugin will automatically collect all data from the "release" build type
  • fixes support of "compileOnly" dependencies
Feedback is welcome until middle of next week.

Full release notes:

++

Julien

m.gae...@gmail.com

unread,
Aug 30, 2016, 2:32:16 AM8/30/16
to SonarQube
Hello,

I wanted to try this new release in my project, but I get the following exception: http://pastebin.com/z2T1HP3a
My project is an Android project, using Gradle 3.0 and Android Gradle Plugin 2.2.0-beta3.
I also have product flavors with flavor dimensions, and I guess this is why it is failing for me: in my project, the task name is not "compileReleaseJavaWithJavac", but "compileProductFlavor1ProductFlavor2ReleaseJavaWithJavac".

Don't hesitate to ask for more information if needed,
Gaëtan

Julien HENRY

unread,
Aug 30, 2016, 9:26:46 AM8/30/16
to SonarQube, m.gae...@gmail.com
Thanks for the feedback! I'll fix that.

Julien

Julien HENRY

unread,
Aug 30, 2016, 12:51:50 PM8/30/16
to SonarQube, m.gae...@gmail.com
Hi Gaëtan,

I have published version 2.1-rc2 with proper support of flavors. By default I use the first release flavor to configure the SonarQube analysis. If this is not appropriate there is a parameter to specify the variant name to use:

android {
  productFlavors {
    demo {
      ...
    }
    full {
      ...
    }
  }
}

sonarqube {
    androidVariant 'fullRelease'
}

Can you confirm it works for you?

Thanks

Julien

m.gae...@gmail.com

unread,
Aug 31, 2016, 2:54:06 AM8/31/16
to SonarQube, m.gae...@gmail.com
Hi Julien,

Thanks for the quick fix. It is working better.

However I am still facing an issue. I don't know if it is a bug in the plugin or a wrong configuration in my project.
When I run `./gradlew sonarqube`, it fails with the following error: http://pastebin.com/qDj36DJE.
- The specified folder does not exists (as stated by the error) and I don't know where to find the required classes for tests
- The product flavor in the stacktrace does not match the value I specified in sonarqube.androidVariant
I have a basic configuration without any properties to specify the sources/tests folders (only the project name, key, version, Sonar host, ...).

I managed to work around this issue by adding this in my root `build.gradle`, but I don't have any coverage information if I do this:

subprojects {
sonarqube {
properties {
property 'sonar.java.test.binaries', ''
}
}
}



Gaëtan

Julien HENRY

unread,
Aug 31, 2016, 4:19:24 AM8/31/16
to SonarQube, m.gae...@gmail.com
Hi Gaëtan,

Are ${workingDirectory} and ${productFlavor} in the original stacktrace or is it an anonymization you have made?

Would you mind sharing a reproducer? You can probably remove all source files, and you can send it directly to me for privacy.

Thanks

Julien

m.gae...@gmail.com

unread,
Aug 31, 2016, 5:41:44 AM8/31/16
to SonarQube, m.gae...@gmail.com
Yes, in the original stacktrace, ${workingDirectory} and ${productFlavor} have a real value.
I will try to provide a simple project to reproduce this if I can.

Julien HENRY

unread,
Sep 2, 2016, 8:15:37 AM9/2/16
to SonarQube, m.gae...@gmail.com
Hi Gaëtan,

Any update?

++

Julien

cli...@gmail.com

unread,
Sep 2, 2016, 10:16:00 AM9/2/16
to SonarQube, m.gae...@gmail.com
It seems that it is still necessary to provide the property "sonar.java.version". If not I see false positives for Java8-rules such as squid:S1609.
Also Android Lint-rule violations don't seem to be working (if the Android plugin is installed on SonarQube).

Julien HENRY

unread,
Sep 5, 2016, 5:09:41 AM9/5/16
to SonarQube, m.gae...@gmail.com, cli...@gmail.com
Hi,


Le vendredi 2 septembre 2016 16:16:00 UTC+2, cli...@gmail.com a écrit :
It seems that it is still necessary to provide the property "sonar.java.version". If not I see false positives for Java8-rules such as squid:S1609.

This issue was already reported and I'm looking into it. Anyway thanks for the feedback.
 
Also Android Lint-rule violations don't seem to be working (if the Android plugin is installed on SonarQube).

I didn't focus on supporting Android Lint but you probably simply need to pass the property sonar.android.lint.report=<path to your lint report>. Of course you need to have the SonarQube Android plugin installed and its rules activated in your quality profile.

Julien HENRY

unread,
Sep 5, 2016, 5:58:15 AM9/5/16
to SonarQube, m.gae...@gmail.com, cli...@gmail.com
I made some tests and things are working as expected regarding Java source level. As mentioned in Android documentation you have to specify in your build the Java source level (providing only the compileSdkVersion is not enough). If you don't it will take the source level of the current JVM you are using to run Gradle (so 1.8).

For example:

android {
  compileSdkVersion XX
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
  }
}

pablo.a....@gmail.com

unread,
Sep 6, 2016, 5:42:51 AM9/6/16
to SonarQube, m.gae...@gmail.com, cli...@gmail.com
Salut Julien,

I have just updated to rc3, I have a multimodule Android project with flavors, and all seems to work fine.


just one question where should I place the flavor variant:

sonarqube {
androidVariant 'ukPlayStoreDebug'
}

or 

sonarqube {
    properties {
       androidVariant 'ukPlayStoreDebug'
    }
}

regards

Julien HENRY

unread,
Sep 6, 2016, 6:11:16 AM9/6/16
to SonarQube, m.gae...@gmail.com, cli...@gmail.com, pablo.a....@gmail.com
Hi Pablo,

I'm expecting the first syntax to work:

sonarqube {
androidVariant 'ukPlayStoreDebug'
}

Can you confirm? Running sonarqube task should automatically run compileUkPlayStoreDebugJavac task.

++

Julien

Pablo A. Martínez Andrés

unread,
Sep 6, 2016, 7:49:33 AM9/6/16
to Julien HENRY, SonarQube, m.gae...@gmail.com, cli...@gmail.com
Then there is something wrong, if I configure it outside properties build fails with:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':sonarqube'.
> No files nor directories matching 'build/intermediates/classes/ukPlayStore/debug'

Configuring it inside properties makes the build successful



# Pablo A. Martínez Andrés

Julien HENRY

unread,
Sep 6, 2016, 8:40:25 AM9/6/16
to Pablo A. Martínez Andrés, SonarQube
Can you send me full logs of the SonarQube task (--debug --stacktrace)? You can send them privately if you prefer.

Julien HENRY

unread,
Sep 8, 2016, 5:18:09 AM9/8/16
to Pablo A. Martínez Andrés, SonarQube
Hi Pablo,

First I don't see any error in the logs you sent. The easiest way for me to investigate would be to send me a reproducer (sample project).

Few details:
  - passing androidVariant in sonarqube properties has NO effect. That's why you think it works.
  - by default, when you run 'sonarqube' task alone, it will automatically run javac compilation of the first release variant, and use this variant to configure the analysis (source fodlers, output folders, ...). Passing androidVariant allows to select the variant to be used if the default doesn't fit your needs. May I ask you why you want to use this 'ukPlayStoreDebug' variant?
  - I see that you are running ./gradlew test sonarqube so if I'm correct the 'test' task will compile and run unit tests of all variants. then I don't understand why 'build/intermediates/classes/ukPlayStore/debug' would be missing... Do you have an idea?
  - you are still passing manually a lot of properties  that the plugin is intended to automatically guess (that was the point of my sprint). In order to simplify your build.gradle and to really test the plugin you should stop manually passing: sonar.java.source, sonar.sources, sonar.binaries, sonar.java.binaries, sonar.tests. Please also try to remove sonar.jacoco.reportPath and sonar.junit.reportsPath but I'm not sure it will still work.

++

Julien

Pablo A. Martínez Andrés

unread,
Sep 9, 2016, 4:23:14 AM9/9/16
to Julien HENRY, SonarQube
Hi I'm working as freelance on this project so I only have access to this CI when I'm on site.

About the variants, we have two flavors, ukPlayStore and worldPlayStore,  world version just differs on a couple of flags from uk version which has all the business logic and code.

Our release versions run proguard, so I guessed that it was better to run sonarqube in debug mode, shouldn't I?

I will try to remove all given config params from gradle and check If builds is ok, I'll let you know, asap.

Regards



# Pablo A. Martínez Andrés


Julien HENRY

unread,
Sep 9, 2016, 4:50:21 AM9/9/16
to Pablo A. Martínez Andrés, SonarQube

2016-09-09 10:22 GMT+02:00 Pablo A. Martínez Andrés <pablo.a....@gmail.com>:
Our release versions run proguard, so I guessed that it was better to run sonarqube in debug mode, shouldn't I?

That's an interesting feedback. Maybe I should default to analyze 'debug' variant instead of 'release' variant. WDYT?

Pablo A. Martínez Andrés

unread,
Sep 9, 2016, 6:21:48 AM9/9/16
to Julien HENRY, SonarQube
yes, I think so, android apps in release mode don't run proguard by default but we are encoruaged to do so by Google documentation and most developers probably do it.

# Pablo A. Martínez Andrés


Stephane Renou

unread,
Sep 19, 2016, 11:17:05 AM9/19/16
to SonarQube
Hello,

I tried that new version of the plugin but unfortunately could not get it to run. I am testing with rc3.
I am getting a null pointer exception as:

* What went wrong:
Could not determine the dependencies of task ':sonarqube'.
> java.lang.NullPointerException (no error message)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

the full stacktrace is:
* Exception is:
org.gradle.api.GradleException: Could not determine the dependencies of task ':sonarqube'.
        at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext.resolve(CachingTaskDependencyResolveContext.java:67)
        at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext.getDependencies(CachingTaskDependencyResolveContext.java:55)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.addToTaskGraph(DefaultTaskExecutionPlan.java:139)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.addTasks(DefaultTaskGraphExecuter.java:98)
        at org.gradle.execution.TaskNameResolvingBuildConfigurationAction.configure(TaskNameResolvingBuildConfigurationAction.java:47)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:48)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.access$000(DefaultBuildConfigurationActionExecuter.java:25)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter$1.proceed(DefaultBuildConfigurationActionExecuter.java:54)
...
Caused by: java.lang.NullPointerException
        at org.sonarqube.gradle.SonarQubePlugin.lambda$null$6(SonarQubePlugin.java:121)
        at org.sonarqube.gradle.SonarQubePlugin$$Lambda$15/365999192.apply(Unknown Source)
        at org.sonarqube.gradle.SonarQubePlugin.lambda$createTask$8(SonarQubePlugin.java:127)
        at org.sonarqube.gradle.SonarQubePlugin$$Lambda$12/312560500.call(Unknown Source)
        at org.gradle.util.GUtil.uncheckedCall(GUtil.java:401)
        at org.gradle.api.internal.tasks.DefaultTaskDependency.visitDependencies(DefaultTaskDependency.java:76)
        at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext$TaskGraphImpl.getNodeValues(CachingTaskDependencyResolveContext.java:88)
        at org.gradle.internal.graph.CachingDirectedGraphWalker$GraphWithEmpyEdges.getNodeValues(CachingDirectedGraphWalker.java:202)
        at org.gradle.internal.graph.CachingDirectedGraphWalker.doSearch(CachingDirectedGraphWalker.java:112)
        at org.gradle.internal.graph.CachingDirectedGraphWalker.findValues(CachingDirectedGraphWalker.java:64)
        at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext.doResolve(CachingTaskDependencyResolveContext.java:76)
        at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext.resolve(CachingTaskDependencyResolveContext.java:65)

I guess I forgot a parameter somewhere, but could not find where. I am reusing my build script that was working fine when using plugin release 1.0.
I tweaked around the parameters.

I would really like to enjoy the work you are doing to remove some of the manual data that I need to provide, so tell me what I can do to provide more data.

Julien HENRY

unread,
Sep 19, 2016, 11:24:44 AM9/19/16
to SonarQube
Hi Stephane,

Any change you can share a reproducer? Also could you please tell me the version of Gradle and the version of the android plugin you are using?

Thanks

Julien

m...@thomaskeller.biz

unread,
Sep 27, 2016, 5:08:35 AM9/27/16
to SonarQube, pablo.a....@gmail.com
Hi Julien,

yes, absolutely, you should only grab results from the various "debug" variants an Android application / library provides. This is because Android Instrumentation tests will _always_ run on the debug build type of the app under test, never under the release build type, as you need a proper signing setup for the latter (debug builds, i.e. the app's apk and the test apk that contains the test code, are signed with a default debug keystore that is usually created during SDK installation / first use and Android's build tools have a default password set up for this).

Regarding proguard, this can also be set up for debug and test builds (and actually should be done to be able to catch proguard-induced issues in production code), but obviously with obfuscation turned off.

I found this thread a bit too late, so I posted more findings where the scanner currently does not work as expected here: https://groups.google.com/forum/#!topic/sonarqube/rBKe33H2bNo

Thomas.

Julien HENRY

unread,
Sep 27, 2016, 9:12:17 AM9/27/16
to SonarQube, pablo.a....@gmail.com, m...@thomaskeller.biz
Hi Thomas,

I made the change in release 2.1. I now take by default the first debug variant.

I'll have a look at your other thread.

++

Julien
Reply all
Reply to author
Forward
0 new messages