I've looked at those. The trouble I'm having is that sourceSets supports additions from otherwise decoupled plugins. But in the case of a simple, scalar value, it's not clear how to have two plugins provide the value in a way that keeps trying different plugins until one is successful. Wrapping the base shared convention object in delegating objects has not turned out to be as simple as I thought. @Delegate doesn't turn out to be useful in this case (it requires more type information than I'm willing to supply).
I keep thinking, if convention objects had the option of throwing some kind of exception that indicates "please move on to next object"... Oh...well, I guess it can. I guess if my convention objects implement hasProperty(), and there see if they are able to provide the value (call git, or look for the teamcity properties), return false, then the normal Convention plumbing will move on to the next possible provider...will try that. On Saturday, September 3, 2011 at 7:54 PM, Adam Murdoch [via Gradle] wrote: > > On 03/09/2011, at 3:48 AM, ansel1 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. > > This is the approach we use in Gradle for shared configuration. There's > generally a base plugin which introduces some abstraction (eg the java-base > plugin adds in the sourceSets container, but does not define any actual > source sets). A bunch of plugins then extend and fill out the abstraction (eg > the java, groovy, scala, antlr plugins), and a bunch of plugins which consume > this information (eg the java, eclipse, idea plugins). > > > > > > 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 > > > > > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > > > 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-tp4763279p4766485.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-tp4763279p4766587.html Sent from the gradle-user mailing list archive at Nabble.com.
