Hi Peter, The current default is reasonable for most cases. One concrete use case is that if Jacoco auto-configures my integration test execution data as a Sonar property, I would expect that a dependency would be set up on that integration test task.
In practice, it's not that much extra to add the dependency manually or to run "build sonarRunner", so this is somewhat a point of principle. Gradle has facilities needed to handle the dependencies automatically, so I think manual task dependencies should be a matter of last resort. The reasoning behind the "model-less" Sonar plugin makes a lot of sense. It would be nice to have some way of handling the values of properties so that Buildable values add a dependency. Granted that gets a little difficult with individual Files, since those aren't Buildable (as far as I know). Andrew Oberstar On Tue, Mar 26, 2013 at 3:26 PM, Peter Niederwieser <[email protected]>wrote: > Hi Andrew, > > > Andrew Oberstar wrote > > Looking at the DSL for the SonarRunner plugin, I noticed that the > > dependencies of the SonarRunner tasks are directly on the test task. > > The assumption is that for a project that has the `java` plugin applied, > you > want to have (at least) the `main` source set analyzed, and (at least) > the results of the `test` task collected. Isn't this a reasonable > assumption? > If truly necessary, task dependencies can of course be overridden. > Another observation is that Sonar will, apart from any third-party Sonar > plugins I may not be aware of (and that we wouldn't model anyway), > *never* consume any build outputs other than the following: > > * Compiled classes > * Test results > * Code coverage results > > Therefore, the task dependencies should be fairly static and easy to > handle. > > One thing I just noticed is that `sonar.libraries` gets configured with all > files on the `runtime` > configuration, which may include project dependencies. But without task > autowiring, the tasks producing > the depended-on project's artifacts won't be executed. We should > investigate > this. > > > Andrew Oberstar wrote > > One of the big weaknesses of the original Sonar plugin was that > > sonarAnalyze had > > no dependencies, > > Did you consider this a big deal in practice? Typically, `gradle build > sonarAnalyze` was all you needed/wanted, but I didn't like the idea of > having the plugin add that dependency. > > > Andrew Oberstar wrote > > but the approach in SonarRunner bypasses the more model > > based approaches many of the other plugins have taken. > > Could the SonarRunner DSL be modified to get its dependencies from the > > inputs instead? > > Given that the new plugin is (intentionally) model-less, it's not clear to > me how this could be achieved. > > Providing our own Sonar model turned out to be infeasible because the Sonar > ecosystem is totally centered around Sonar properties. Also, properties are > being added/renamed/removed at a fast pace. This is why, after a prolonged > discussion with the Sonar folks, we eventually decided to create a new, > model-less plugin that handles configuration the Sonar way (plain key-value > pairs). > > Cheers, > Peter > > > > -- > View this message in context: > http://gradle.1045684.n5.nabble.com/SonarRunner-Task-Dependencies-tp5711079p5711085.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 > > >
