GRADLE-2587 Provide option to fork Sonar analysis

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

GRADLE-2587 Provide option to fork Sonar analysis

zeeke
As suggested by Luke Daley, I move the discussion here from github.

I'm going to implement the "fork mode" for SonarQube analysis with the following specification:

- Remove non forking mode entirely
- Allow choice of Sonar runner version
- Change default version to 2.3

Currently, the SonarRunner plugin creates a SonarRunnerExtension for each Java project in the current build config. It allows to configure sonar runner properties for each project.

Now we have a bit more configuration to offer to users, including:
- The sonar-runner version
- The java options to use when forking the new process

I can't put this info in the same extension because it will be applied to subprojects too and it would be meaningless.

The only way I see is to put some filed in the task and to allow users to configure it as following:

sonarRunner {
  // This is the already in place SonarRunnerExtension
  // Each project can have one
  sonarProperties {
    // ...
  }
}

tasks.sonarRunner {  // There is an alias with the extension. The plugin creates only one task.
 
  toolVersion = '2.3'
  forkOptions {
    // ...
    maxHeapSize = '1024m'
  }
}

I think this is not a very nice solution but it is the best we can do if we don't want to break too much backward compatibility.

Any suggestion?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

Andrew Oberstar
Agree about the tasks.sonarRunner {} approach not looking so great.

One option could be to subclass SonarRunnerExtension with a SonarRunnerRootExtension that has the new properties. The root extension would only be used on the project the plugin is applied to. The other projects would use the old extension. However, I'm not sure if there are any other cases where the same extension name maps to a different class depending on the project.

Otherwise, this is still an incubating plugin, so maybe the devs would be alright with breaking some compatibility?


Andy


On Tue, Jul 1, 2014 at 3:03 PM, zeeke <[hidden email]> wrote:
As suggested by Luke Daley, I move the discussion here from  github
<https://github.com/gradle/gradle/pull/257>  .

I'm going to implement the "fork mode" for SonarQube analysis with the
following specification:

- Remove non forking mode entirely
- Allow choice of Sonar runner version
- Change default version to 2.3

Currently, the SonarRunner plugin creates a SonarRunnerExtension for each
Java project in the current build config. It allows to configure sonar
runner properties for each project.

Now we have a bit more configuration to offer to users, including:
- The sonar-runner version
- The java options to use when forking the new process

I can't put this info in the same extension because it will be applied to
subprojects too and it would be meaningless.

The only way I see is to put some filed in the task and to allow users to
configure it as following:

sonarRunner {
  // This is the already in place SonarRunnerExtension
  // Each project can have one
  sonarProperties {
    // ...
  }
}

tasks.sonarRunner {  // There is an alias with the extension. The plugin
creates only one task.

  toolVersion = '2.3'
  forkOptions {
    // ...
    maxHeapSize = '1024m'
  }
}

I think this is not a very nice solution but it is the best we can do if we
don't want to break too much backward compatibility.

Any suggestion?





--
View this message in context: http://gradle.1045684.n5.nabble.com/GRADLE-2587-Provide-option-to-fork-Sonar-analysis-tp5712779.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

zeeke
Ok, the extension hierarchy seems to cover all the new requirements. I'll go this way until anyone else will post a better solution.




2014-07-02 0:44 GMT+02:00 Andrew Oberstar [via Gradle] <[hidden email]>:
Agree about the tasks.sonarRunner {} approach not looking so great.

One option could be to subclass SonarRunnerExtension with a SonarRunnerRootExtension that has the new properties. The root extension would only be used on the project the plugin is applied to. The other projects would use the old extension. However, I'm not sure if there are any other cases where the same extension name maps to a different class depending on the project.

Otherwise, this is still an incubating plugin, so maybe the devs would be alright with breaking some compatibility?


Andy


On Tue, Jul 1, 2014 at 3:03 PM, zeeke <[hidden email]> wrote:
As suggested by Luke Daley, I move the discussion here from  github
<https://github.com/gradle/gradle/pull/257>  .

I'm going to implement the "fork mode" for SonarQube analysis with the
following specification:

- Remove non forking mode entirely
- Allow choice of Sonar runner version
- Change default version to 2.3

Currently, the SonarRunner plugin creates a SonarRunnerExtension for each
Java project in the current build config. It allows to configure sonar
runner properties for each project.

