The difference between the IDE plugins and the Sonar plugin is that the former do most of their work per project and have limited aggregation needs. They have per-project tasks that can be run independently. The Sonar plugin on the other hand does all its work per aggregation root. Applying the Sonar plugin to a subproject would do little more than acting as a marker annotation. The plugin could add a model object to the project, but since the aggregation root's task needs to find that model object anyway, it might as well take over the job of creating and injecting it.
Specific reasons why I didn't go with the plugin-per-project approach: * I found it strange to apply a plugin to a project and not getting any behavior (like a task) for that project's build. * I wanted to support multiple aggregation roots (e.g. analyze project A and its subprojects separately from project B and its subprojects). I'm not saying that I've found the best possible solution, just explaining my reasoning. -- Peter Niederwieser Principal Engineer, Gradleware http://gradleware.com Creator, Spock Framework http://spockframework.org Twitter: @pniederw Adam Murdoch wrote: > > Hi, > > We currently have a few plugins which need to do some work across a > hierarchy of projects: > * The idea plugin needs to generate a .ipr and .iws file for a set of > projects > * The eclipse and idea plugins need to deduplicate project names for a set > of projects > * The sonar plugin needs to analyse a set of projects in a single pass > > We also want to change the jetty plugin so that it is possible to share > the same web container instance across multiple projects. Plus there are > other places where we probably need to do this (eg a reporting plugin, a > release plugin, an aggregate binary plugin, etc). > > There are 3 things such plugins need to do: > * Decide where to place global state > * Decide where to place global tasks > * Decide which projects are to be included > > The ide plugins and the sonar plugin take different approaches to this: > > * The ide plugins attach global state (idea project and workspace models) > to the root project (but only if the the plugin is applied to the root > project), whereas the sonar plugin attaches global state to the project > that the plugin is applied to. > * The ide plugins attach global tasks (idea project and workspace tasks, > deduplication) to the root project (but only if the plugin is applied to > the root project), whereas the sonar plugin attaches global tasks to the > project that the plugin is applied to. > * The ide plugins include only those projects that the plugin is applied > to, whereas the sonar plugin includes all subprojects of the project that > the plugin is applied to, and adds a sonarProject.skip property to each > project if it needs to be excluded. > > I'd really like to use the same approach for all these plugins, as I can't > really see there being any need for them to be different. > > I like the opt-in approach of the ide plugins, as I can use the same > mechanisms for conditionally applying the plugin that I use for all my > other plugins (java, etc). On the other hand, I like the fact that the > sonar plugin makes it explicit which project is the 'owner' of the > analysis, and doesn't force me to include the root project to get anything > useful out of the plugin. > > Some possible approaches: > > 1. Only those projects that the plugin has been applied to are included, > and global state and tasks are attached to the root project (regardless of > whether it is included or not) > 2. Only those projects that the plugin has been applied to are included, > and global state and tasks are attached to the included project that is > highest in the hierarchy. > 3. Global state and tasks are attached to the projects that the plugin has > been applied to, and all its subprojects are included. > 4. Global state and tasks are attached to the projects that the plugin has > been applied to, and I have to explicitly declare which projects are > included. > 5. Separate plugins for root and included projects. > > In all the above cases, the included projects will be simply defined as a > collection property on a model somewhere, so will be easy enough to > override. > > Not sure which one I prefer. One of 2, 3 or 4, I think. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > -- View this message in context: http://gradle.1045684.n5.nabble.com/plugins-that-work-with-a-project-hierarchy-tp4725008p4748638.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
