Because there are many different ways the information might be obtained. The VCS commit ID is an interesting piece of information. It's something that would be of interest to many plugins, and there are many different possible ways it might be obtained.
In my example, the git id can be obtained either from proprietary properties injected by teamcity, or by calling git. Neither or both may be present in a particular environment. I could make a single plugin that tries teamcity, then tries git...but that plugin would then be coupled with two different, otherwise orthogonal, tools. And if I tried to make the plugin more general purpose, to handle other CI servers, other VCS systems, and maybe other possible ways to get a commit ID, then the plugin would become very tangled. I think organizing the plugins along the lines of the tools I use in a particular project (if I use git, I can apply the "git" plugin. If I use subversion, I apply the "subversion" plugin) makes the plugins easier to understand and more focused. I got the approach I described earlier working. The "buildVcsNumber" is defined in a base plugin, but that base plugin doesn't define a value for it. The base plugin is applied by all the plugins which either a) use that property, or b) provide a value for that property. The ones that provide the property use @Delegate to install a pipeline of objects which try and get the value, and on failure, delegate to the next convention object. On Saturday, September 3, 2011 at 1:36 PM, Merlyn Albery-Speyer [via Gradle] wrote: > What if you made just one plugin responsible for providing just the version? > On Sep 2, 2011 10:48 AM, "ansel1" <[hidden email] > (/user/SendEmail.jtp?type=node&node=4765886&i=0)> wrote: > > Our project is in git, and we use the git commit id in several place (jar > > manifests, log messages, VERSION files, etc). > > > > The way we get the git commit id depends on the environment in which the > > build runs: if it runs on a dev workstation with git installed, it calls the > > git command line. If the build is running in our TeamCity server, the id is > > passed to the build as a teamcity property. > > > > I've been refactoring some of this logic into a set of re-usable plugins. I > > decided I'd like to have a "git" plugin, and a "teamcity" plugin. Not > > dependent on each other. > > > > Both plugins offer their own ways to get the git commit id. > > > > I'd like to define a single property for storing this commit id, called > > "buildVcsNumber" (generic enough to hold ids from other VCS'). Other > > plugins may expect that property to be defined in the project. I want to > > set up the git and teamcity plugins such that they both offer ways to > > calculate that value, but if they fail, some other plugin would get an > > opportunity to have a go at it. Sort of like this: > > > > build script asks Project for property "buildVcsNumber" > > Project asks plugin1 "can you provide that?" > > Plugin1 says "I'll give it a shot...one sec...nope, no luck, go fish." > > Project asks plugin2 "can you provide that?" > > Plugin2 says "Maybe...yup, I got it, here it is" > > > > Is there a preferred design for this case? > > > > Here's what I'm thinking of now: > > Both "git" and "teamcity" will apply a commit "build-info" plugin, which > > defineds a "build-info" convention with the "buildVcsNumber" property. > > Default value is null. > > > > Both teamcity and git plugins apply that base plugin, then get the > > convention object it installs and wrap it in it's own facade convention > > object. Each facade attempts it's own method of getting the vcs number, and > > on failure, falls through to the delegate's method. > > > > The order in which the different methods are attempted will still be > > indeterminate, but in my case that's ok. It doesn't really matter to me > > which method wins. > > > > -- > > View this message in context: > > http://gradle.1045684.n5.nabble.com/Design-advice-for-multiple-plugins-offering-values-for-the-same-project-property-tp4763279p4763279.html > > Sent from the gradle-user mailing list archive at Nabble.com > > (http://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/Design-advice-for-multiple-plugins-offering-values-for-the-same-project-property-tp4763279p4765886.html > > To unsubscribe from Design advice for multiple plugins offering values for > the same project property, click here > (http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4763279&code=cnVzc2VsbGVnYW5AZ21haWwuY29tfDQ3NjMyNzl8MTc0MDU1ODM0). > > > > -- View this message in context: http://gradle.1045684.n5.nabble.com/Design-advice-for-multiple-plugins-offering-values-for-the-same-project-property-tp4763279p4766173.html Sent from the gradle-user mailing list archive at Nabble.com.