Now we have a bit more configuration to offer to users, including:
- The sonar-runner version
- The java options to use when forking the new process

I can't put this info in the same extension because it will be applied to
subprojects too and it would be meaningless.

The only way I see is to put some filed in the task and to allow users to
configure it as following:

sonarRunner {
  // This is the already in place SonarRunnerExtension
  // Each project can have one
  sonarProperties {
    // ...
  }
}

tasks.sonarRunner {  // There is an alias with the extension. The plugin
creates only one task.

  toolVersion = '2.3'
  forkOptions {
    // ...
    maxHeapSize = '1024m'
  }
}

I think this is not a very nice solution but it is the best we can do if we
don't want to break too much backward compatibility.

Any suggestion?





--
View this message in context: http://gradle.1045684.n5.nabble.com/GRADLE-2587-Provide-option-to-fork-Sonar-analysis-tp5712779.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email






If you reply to this email, your message will be added to the discussion below:
http://gradle.1045684.n5.nabble.com/GRADLE-2587-Provide-option-to-fork-Sonar-analysis-tp5712779p5712780.html
To unsubscribe from GRADLE-2587 Provide option to fork Sonar analysis, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

Luke Daley-2
Just hold off a bit.

Peter (who has done the most work in this area) is going to respond here over the next day or two. I want to get his opinion here.

Thanks again for taking this on.

On 2 July 2014 at 5:21:28 pm, zeeke ([hidden email]) wrote:

Ok, the extension hierarchy seems to cover all the new requirements. I'll go this way until anyone else will post a better solution.




2014-07-02 0:44 GMT+02:00 Andrew Oberstar [via Gradle] <[hidden email]>:
Agree about the tasks.sonarRunner {} approach not looking so great.

One option could be to subclass SonarRunnerExtension with a SonarRunnerRootExtension that has the new properties. The root extension would only be used on the project the plugin is applied to. The other projects would use the old extension. However, I'm not sure if there are any other cases where the same extension name maps to a different class depending on the project.

Otherwise, this is still an incubating plugin, so maybe the devs would be alright with breaking some compatibility?


Andy


On Tue, Jul 1, 2014 at 3:03 PM, zeeke <[hidden email]> wrote:
As suggested by Luke Daley, I move the discussion here from  github
<https://github.com/gradle/gradle/pull/257>  .

I'm going to implement the "fork mode" for SonarQube analysis with the
following specification:

- Remove non forking mode entirely
- Allow choice of Sonar runner version
- Change default version to 2.3

Currently, the SonarRunner plugin creates a SonarRunnerExtension for each
Java project in the current build config. It allows to configure sonar
runner properties for each project.

Now we have a bit more configuration to offer to users, including:
- The sonar-runner version
- The java options to use when forking the new process

I can't put this info in the same extension because it will be applied to
subprojects too and it would be meaningless.

The only way I see is to put some filed in the task and to allow users to
configure it as following:

sonarRunner {
  // This is the already in place SonarRunnerExtension
  // Each project can have one
  sonarProperties {
    // ...
  }
}

tasks.sonarRunner {  // There is an alias with the extension. The plugin
creates only one task.

  toolVersion = '2.3'
  forkOptions {
    // ...
    maxHeapSize = '1024m'
  }
}

I think this is not a very nice solution but it is the best we can do if we
don't want to break too much backward compatibility.

Any suggestion?





--
View this message in context: http://gradle.1045684.n5.nabble.com/GRADLE-2587-Provide-option-to-fork-Sonar-analysis-tp5712779.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email






If you reply to this email, your message will be added to the discussion below:
http://gradle.1045684.n5.nabble.com/GRADLE-2587-Provide-option-to-fork-Sonar-analysis-tp5712779p5712780.html
To unsubscribe from GRADLE-2587 Provide option to fork Sonar analysis, click here.
NAML



View this message in context: Re: GRADLE-2587 Provide option to fork Sonar analysis
Sent from the gradle-dev mailing list archive at Nabble.com.
— 

Luke Daley
http://www.gradleware.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

Peter Niederwieser
In reply to this post by zeeke
<quote author="zeeke">
Ok, the extension hierarchy seems to cover all the new requirements. I'll
go this way until anyone else will post a better solution.
<quote>

