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.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to