Sonar analysis has been the only thin so far that has required me to increase the heap or perm gen space for the Gradle build. It would be nice to have the option of forking the process, to avoid that issue.
Definitely have to agree here. With any sizable codebase, especially ones including several third part dependencies, it doesn’t take long for PermGen errors to occur when running the sonarAnalyze task with the default JVM settings.
If it could be forked with it’s own JVM settings (much like for unit tests), then the adjusted PermGen setting would be localized just to the needs of sonarAnalyze and not take effect every time gradle/gradlew is invoked for other tasks.
-Spencer
Good suggestion. Probably Sonar analysis should always run in a separate process. I’ve created GRADLE-2587 for this.
I was just about to look into options for fixing this when I saw the new SonarRunner code in Gradle. This looks like it will solve a lot of issues! Hopefully Sonar Runner 2.1 can also be integrated in time for 1.5, so we can get the forking ability. Thanks, guys!
See more info in the nightly user guide.
Is there any update on this issue?
No news so far. This would be a good opportunity for a community contribution.
Ok, I’ll try to tackle it
Hello Is there any update on this? Or is there any workaround to run Sonar on a separate process?
Thanks!