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. > > --------------------------------------------------------------------- > 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
