What if you made just one plugin responsible for providing just the version?
On Sep 2, 2011 10:48 AM, "ansel1" <[email protected]> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
