Gradle, Sonar and ${}

(Marcin Kuszczak) #1


I have started implementing Gradle build scripts for our company purposes, but I met some obstacles.

Problem is with variable In Gradle it is calculated from project directory. But unfortunately when Sonar is started on TeamCity CI server this name is just a garbage (it’s some kind of hash e.g. 1eefa89ab698a6dc). Normally a lot of different logic depends on In my case it is e.g. jar name, Sonar ‘key’ and ‘name’ properties, distribution name. It’s not necessary to say that when project is in such a strange named directory all of these tasks will produce also garbage. To make it worse you can NOT change variable - it is immutable(*).

To fix this problem I am trying to use extension properties. But without success… I have my build script in two files: build.gradle and common.gradle. My project configuration should be located in build.gradle and common part in second file.

When I put: = ‘hpa-core’ in build.gradle

I can see this property in common.gradle here: task mytest {

println }

but I can not see it in sonar configuration: sonar {

project {

name = “${}-gradle”

key = “${}”

version = “continuous-integration”

} }

Script is not executed because of “cannot get property ‘name’ on extra properties extension as it does not exist” error in: name = “${}-gradle”

How to overcome this problem?

BR Marcin

(*) I think that immutability of is causing a lot of troubles. It should be possible to just override with user supplied name. In general it is wrong assumption that project name is strictly connected with project directory. In my case CI server is naming directories in some random way. Also developers can have multiple directories with different versions of project in different directories. Maybe it is good default, but it should be possible to override it.

(Peter Niederwieser) #2

The problem isn’t specific to Sonar. The solution is to add a settings.gradle and set the (root) project name there (‘ = “…”’).

(Marcin Kuszczak) #3

That was quick! :slight_smile:

You are right. I will probably use this solution. But I still think that it’s not “right way”. Part of my build.gradle looks like this:

group = ‘hpa’ version = ‘1.0’

so why I should ‘pollute’ my project directory just to change name of project? Except of polluting main directory it is also easier to forget changing the project name if necessary. I will have to add this file to every project which will use common.gradle. So in my case it’s about 6 projects * 1 file with only one property.

I think that if you depend on immutability of in Gradle, then you should define some internal variable which will correspondent to current behavior and allow to freely modify project name by users.

Anyway thanks for quick answer!

BR Marcin