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
