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 (panattoni.and...@gmail.com) 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