Seems like the best solution to me. The old `sonar` plugin uses the same approach (extension named `sonar`, type `SonarRootModel` vs. `SonarProjectModel`).

Looking forward to this contribution.

Cheers,
Peter

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

zeeke
I'm now looking for a good integration test strategy. The old sonaRunner integTest downloads the 3.4 server version and launches it through a ServletContainer. SonarQube has dropped the WAR mode since 4.0 and the next release will be 4.4 .

Now, a good test can be done using a fake sonar-runner and verifying properties but I'm downloading it using an hidden configuration with a maven notation.

Any suggestion of this front?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

Luke Daley-2
Peter?

On 13 July 2014 at 5:02:14 pm, zeeke ([hidden email]) wrote:

I'm now looking for a good integration test strategy. The old sonaRunner
integTest downloads the 3.4 server version and launches it through a
ServletContainer. SonarQube has dropped the WAR mode since 4.0
<http://jira.codehaus.org/browse/SONAR-4577> and the next release will be
4.4 .

Now, a good test can be done using a fake sonar-runner and verifying
properties but I'm downloading it using an hidden configuration with a maven
notation.

Any suggestion of this front?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

Adam Murdoch
In reply to this post by zeeke

On 13 Jul 2014, at 5:02 pm, zeeke <[hidden email]> wrote:

I'm now looking for a good integration test strategy. The old sonaRunner
integTest downloads the 3.4 server version and launches it through a
ServletContainer. SonarQube  has dropped the WAR mode since 4.0
<http://jira.codehaus.org/browse/SONAR-4577>   and the next release will be
4.4 .

Now, a good test can be done using a fake sonar-runner and verifying
properties but I'm downloading it using an hidden configuration with a maven
notation.

Any suggestion of this front?

We should change the test to run the server using the scripts instead.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

zeeke
This post was updated on .
Ok, I will need some artifacts to be uploaded on https://repo.gradle.org/gradle from http://dist.sonar.codehaus.org/

The latest stable version is 4.3.2, we should go with it for integration tests.

EDIT: I don't know if there is a way to track the sonar distribution site as dependency repository. Anyway, I suggest to use the gradle artifactory, even the artifacts are not so small.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

Luke Daley-2

Thanks!

On 22 July 2014 at 4:42:57 am, zeeke ([hidden email]) wrote:

Ok, I will need some artifacts to be uploaded on
https://repo.gradle.org/gradle from http://dist.sonar.codehaus.org/

The latest stable version is 4.3.2, we should go with it for integration
tests.



--
View this message in context: http://gradle.1045684.n5.nabble.com/GRADLE-2587-Provide-option-to-fork-Sonar-analysis-tp5712779p5712917.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

zeeke
I'm having trouble launching the sonar server. I've post a message on sonarqube user list
http://sonarqube.15.x6.nabble.com/SonarQube-integration-test-for-Gradle-plugin-td5027144.html


Plus, the new SonarQube version (4.4) require version 2.6 of sonar-runner. There is almost no way to use gradle with sonar 4.4 at the moment.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

zeeke
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

zeeke
This post was updated on .
The feature is almost finished with some test and I updated the related PR on github. Do you prefere to continue this thread on GitHub?

While waiting for a code review, I'm going to work on the user guide.

Also, what's the plan for the old Sonar plugin (package org.gradle.api.plugins.sonar)? Are we going to continue to support it?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GRADLE-2587 Provide option to fork Sonar analysis

Adam Murdoch

On 11 Aug 2014, at 5:25 am, zeeke <[hidden email]> wrote:

The feature is almost finished with some and I updated the relative PR on
github <https://github.com/gradle/gradle/pull/257>  . Do you prefere to
continue this thread on GitHub?

While waiting for a code review, I'm going to work on the user guide.

Also, what's the plan for the old Sonar plugin (package
org.gradle.api.plugins.sonar)? Are we going to continue to support it?


Not once the sonar-runner plugin is stable. The plan is something like this:

1. finish up the sonar-runner plugin (which include updating the sonar runner version so that it can be specified in the build, switching to forked execution, maybe a couple of tweaks to test result handling).
2. promote the sonar-runner plugin so that it is no longer incubating.
3. deprecate the old sonar plugin.
4. remove the old sonar plugin at the next major Gradle version after step #3 happens.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Loading...